whitequark changed the topic of #glasgow to: digital interface explorer · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · discord https://1bitsquared.com/pages/chat · production https://www.crowdsupply.com/1bitsquared/glasgow (FUNDED)
jstein has quit [Ping timeout: 276 seconds]
Foxyloxy_ has joined #glasgow
esden has quit [*.net *.split]
Stary has quit [*.net *.split]
Dark-Star has quit [*.net *.split]
alanvgreen has quit [*.net *.split]
russss has quit [*.net *.split]
merry has quit [*.net *.split]
Dark-Star has joined #glasgow
alanvgreen has joined #glasgow
Dark-Star has joined #glasgow
Dark-Star has quit [Changing host]
esden has joined #glasgow
russss has joined #glasgow
merry has joined #glasgow
Stary has joined #glasgow
pg12 has quit [*.net *.split]
pg12 has joined #glasgow
fibmod has quit [Ping timeout: 248 seconds]
fibmod has joined #glasgow
chaoticryptidz has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
chaoticryptidz has joined #glasgow
jstein has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #glasgow
puck has quit [Excess Flood]
puck has joined #glasgow
fibmod has quit [Ping timeout: 252 seconds]
fibmod has joined #glasgow
Tom_ has joined #glasgow
Tom__ has quit [Ping timeout: 248 seconds]
jstein has quit [Quit: quit]
jstein has joined #glasgow
<d1b2> <davoid> quick one, remember I saw a speed test where u achieved close to 30MB over bulk (cdc?) via libusb+python, correct or dream?
<d1b2> <Qyriad> Idk about CDC specifically, but we've managed to get around 42 MiB/s in Python with pretty tuned code
<d1b2> <Qyriad> This will depend a lot on your host controller too though
<d1b2> <davoid> tuned linux prios you mean? pr even rtpatched?
<d1b2> <Qyriad> Tuned Python code handing the transfers
<d1b2> <davoid> stock libusb?
<d1b2> <Qyriad> Yep
<d1b2> <davoid> on the transport/LL side, did you have to do something else than just one cdc endpoint to achieve that speed?
<d1b2> <davoid> i've seen problems with libusb being able to pack all microframes in an optimal way
<d1b2> <Qyriad> Before we optimized it we got it to ~30 MiB/s on some host controllers, but other host controllers it was less than half that
<d1b2> <davoid> to follow the opt history, where should I look?
<d1b2> <Qyriad> Not that I remember, but it wasn't CDC: vendor-specific bulk
<d1b2> <Qyriad> Look at the discussions and branches listed in this issue: https://github.com/greatscottgadgets/greatfet/issues/286
<d1b2> <Qyriad> Iirc the tl;dr was use python-libusb1 with async transfers instead of PyUSB, and benchmark to make sure any Python data-parsing code isn't getting in the way of the USB transfers
<d1b2> <davoid> thx
<d1b2> <davoid> because cdc was slower? or just to get a separate descriptor as you own both sides?
<d1b2> <Qyriad> idk, we weren't there for when it was implemented, but I'd assume it was just because it was simpler
<d1b2> <Qyriad> Didn't have to go and correctly implement a proper USB class; they just made a bulk endpoint that sporked raw data any time it was asked
<d1b2> <Qyriad> I don't know enough about CDC to know what overhead it has, so I don't know how helpful these results will be for you, but if you're having performance issues then switching to python-libusb1 and async transfers is a good bet
<d1b2> <davoid> will try and mimic that implementation
<d1b2> <davoid> i was mainly interested if several bulk endpoint was used to trick the OS of filling the outgoing phy buffers in a more efficient way
<d1b2> <Holonium> Any chance that a Glasgow ordered June 2021 will arrive before August this year under current conditions?
slurdge3 has joined #glasgow
kbeckmann has quit [Ping timeout: 256 seconds]
kbeckmann has joined #glasgow
slurdge has quit [Ping timeout: 248 seconds]
slurdge3 is now known as slurdge
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #glasgow
icb has quit [Ping timeout: 250 seconds]
icb has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]