Fiber optic speed test.

Char Jackson wrote:

As above, the route is irrelevant. The aim is to measure end to end
throughput.

Uh huh. The responsiveness of each node in the current route has no
effect on the end-to-end speed test. Those nodes always have the same
lag to transfer the traffic, never vary by the time of day, never have
varying loads. Uh huh. The route is VERY relevant. The nodes you get
affects the speed test.

On Fri, 15 Nov 2019 00:43:15 -0600, VanguardLH wrote:

Char Jackson wrote:

As above, the route is irrelevant. The aim is to measure end to end
throughput.

Uh huh. The responsiveness of each node in the current route has no
effect on the end-to-end speed test. Those nodes always have the same
lag to transfer the traffic, never vary by the time of day, never have
varying loads. Uh huh. The route is VERY relevant. The nodes you get
affects the speed test.

You missed the point. I'll try again. You have no control over the route
that your traffic takes. You have no control over the first packet, the
second packet, or any of the subsequent packets, and each packet needs to
find its own way from the server to you. It's possible that no two packets
take the exact same path.

Given that, how do you propose that a speed test tool would show you the
path that each of some large number of packets took? Would you like to
see it in a tabular display, a graphical representation, or what? And what
would you do with that information? How would it help you?

Yes, the route(s) that packets take are relevant to the speed that you see,
but since there could be thousands of different routes during a single
speed test, each of which you can't control and can't see, you have to let
it go and focus on the end to end aspect of the test. That is the important
part. Internet routing is beyond your control.

You snipped everything else, so I assume it was all helpful to you.

Char Jackson wrote:

On Fri, 15 Nov 2019 00:43:15 -0600, VanguardLH wrote:

Char Jackson wrote:

As above, the route is irrelevant. The aim is to measure end to end
throughput.

Uh huh. The responsiveness of each node in the current route has no
effect on the end-to-end speed test. Those nodes always have the same
lag to transfer the traffic, never vary by the time of day, never have
varying loads. Uh huh. The route is VERY relevant. The nodes you get
affects the speed test.

You missed the point. I'll try again. You have no control over the route
that your traffic takes. You have no control over the first packet, the
second packet, or any of the subsequent packets, and each packet needs to
find its own way from the server to you. It's possible that no two packets
take the exact same path.

Given that, how do you propose that a speed test tool would show you the
path that each of some large number of packets took? Would you like to
see it in a tabular display, a graphical representation, or what? And what
would you do with that information? How would it help you?

Yes, the route(s) that packets take are relevant to the speed that you see,
but since there could be thousands of different routes during a single
speed test, each of which you can't control and can't see, you have to let
it go and focus on the end to end aspect of the test. That is the important
part. Internet routing is beyond your control.

You snipped everything else, so I assume it was all helpful to you.

Yep, I get your point that you have no control over the routing. It
sounded like the particular route(s) in a test and changes for the next
test wouldn't have any effect. Looks like we agree.

VanguardLH wrote:
Char Jackson wrote:

As above, the route is irrelevant. The aim is to measure end to end
throughput.

Uh huh. The responsiveness of each node in the current route has no
effect on the end-to-end speed test. Those nodes always have the same
lag to transfer the traffic, never vary by the time of day, never have
varying loads. Uh huh. The route is VERY relevant. The nodes you get
affects the speed test.

Latency and bandwidth are two different things.

The reason we use Speedtest.net, is we like to see
the "contracted bandwidth" on display. Because usually,
the latency of the service, isn't in the adverts for
the service. Only the bandwidth seems to matter.

But people seldom think of the latency and latency distribution
as factors, and those ruin web surfing. And more of your
day is spent web surfing, than downloading.

This is why nobody wants to be caught dead on Hughes Satellite.
It's the latency. And the effect on web surfing (which
accesses way too many sites, in order to render a single
web page).

Just as bad DNS implementations at your ISP, can
ruin a web surfing experience (until you switch
to something else for DNS).

The latency at my ISP, has dropped by half, since
the service was first set up years ago. The routing
used at the time, was absurd (pony express absurd).

Paul