Hey there is nothing wrong with Megapath ! they were my second ISP after Northpoint went bust.
If I had a time machine, and went back to 2001, I'd be very happy with Megapath.. :)
Anyway Rich has some good ideas for how to display the latency during the test progress and yes
that is the plan, to do that.
The results page, for the sake of non-confusion by random people, does just show the smoothed
line and not the instant download speeds. I'm not confident enough that the instant speeds
relate 1:1 with what is going on at your interface as unfortunately modern browsers don't
give nearly enough feedback on how uploads are going compared to how they instrument
downloads - which are almost on a packet by packet level. You would hope they would pass
back events regularly but unless then line is pretty fast, they don't. They go quiet and catch up
and meanwhile the actual upload might be steady.
The retransmit stats and congestion window and other things come from the linux tcp structures
on the server side. Retransmits are not necessarily lost packets, it can just be TCP getting confused by
a highly variable RTT and re-sending too soon. But on a very good connection (google fiber) that
column is 0%. On some bad connections, it can be 20%+ Often it is between 1 and 3%.
Yes the speed test is trying to drive the line to capacity but not force feeding, it is just TCP after
all, and all streams should find their relative place in the available bandwidth and lost packets
should be rare when the underlying network is good quality. At least, that is what I've seen. I'm
far from understanding the congestion algorithms etc. However I did find it somewhat surprising
that whether one stream or 20, it all sort of works out with roughly the same efficiency.
With more data I think the re-transmits and other indicators can just show real problems, even
despite that the test tends to (hopefully) find your last mile sync speed and drive it to capacity.
-justin