I've been trying to sort out how to get enough data out of the NIST printer to get to the "millisecond benchy" goal - part of that is figuring what real underlying data rates on USB serial links are.
To start, I spun up ...
To start, I spun up some max-rate-ingestion tests, on ubuntu and windows,
So, we do win some speed when we increase packet sizes, but we have a clear trend around ~ 0.6 -> 0.9 Mbits/s ... which is not awesome; our spec for the data printer requires about 4 Mbits/s of real data rate.
### Windows Subsystem for Linux (WSL)
## 2023 12 20
Another option - though I'm not sure how it will handle drivers etc - is to run this mf'er out of WSL - which I will try because I am having to install ubuntu anyways on a different machine to test on the real deal.
So - yeah, I want to keep working through this today, and I'm going to bundle code in here as well.
That requires some [additional middleware](https://github.com/dorssel/usbipd-win) that looks stateful / PITA-ish, so I will just try on a separate machine; this is meant to be simple.
I wanted to see about improving with nanocobs and maybe packing more data (up to 512 encoded bytes rather than 255), but I don't think that's the bottleneck - instead I suspect that we can try linux instead of windows... and then anyways move on to i.e. ethernet tests or multiple devices / async patterns etc etc etc, so, let's see about linux, running the same code.
### Surprisingly...
Windows out performs ubuntu here. Now, there is a big difference in machines as well: the Windows platform is a much faster machine. However, not starkly so, and I had been expecting a noticable bump in perf from Unix. Fortunately for me, this is not the case.
We do also win some total bandwidth when we use bigger packet sizes, sort of as expected.
But we have a clear cap near 1Mbit/sec in terms of real performance, which FWIW is 1/12th of the USB 2.0 Full-Speed-Device reported max, so there's clearly a lot missing here. Our data-printer spec asks for about 4Mbit/sec.
---
This is also not accounting for i.e. multiple devices, flow control, flow going down (as well as up), etc. For that I will have to improve the system / etc.
...then test to see if we can (1) get some backpressure going on and (2) intelligently control data rates, maybe culminating in some demo of a high-throughput application where we can visualize data flows, and see i.e. how traffic patterns change over time (if new devices are added, for example).
## 2023 12 20
So, we want to... consume and produce data, as fast as possible in either direction, and open multiple ports.
I think I will get some devices w/ OLEDs on 'em, and then also do the due dilly of checking if I2C display writes are blocking or not?
---
And then a next step would be to get the COBS thing up to doing flow-control, and testing TS as well, pushing a first-hello-world-for-each... if we can do that today, and show that we can RP2040 UART PIO, that's good shit.
---
---
## Results
The data printer has a spec for 1.4Mbits/s total data, which initial tests look to not be capable of (out of one USB port) (2023-12-12 images).
## Feedback Systems Assembly
Recall the punchline: we want to develop a link layer that can continuously measure underlying performance... to use as a diagnostic tool.
