Foxyloxy has quit [Read error: Connection reset by peer]
<whitequark[cis]>
good news: i'm finally working on the parts of the glasgow stack which are limiting the amount of conceptual data pipes (and thus, number of applets, but also the flexibility of individual applets that require many async data streams)
<whitequark[cis]>
soon, you should be able to get as many streams to/from PC as you want, with very little overhead (cycles on gateware side, CPU time on host side)
<urja>
Oh now I realize i might've misunderstood your original idea (as a delay that resets on write to the buffer, when you mightve meant one that counts time for the whole packet?) and we have the same idea with different names lol
<urja>
the NAGLE algo as in the wiki describes one where the packet is buffered until the ACK for the previous write is received, but I assume we dont have TCP-like ACKs so that would be nonsensical?
<whitequark[cis]>
no, i think you understod me correctly
<whitequark[cis]>
and i actually think your idea makes more sense, after examining it carefully
galibert[m] has joined #glasgow
<galibert[m]>
Isn’t nagle’s aim avoiding congestion in packet-routed networks ?
<whitequark[cis]>
the underlying useful property is "a byte clocked into the FIFO at cycle x will be submitted at last in cycle x+y" in yours
<whitequark[cis]>
and mine provides no such guarantee
<whitequark[cis]>
it just ensures that such a byte will be submitted eventually, with a delay depending on which other things the applet is doing
<whitequark[cis]>
if i reset the timer on every write to the buffer, and the timer is (e.g.) 20 ms, then for a 512 byte buffer filled with bytes at a rate of one per 19 ms, you'll wait up to 10 seconds (!!)
<urja>
Yeah yours is at the worst case x+(y*512) (where x being the time of insertion and y being a per-byte timeout) and I figured that as the timeout grows, well the worst case delay becomes noticeable (and growing y might be necessary to have any packets bigger than 1 for slow links)
<whitequark[cis]>
i don't think we need an inter-byte timeout at all, rather it should be a form of QoS which says "if you pushed in a byte it should end up committed to USB at most this many milliseconds later"
<urja>
Ah okay, yeah that might work (i'm trying to think of the inter-byte timeout is actually useful somewhere)
<whitequark[cis]>
once we start multiplexing multiple data pipes using COBS, this should be done on a per-applet basis, ie an applet with a requested worst-case latency of 1ms adding a byte after another applet with a requested latency of 10ms causes the entire buffer to flush before 10ms expire
<urja>
like, it could be beneficial (for "early exit" when the stream ends), but not sure if functionally necessary
<whitequark[cis]>
actually, this is another great point you bring up
<whitequark[cis]>
I think it might be quite nice to get rid of .flush entirely
<asjackson>
whitequark[cis]: sure, got about an hour now, more free this evening :) is it _that_ bad? :P
<whitequark[cis]>
urja: we should be able to submit something like 3 buffers per microframe, which with 4 buffers per EP means a timeout of 125us is probably more than sufficient
<whitequark[cis]>
we do bump into the "receiving a less-than-full packet costs one libusb completion each time"
<whitequark[cis]>
* each time" issue
<whitequark[cis]>
asjackson: not at all, I just would like to understand how it's working on a deeper level
<asjackson>
ah cool, i'll write it up as a github comment i think, so i can go back and edit bits. typing that over irc will give me a headache :)
<whitequark[cis]>
asjackson: thanks, this is very comprehensive! i'll read it later during another review round
<whitequark[cis]>
urja: I just realized we probably need TCP-ish ACKs
<whitequark[cis]>
well, more like PCIe-ish ACKs, because the purpose would be to avoid head-of-line blocking with multiple simultaneous applets
<asjackson>
whitequark[cis]: nice thanks, maybe wait till i can push a couple of small things not pushed (i forgot my yubikey today)... probably 6pm ish
<whitequark[cis]>
it's actually really challenging to support that use case even beyond the UI
<asjackson>
(sorry found a work around, no rush tho)
<whitequark[cis]>
a really cursed fact is that with a single applet, you are able to rely on backpressure being transmitted via USB, but with multiple applets, you have to either (a) drop data and have acks and retransmissions or (b) accept that head-of-line blocking will keep being a problem
<whitequark[cis]>
i think buffer management is about to get a whole lot worse hahaha
<whitequark[cis]>
moreover, if we do things like "put registers into the same BULK IN/OUT pipe as the rest", you don't even need multiple applets to trigger the same problem
<whitequark[cis]>
merely trying to tell an applet that's stuck and not reading queued data to do something else asynchronously brings it out already
<whitequark[cis]>
i think what i'm going to do is to not even try to solve it in python, but write a rust program (using nusb and pyo3) that would do all of the buffer management, retransmission, etc and the python code would just have write(), read(), etc calls plus a way to tell the rust code "just pipe all of the data to/from this fd"
<whitequark[cis]>
this would also make network transparency not only possible but quite easy
<whitequark[cis]>
who's excited for network transparency?
<galibert[m]>
I am, I need to multiplex a couple of midi streams and a couple of i2s ones
Attie[m] has joined #glasgow
<Attie[m]>
this sounds very exciting!
<Attie[m]>
intrigued by the support from rust - what's the reasoning there?
<whitequark[cis]>
python is quite slow at byte-wise processing. so far i've managed to get the performance quite good because i've very aggressively added high-level optimizations that punt to C for bytes processing, reused buffers via memoryview, and so on
josHua[m] has joined #glasgow
<josHua[m]>
I am excited for network transparency, for the long threatened but never implemented wafflehouse
<whitequark[cis]>
but using COBS and especially having to handle retransmits with such a small on-device buffer size means a bunch of byte-wise processing in Python
<whitequark[cis]>
the PyPI cobs package carries a CPython extension already. it works fine on PyPy and CPython, with good performance, but it's an extension without binary wheels for anything but Windows
<whitequark[cis]>
and it wouldn't help with the retransmits
<whitequark[cis]>
I benchmarked providing the COBS encode/decode via PyO3, and curiously it's somehow worse than the CPython extension (on both Python kinds), but still satisfactory
<josHua[m]>
(or otherwise for being able to run a UART-driver emulation daemon out of process in a way that can hold it at arm's length from the Glasgow core, and Glasgow core could then implement only a more tasteful API like "emulate some UARTs for me with some line config options", or "emulate some MPSSEs for me" and the tasteless stuff can live somewhere out of tree without having to actually create an out-of-tree applet)
<whitequark[cis]>
moreover, python-libusb1 is a very good library but it can only do so much to bridge two very different languages, and we layer async on top of that
<whitequark[cis]>
and it keeps segfaulting on exit sometimes, which annoys me
<Attie[m]>
fair enough 😂🫣
<whitequark[cis]>
there's so much overhead in thread synchronization inherent in libusb, python synchronization, buffer munging...
<Attie[m]>
I've been using a python cobs package recently, pretty sure it calls out something (c? rust?) but I didn't watch the install closely enough re binary wheels
<josHua[m]>
also yes, on slow platforms, processing a byte stream in CPython is truly miserable.
<whitequark[cis]>
and then when you are feeding the buffers to something external like openocd, there can be a lot of python overhead especially with small packets
<whitequark[cis]>
Attie: it builds a C extension. it also has a pure-Python fallback but the performance is miserable
<whitequark[cis]>
even on PyPy, where the fallback is recommended according to some
<Attie[m]>
I also swapped from a pre python CRC package, to a rusty-supported CRC, and the performance bump was absurd... like -95% run time, so I know the impact well!
<whitequark[cis]>
(you have at most 45 MiB/s with USB HS BULK)
<whitequark[cis]>
anyway, that is quite bad, do you know why it went with the fallback?
<altracer[m]>
disregard that, that was bytecode fallback. I then cloned the repo, fiddled around with missing/UNKNOWN egg info, reset to 1.2.0 and done a `sudo python3 setup.py install`. After `pip3 uninstall cobs` it picked up the native C library variant and ran much faster
<altracer[m]>
If this library is good enough for cpy/pypy, the distutils packaging is old/incomplete, it likely misses wheel or egg information. I tried to regenerate something via bdist_egg, and renamed a bunch of entries, but setup.py does not want to pick it up. And without that code goes to UNKNOWN dist-packages where I can't import it from.
<whitequark[cis]>
right, gotcha. this is very useful information, I've been hesitating to add it as a dependency
<altracer[m]>
Okay I think I fixed it by adding these two lines to setup.py, and now bdist_wheel succeeds:
<altracer[m]>
+ name="cobs",
<altracer[m]>
+ version="1.2.1",
<whitequark[cis]>
do you think you could submit a PR to cobs?
<altracer[m]>
installed, it's still accelerated. idk if it's *enough* but I can submit. Or you can submit it if you daily-drive linux, too.
<altracer[m]>
well the version might not be 1.2.1
<altracer[m]>
strange, that's present in pyproject.toml
<_whitenotifier-2>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-799-a03e40d62f17dba36dde3f8a1809bb5aa4698c83 - https://github.com/GlasgowEmbedded/glasgow
<altracer[m]>
as I wrote the PR description I thought to test on my Raspberry Pi 3B running Aarch64 Debian 11 bullseye, and ... it fetches through pip3 the cobs-1.2.1 package and compiles native extensions successfully without any patching, what gives? python3.9 with C extension is then fast enough (100 MiB/s). Without? Abysmal.
<altracer[m]>
Third machine, Gentoo 2.14 on Ryzen 5600G, world not updated for a couple years -- `pip3 --user` was disabled by maintainers but I can clone the repo and invoke `python3.11 setup.py bdist_wheel` which ... picks up the info from *somewhere* and does the right thing.
<altracer[m]>
encoding: 0.36110053722608665 GB/s
<altracer[m]>
decoding: 0.3809092131056421 GB/s
<altracer[m]>
Submitted, won't bother you with *more* conventional x86_64 Linux CPython setups.
redstarcomrade has quit [Read error: Connection reset by peer]
<altracer[m]>
25ms per semihosting call? Not bad for desktop roundtrip! I couldn't get much faster than 19-25ms for in-BMP calls SYS_ELAPSED/TICKFREQ, but it has an excuse of bitbanged SWD (and USBOTG_FS not HS)
<whitequark[cis]>
oh, thanks ^^ I was wondering where this places me against other tools
lxdr5 has quit [Remote host closed the connection]
lxdr5 has joined #glasgow
<whitequark[cis]>
just realized that we could fix the performance issues plaguing windows by switching interface alt settings instead of switching configurations
<whitequark[cis]>
somehow this completely elided me for 5 years
<galibert[m]>
eluded?
<whitequark[cis]>
eluded, yes
<galibert[m]>
:-)
<galibert[m]>
So you had to go with Cat for 5 years but now you can use Catherine?
<galibert[m]>
I guess Windows takes ages to switch configs?
<whitequark[cis]>
you can't
<galibert[m]>
oh, that's even worse
<whitequark[cis]>
like, at all. impossible. can't do with WinUSB. can't do with libusb. can't do with a custom kernel mode device driver (via documented APIs)
<galibert[m]>
wow
<whitequark[cis]>
can't do via libusbK either
<galibert[m]>
really opiniated on that topic, windows is
<whitequark[cis]>
now that i research the topic deeper, it seems that "configurations" are intended for static switching only, and presumably windows and usb were co-developed in that aspect
<altracer[m]>
Windows does not support alt settings, correct. Only default.
<whitequark[cis]>
alt configs
<whitequark[cis]>
it supports alt interface settings just fine
<altracer[m]>
So JLink (newer than V9) and XDS110 use Configurator and xdsdfu to tell firmware to switch descriptors and operating modes.
<altracer[m]>
Is there a page which describes the difference between configs and settings? Preferably not the USB spec...
<whitequark[cis]>
(cont. re: switching) since switching interfaces gives you everything that switching configurations would give you in terms of EP flexibility, you're not losing that much by being constrained like this; you do lose the ability to pretend to be other devices
<galibert[m]>
I guess to pretend to be another device you have to fully disconnect and come back
<whitequark[cis]>
altracer: i personally find the spec readable
<whitequark[cis]>
galibert: generally speaking you do that anyway, since even Linux binds kernel drivers to the first supported config
<galibert[m]>
the spec is a little hard if you haven't seen actual traces of usb communications
<gruetzkopf>
hm, what unconventional machines with modern python do i have around.. could get ppc64 (bigendian), sparc64 and itanium2 :D
<galibert[m]>
LA-ing a usb1.0 device helped me quite a lot
<whitequark[cis]>
oh hi gruetzkopf
<galibert[m]>
(hardest part was fiding something old enough)
<whitequark[cis]>
using glasgow much these days?
<galibert[m]>
s/fiding/finding/
<altracer[m]>
For example, when I invoke Linux OTG gadget for Composite RNDIS+ACM+mass storage, and RNDIS is intended for Windows but Linux sees the second config and requests a switch to ECM, what is it called? (other than a legacy support headache)
<whitequark[cis]>
so, composite devices are a secret third thing
<whitequark[cis]>
but you might have a situation where you have both a composite device and multiple configurations
<gruetzkopf>
fairly regularly, i expect to use memory-floppy on some not-known-to-me-disk-format disks soon (containing boot code for GEI 6000 series computers (a clone of general automation GA-400))
<whitequark[cis]>
if you send the configuration descriptor dump my way i will be able to tell
<whitequark[cis]>
gruetzkopf: sweet! still with the hacked up revB?
<gruetzkopf>
hacked up B, C1, C2
<whitequark[cis]>
oh, that's many
<whitequark[cis]>
what's your #1 complaint?
<gruetzkopf>
well, the very thing you're working on, multiapplet operation
<gruetzkopf>
otherwise it's been extremely useful and reliable (when i didn't manage to mess up CDC in an applet again)
<whitequark[cis]>
haha, you're in luck; i almost have a working (super rough) prototype
<whitequark[cis]>
glad to hear it was reliable, reliability is probably my top concern with it
<whitequark[cis]>
absolutely nobody ever wants to debug their debug tool