You should …
I should give you a tool, what I’ve done 
Everything else is out of my control, actually.
any sort of useful numbers.
The purpose of benchmarking is to highlight differences, so I hope the results are useful to you or anyone else interested in comparing USB/CAN/Serial performance.
lot more samples and a lot more data
In this test, we’re measuring Klipper data payload bandwidth with all the protocol/encoding/decoding overhead (Klipper serial, CAN, USB). While the Klipper protocol does impose some limitations, the data payload size represents a typical batch from sensors like ADXL.
In my setup, I can’t increase the sample count because it simply doesn’t work. But when comparing mean latency, I see that your USB setup is twice as fast as mine with USB. For bandwidth, increasing the sample count improves precision, but it doesn’t change the actual bandwidth. My results don’t vary much, as the count remains relatively stable, aside from small changes in stddev.
As for bandwidth, it’s calculated by dividing the total amount of data by the time taken sum, of each individual transfer time. So, increasing the number of samples improves the precision of the result but doesn’t change the actual bandwidth measurement. In my tests, increasing the sample count doesn’t alter the average much—only the standard deviation.
which gives further misleading results
It’s great that you’re able to get higher numbers. My results may seem conservative, but they should be stable for others and avoid errors like ‘Timer too close.’
I’m curious a little about your lower sample counts and how they lead to differences. Sharing those details would clarify the ‘misleading’ aspect.
If you check Klipper’s benchmarks closely, you’ll see they use nop (code), which means “do nothing.” As explained in the documentation, the benchmark measures “dummy” command processing by the microcontroller. So it’s not directly comparable to actual data payload tests.
I’m not sure, that Klipper’s console.py support work with CAN.
P.S. Just a thought - are you running RatOS on a Raspberry Pi with a 32-bit image? I noticed 32-bit images on GitHub. I’m using the latest official 64-bit Raspbian with Python 3.12, which might explain some differences in our test results.
(This post on CAN communication timeouts between 32-bit and 64-bit Pis might be relevant: https://klipper.discourse.group/t/psa-canbus-on-32-bit-vs-64-bit-pis-communication-timeout-errors).
I will try to make some graphs and add them to the post, to clarify things with the relation between output and count param.