Measurements seem quite short... #14
Comments
|
So, you are saying that the "fluent" tool got you 95.44/30.90 and goresponsiveness 87.499/26.531? Just want to make sure that I am parsing what you are saying! Also, this may be the same as #12 . |
|
Yes flent/netperf gave a throughput of 95.44/30.90 while goresponsiveness gave 87.499/26.531 (this is with my SQM traffic shaper configured for a gross rate of 105/36). |
|
Thanks again for the great reports!! Keep 'em coming!! I really, really
enjoy working with you!
Will
…On Mon, Mar 28, 2022 at 3:44 AM moeller0 ***@***.***> wrote:
Yes flent/netperf gave a throughput of 95.44/30.90 while goresponsiveness
gave 87.499/26.531 (this is with my SQM traffic shaper configured for a
gross rate of 105/36).
And yes this seems to be related to #12
<#12>
—
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCP2CVERQ5QXNE3SKOJVBTVCFPMLANCNFSM5RZDZOHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@moeller0 Would you be willing to run you
test with the Thank you! |
here is the captured debug output: Cooling down seems to take 2-3 seconds, so out of the 8.5 seconds total time, the saturation tests could at most have taken < 8 seconds, but at 12 flows even with bi-directional testing, I naively expected at least 12 seconds measurement time, 4 seconds for each set of 4 additional flows. Feature request, in debug mode, could we prefix every line output with a timestamp (say in microseconds after test start-up, or milliseconds as float?) |
|
Update after 7113efc fix:
Apple's networkQualityAverage RPM: 3064 goresponsivenessAverage RPM: 3558 (excluding error run) |
This was referenced May 6, 2022
|
I am probably exceptionally daft today, but how to interpret |
|
I don't know why the times are formatted differently for my shell - all on one line, instead of separate lines. I'm using zsh, macOS 10.15.7, and the last number looks to be the wall-clock time. See: |
|
Ah, thanks I guess I am daft today ;) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The total measurement duration of the test against apples servers appears quite short. It would be nice if the duration could be controlled from the client (or if that is not according to the spec if the servers could be configured to measure for longer durations):
~6 seconds, that is even shorter than run-of-the-mill speedtests... This might or might not result in a saturating load, but it most certainly will result in an imprecise throughput measurement...
Experience with bufferbloat measurements seems to indicate that >= 20-30 seconds testing is required to fully saturate a link (and be sure about that fact).
Trying to confirm this with flent/netperf:
This is a bidirectional test that only reports actual TCP goodput, neither the latency probes nor the reverse ACK traffic is accounted and yet:
Download: 95.44
Upload: 30.90
which compared to the actual shape settings of 105/36 (with 34 bytes overhead) seems sane:
theoretical maximal throughput:
105 * ((1500-8-20-20-12)/(1500+26)) = 99.08 Mbps
36 * ((1500-8-20-20-12)/(1500+26)) = 33.97 Mbps
Compared to these numbers the reported 87.499/26.531 do not seems either saturating or precise, probably neither....
The text was updated successfully, but these errors were encountered: