Current Server Time: 00:07 (Central Europe)

#apertus IRC Channel Logs

2020/08/11

Timezone: UTC


00:17
RexOrCine
left the channel
00:17
RexOrCine1
joined the channel
03:57
Bertl_oO
off to bed now ... have a good one everyone!
03:57
Bertl_oO
changed nick to: Bertl_zZ
05:13
BAndiT1983|away
changed nick to: BAndiT1983
06:36
mumptai
joined the channel
09:37
mumptai
left the channel
11:58
illwieckz
left the channel
11:58
illwieckz
joined the channel
12:00
Bertl_zZ
changed nick to: Bertl
12:00
Bertl
morning folks!
12:44
kbeckmann
just wanted to let you know that i was able to run https://github.com/apertus-open-source-cinema/ft60x-rs on my ft600 as well (just had to change the PID), and it does indeed use very little cpu resources. great!
12:45
kbeckmann
s/on/with/
12:48
vup
kbeckmann: very nice
12:49
kbeckmann
as for throughput, i get just like with the binary drivers, around 180 MB/s in 245 mode.
12:50
miek
ooh it's in rust, nice. i wrote a viewer for thermal imaging data a while back using libusb-rs, but it wasn't great to work with. i'll have to check out that rusb crate!
12:54
vup
miek: rusb is essentially a continuation of libusb-rs and thus very much the same, the only advantage is, that there is a old version that supports async transfers
12:55
vup
they have remove async transfers again in the newer versions tho
12:58
Bertl
kbeckmann: usb performance largely depends on the infrastructure, i.e. controller, hubs, cables
12:59
kbeckmann
well, in this case i don't have much connected and it's connected straight into the computer (no hub in between). and the numbers seem to scale 2x with yours, you got 360 right?
13:00
kbeckmann
would be fun to try out 60x mode but i haven't done that yet.
13:00
Bertl
there could be a bunch of hubs in your computer as well
13:00
kbeckmann
sure
13:00
Bertl
and the controller might be badly supported
13:01
Bertl
s/badly/not well/
13:01
vup
kbeckmann: well if you try out 60x mode and it gets higher throughput we might be motivated to add support for that to the rust driver aswell :)
13:02
kbeckmann
i'll see if i get around to it. if i do i will of course keep you posted!
13:03
kbeckmann
it would be nice to see a schematic of the mainboard of my computer.. seems there is a hub internally after all. annoying :). guess i have to try all the ports until i find a "pure" one?
13:10
Bertl
might not be there at all
13:11
Bertl
in my experience, the best solution is to have a dedicated controller card
13:11
Bertl
(they are available for PCs and Laptops) but of course that complicates things
13:12
Bertl
also, if you have one of those (red?) usb 3.2 ports, those are typically directly connected to a controller
13:14
BAndiT1983
are 3.2 red now? as 3.1 were blue
13:14
Bertl
I think the red is not official, but I've seen a bunch of them
13:14
Bertl
similar to the yellow ones for charging/always on
13:15
BAndiT1983
ah, ok, someone mentioned it also -> https://www.quora.com/What-is-the-red-colored-USB-port-of-a-motherboard
13:16
Bertl
ah, yes, USB 3.1 Gen 2 is what I meant
13:35
illwieckz
left the channel
13:35
illwieckz
joined the channel
14:20
illwieckz
left the channel
14:52
thiblahute__
joined the channel
15:04
kbeckmann
hum, weird. found a red port and this doesn't seem to work at all. using the official lib stalls, and the rust codes asserts on src/ft60x.rs:103:33
15:06
BAndiT1983
failing handshake?
15:06
BAndiT1983
either check dmesg or for more hardcore version try wireshark USB sniffing
15:07
kbeckmann
thanks, will try wireshark
15:07
kbeckmann
[594689.174328] usb 8-1: usbfs: process 610734 (stream_checker) did not claim interface 1 before use
15:07
kbeckmann
not sure what that means.. but it shows up when running.
15:08
BAndiT1983
you can google last part, found several entries which can help
15:08
BAndiT1983
am not that deep in USB yet, still trying to understand the low-level CDC protocol
15:08
kbeckmann
true. i'll see if i can find what it is
15:41
thiblahute__
left the channel
15:42
vup
I think the claim interface message also occurs when it is working
15:42
vup
that assert means the chip didn't send the amount of data requested, interesting
15:47
thiblahute__
joined the channel
15:48
kbeckmann
oh weird. my code that was using the proprietary lib stalled in the reconfiguration step. if i comment that out and go straight to streaming data it works, and i get 190 MB/s (compared to 180 through a hub)
15:50
Bertl
well, that's something, isn't it?
15:50
kbeckmann
tracking it down now, seems to be the hacky way of waiting for the device to re-enumerate that was broken.
15:52
kbeckmann
but yeah, 190 instead of 180 is nice. this might not scale linearly, but perhaps you may get past 360 if you also skip the hub (unless you already did that)
16:13
kbeckmann
urgh, seems that the proprietary lib has some internal state that gets messed up when you re-enumerate even though I close the driver handle. anyway, won't be using that in the future anyway :).
16:32
mumptai
joined the channel
20:10
RexOrCine1
left the channel
20:19
BAndiT1983
changed nick to: BAndiT1983|away
21:03
danieel
left the channel
21:04
danieel
joined the channel
21:08
illwieckz
joined the channel
21:34
aombk3
joined the channel
21:38
aombk2
left the channel
21:41
fjodor[m]
joined the channel
22:49
illwieckz
left the channel
23:26
mumptai
left the channel