So here is my take,
to assess the usefulness of an internet access link (any link probably, but
being an end user myself, I want to limit myself to where I have first hand
experience) there are a number of easier/harder to get numbers:
1) access rate: easy to measure (at least as HTTPS/TCP/IP goodput, gross rate
of the bottleneck link is considerable harder to deduce)
2) latency to the end-point under test: also easy to measure (simply by running
an ICMP probe stream before and during a speedtest; also some more enlightened
speedtests already report both RTTs)
IMHO that actually should be a tuple of
latency without load RTT(unloaded) , and latency under saturating
conditions RTT(saturated)
=> if both numbers exist, the difference RTT(saturated) - RTT(unloaded)
= Latency under load increase (LULI ;)) can be calculated
which is a proxy of the level of latency degradation a user can
expect as a function of load.
3) latency variation/jitter: also reasonable easy to measure with tools like
MTR. Quite a number of use-cases work well with moderately high, but static
RTTs but deteriorate quickly if the latency becomes too variable
(Some access technologies, like WiFi or DOCSIS are prone to introduce
jitter, as is XDSL when ITU G.998.4 G.INP retransmissions enter the picture)
4) packet loss: relatively hard to measure, but some tools like iperf seem to
report retransmissions,
5) packet re-ordering: hard to measure (IIUC) if severe enough this will
manifest as apparent packet loss/replay attack
RPM. IMHO is nice additional way to address 2) above, but personally, I am less
interested in how many hypothetical transactions I could perform per second as
compared to how long each takes, as the latter still allows me to make
reasonable guesses of completion time if I issue transactions in parallel, and
the LULI measure can be reasonably compared with what ever latency budget a
given task has.
Any attempt as trying to display all these five in one consistent plot is IMHO
challenging, because such a plot should use a scale of equal severity for all
its axis, otherwise it becomes really hard to parse as an aggregate, no?
Regards
> On Aug 21, 2021, at 03:22, Kenneth Porter <sh...@sewingwitch.com> wrote:
>
> On 8/19/2021 6:58 PM, Dave Collier-Brown wrote:
>> Look at the barrel link, in that case: I'll send you a sketch off-list
>
> Ok, the sketch is of a spoked wheel with 3 spokes, for throughput, latency,
> and RPM, and the spoke for throughput is much longer. The circle represents
> the spoke of smallest radius, indicating the worst rating of the service. The
> ISP will try to sell based on the longest spoke to make itself look better
> than the actual user experience.
>
> It's like taking the barrel illustration and "exploding" the barrel so its
> staves lie flat, radiating from the base. In that case, the shortest stave is
> the worst rating.
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
