diff --git a/2023-12_usb-real-data-rates.md b/2023-12_usb-real-data-rates.md
index 0d0025fc72a9692ca29f56b06c1e56d7c2e9ac3f..2499f6ea0ebc15925b07b40c8622ca56e0e9b7e8 100644
--- a/2023-12_usb-real-data-rates.md
+++ b/2023-12_usb-real-data-rates.md
@@ -2,37 +2,53 @@
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,
-
+### In Ubuntu (Lattitude 5490): 0.4 -> 0.5 Mbits/s
-
+
+
+
+
-
+### In Windows (XPS 15 2019): 0.6 -> 0.9 Mbits/s
+
+
+
-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).
\ No newline at end of file
+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.
\ No newline at end of file
diff --git a/code/serial_source/serial_source.ino b/code/serial_source/serial_source.ino
index 610940615df3a2decc89f341a90fe774b12ec599..cce655d133d2f97123210dc5a5d6ec4623829f2f 100644
--- a/code/serial_source/serial_source.ino
+++ b/code/serial_source/serial_source.ino
@@ -40,7 +40,7 @@ void loop() {
// tx a stamp AFAP
if(cobs.clearToSend()){
chunk.u = micros();
- cobs.send(chunk.bytes, 250);
+ cobs.send(chunk.bytes, 32);
digitalWrite(PIN_LED_G, !digitalRead(PIN_LED_G));
}
// blink to see hangups