Current Server Time: 23:07 (Central Europe)

#apertus IRC Channel Logs

2020/08/06

Timezone: UTC


00:18
intracube
left the channel
00:19
intracube
joined the channel
00:20
mumptai
left the channel
02:23
Bertl_oO
off to bed now ... have a good one everyone!
02:23
Bertl_oO
changed nick to: Bertl_zZ
05:06
BAndiT1983|away
changed nick to: BAndiT1983
05:45
Spirit532
left the channel
05:46
Spirit532
joined the channel
06:07
futarisIRCcloud
left the channel
09:56
mumptai
joined the channel
10:44
Bertl_zZ
changed nick to: Bertl
10:44
Bertl
morning folks!
11:25
se6ast1an
good day
11:51
Dest123
joined the channel
12: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.
12:17
Bertl
vup and anu3jn are already on it ... for now with the FTDI drivers though
12:17
vup
we are getting ~360MB/s with the ftdi driver currently, now to writing our own
12:47
kbeckmann
cool!
12:48
kbeckmann
are you going the libusb route or kernel module?
12:48
kbeckmann
or perhaps something completely different
13:13
futarisIRCcloud
joined the channel
13:24
vup
libusb, as we want to have "easy" cross platform support
13: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.
13:51
Brian_Lad
joined the channel
13:52
Brian_Lad
left the channel
15:11
mumptai
left the channel
15:11
mumptai
joined the channel
16:04
RexOrCine
left the channel
16:09
RexOrCine
joined the channel
16:57
RexOrCine
left the channel
19: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)
19:19
vup
very very wip code here: https://github.com/apertus-open-source-cinema/ft60x-rs
19:20
Bertl
well, 25% is already quite impressive
19:21
vup
(25% of one core on my laptop, results may vary on other hardware)
19:21
Bertl
we had way worse performance in our tests
19:22
vup
also this is verifyable without any data loss (you had problems with that iirc)
19:22
Bertl
btw, you say laptop, is the USB bus shared?
19:23
Bertl
yes, indeed, without (intentional) data loss we ended up with way less
19: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
19:25
Bertl
okay, a good way to test is to use usbmon and the respective usbmonX device for your bus
19: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
19:26
vup
ok, with usbmon there are only packets related to the FT601 (and some hub stuff, but thats normal I think)
19:27
Bertl
good then, because on laptops, quite often the root hubs are connected to a number of devices/other hubs
19:27
Dest321
joined the channel
19:27
Dest321
left the channel
19:28
Dest321
joined the channel
19:28
Dest123
left the channel
19:28
Bertl
and some funny keyboard or bluetooth adapter can mess up the entire bus
19:56
se6ast1an
do you expect the bottleneck on the sender or receiver side?
19: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
20: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
20: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.
21:02
anu3jn
kbeckmann: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/cores/ft601/ft601_stream_sink.py
21: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
21:02
kbeckmann
ohh nmigen, nice :)
21:03
anu3jn
there should be no latency in filling the buffer of the ft601 when there is space
21:03
BAndiT1983
changed nick to: BAndiT1983|away
21:05
kbeckmann
nice
21:05
kbeckmann
yeah that last one should really max it out
21:06
kbeckmann
maybe it just isn't faster :/
21: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.
21:27
anu3jn
In an 386 they suggest that multichannel fifo mode could be faster
21:30
anu3jn
*AN386
21:31
anu3jn
Moreover they have numbers above 360 mbyte/s with less fifo bus idle cycles
21:31
anu3jn
So it seems that at least a bit more is doable
21:45
illwieckz
left the channel
22:16
kbeckmann
ok, interesting. wonder if performance is different on windows. (i assume perhaps incorrectly that you were using linux)
22:19
Bertl
I'd say you are assuming correctly :)
22:25
illwieckz
joined the channel
22:27
vup
indeed :)
22:28
Dest321
left the channel
22:28
Dest321
joined the channel
22:28
Dest321
left the channel
22:28
Dest321
joined the channel
22:40
Dest321
left the channel
23:47
Umori
left the channel
23:50
Umori
joined the channel
23:58
paul[m]4
joined the channel