2023-12_usb-real-data-rates.md

## 2023 12 12 

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

![4byte](images/2023-12-12_ingest-histogram-single-source-pck-32.png)

![64byte](images/2023-12-12_ingest-histogram-single-source-pck-64.png)

![128byte](images/2023-12-12_ingest-histogram-single-source-pck-128.png)

![250byte](images/2023-12-12_ingest-histogram-single-source-pck-250.png)

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. 

## 2023 12 20 

So - yeah, I want to keep working through this today, and I'm going to bundle code in here as well. 

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.


--- 

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

--- 

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