| 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 |