Skip to content
Snippets Groups Projects
2023-12_usb-real-data-rates.md 2.75 KiB
Newer Older
  • Learn to ignore specific revisions
  • Jake Read's avatar
    Jake Read committed
    ## 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 some max-rate-ingestion tests, on ubuntu and windows,
    
    Jake Read's avatar
    Jake Read committed
    
    
    ### In Ubuntu (Lattitude 5490): 0.4 -> 0.5 Mbits/s 
    
    Jake Read's avatar
    Jake Read committed
    
    
    ![32byte](images/2023-12-12_ingest-histogram-single-source-pck-32-ubuntu.png) 
    ![64byte](images/2023-12-12_ingest-histogram-single-source-pck-64-ubuntu.png)
    ![128byte](images/2023-12-12_ingest-histogram-single-source-pck-128-ubuntu.png)
    ![250byte](images/2023-12-12_ingest-histogram-single-source-pck-250-ubuntu.png)
    
    Jake Read's avatar
    Jake Read committed
    
    
    ### In Windows (XPS 15 2019): 0.6 -> 0.9 Mbits/s 
    
    Jake Read's avatar
    Jake Read committed
    
    
    ![32byte](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)
    
    Jake Read's avatar
    Jake Read committed
    
    
    ### Windows Subsystem for Linux (WSL) 
    
    Jake Read's avatar
    Jake Read committed
    
    
    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. 
    
    Jake Read's avatar
    Jake Read committed
    
    
    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.
    
    Jake Read's avatar
    Jake Read committed
    
    
    Jake Read's avatar
    Jake Read committed
    
    
    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. 
    
    Jake Read's avatar
    Jake Read committed
    
    
    We do also win some total bandwidth when we use bigger packet sizes, sort of as expected. 
    
    Jake Read's avatar
    Jake Read committed
    
    
    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. 
    
    Jake Read's avatar
    Jake Read committed
    
    
    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. 
    
    Jake Read's avatar
    Jake Read committed
    
    
    ## 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? 
    
    Jake Read's avatar
    Jake Read committed
    
    
    
    Jake Read's avatar
    Jake Read committed
    
    ---
    
    ## 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.