Current Server Time: 17:33 (Central Europe)

#apertus IRC Channel Logs

2020/08/06

Timezone: UTC


01:18
intracube
left the channel
01:19
intracube
joined the channel
01:20
mumptai
left the channel
03:23
Bertl_oO
off to bed now ... have a good one everyone!
03:23
Bertl_oO
changed nick to: Bertl_zZ
06:06
BAndiT1983|away
changed nick to: BAndiT1983
06:45
Spirit532
left the channel
06:46
Spirit532
joined the channel
07:07
futarisIRCcloud
left the channel
10:56
mumptai
joined the channel
11:44
Bertl_zZ
changed nick to: Bertl
11:44
Bertl
morning folks!
12:25
se6ast1an
good day
12:51
Dest123
joined the channel
13:13
kbeckmann
nice to see that the ft601 enumerates on the new board, exciting! will be interesting to follow your progress here, especially if you can do a throughput test and see how fast you can go.
13:17
Bertl
vup and anu3jn are already on it ... for now with the FTDI drivers though
13:17
vup
we are getting ~360MB/s with the ftdi driver currently, now to writing our own
13:47
kbeckmann
cool!
13:48
kbeckmann
are you going the libusb route or kernel module?
13:48
kbeckmann
or perhaps something completely different
14:13
futarisIRCcloud
joined the channel
14:24
vup
libusb, as we want to have "easy" cross platform support
14:28
kbeckmann
that is so nice to hear. i was thinking of implementing that as well as it seems like the best approach in terms of cross platform and so on. just hope it will still be ok latency-wise. would love to reuse your code for the ft600 later on that i've been using on my board.
14:51
Brian_Lad
joined the channel
14:52
Brian_Lad
left the channel
16:11
mumptai
left the channel
16:11
mumptai
joined the channel
17:04
RexOrCine
left the channel
17:09
RexOrCine
joined the channel
17:57
RexOrCine
left the channel
20:19
vup
kbeckmann: Bertl: well using async libusb our driver is getting pretty exactly the same performance (~360MB/s) as the proprietary ftdi one, but with less cpu usage (70% for the ftdi one vs 25% for our driver)
20:19
vup
very very wip code here: https://github.com/apertus-open-source-cinema/ft60x-rs
20:20
Bertl
well, 25% is already quite impressive
20:21
vup
(25% of one core on my laptop, results may vary on other hardware)
20:21
Bertl
we had way worse performance in our tests
20:22
vup
also this is verifyable without any data loss (you had problems with that iirc)
20:22
Bertl
btw, you say laptop, is the USB bus shared?
20:23
Bertl
yes, indeed, without (intentional) data loss we ended up with way less
20:24
vup
Bertl: its just plugged into one of the usb ports on my laptop, not sure how to figure out if the bus is shared with anything, in lsusb its the only thing on "Bus 003" atleast
20:25
Bertl
okay, a good way to test is to use usbmon and the respective usbmonX device for your bus
20:26
Bertl
if you see any packets not related to the FT601 (or if you see any packets after disconnecting the FT601) then your bus is shared in some way
20:26
vup
ok, with usbmon there are only packets related to the FT601 (and some hub stuff, but thats normal I think)
20:27
Bertl
good then, because on laptops, quite often the root hubs are connected to a number of devices/other hubs
20:27
Dest321
joined the channel
20:27
Dest321
left the channel
20:28
Dest321
joined the channel
20:28
Dest123
left the channel
20:28
Bertl
and some funny keyboard or bluetooth adapter can mess up the entire bus
20:56
se6ast1an
do you expect the bottleneck on the sender or receiver side?
20:59
se6ast1an
if its on the receiver side would a USB 3.1 Gen 2 port and usb-c connector help? https://cdnblob.moshi.com/uploadedfiles/photo/v3/productImages/890/01.jpg
21:07
Bertl
again, depends on the bus, but if there is nothing else happening on the bus, a good quality cable should ensure maximum performance of that specific usb host controller
21:44
kbeckmann
vup: that's awesome progress. but too bad that the actual throughput isn't higher. can you post your gateware / HDL? would be interesting to look at.
22:02
anu3jn
kbeckmann: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/cores/ft601/ft601_stream_sink.py
22:02
anu3jn
or for a more simple example: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/cores/ft601/ft601_perf_debug.py
22:02
kbeckmann
ohh nmigen, nice :)
22:03
anu3jn
there should be no latency in filling the buffer of the ft601 when there is space
22:03
BAndiT1983
changed nick to: BAndiT1983|away
22:05
kbeckmann
nice
22:05
kbeckmann
yeah that last one should really max it out
22:06
kbeckmann
maybe it just isn't faster :/
22:10
kbeckmann
still kinda weird since they claim 400. 360 is only 90% of that.. did you also try the multi channel fifo mode? it will probably be the same but still.. would be interesting to know.
22:27
anu3jn
In an 386 they suggest that multichannel fifo mode could be faster
22:30
anu3jn
*AN386
22:31
anu3jn
Moreover they have numbers above 360 mbyte/s with less fifo bus idle cycles
22:31
anu3jn
So it seems that at least a bit more is doable
22:45
illwieckz
left the channel
23:16
kbeckmann
ok, interesting. wonder if performance is different on windows. (i assume perhaps incorrectly that you were using linux)
23:19
Bertl
I'd say you are assuming correctly :)
23:25
illwieckz
joined the channel
23:27
vup
indeed :)
23:28
Dest321
left the channel
23:28
Dest321
joined the channel
23:28
Dest321
left the channel
23:28
Dest321
joined the channel
23:40
Dest321
left the channel
00:47
Umori
left the channel
00:50
Umori
joined the channel
00:58
paul[m]4
joined the channel