In one of the threads I saw that the dslreports test is one http ping every second. I am not really sure how that is handled - if the connection is tcp (?) and persistent, that measures 1 packet RTT, if it is a new connection, it is quite a few RTTs.
And it is really not enough pings for valid statistical sampling. IF tcp, It would be vastly better to attempt a tcp ping every 10ms on an established connection (or whatever can be achieved, with 20ms being a good interval for most voip, 100ms seems easily doable, but...). This would accomplish two things: 1) A single packet loss would not cause a RTO (usually 250ms) but be flushed out (resent) on the next packet sent. So you would see replies get bunched in relation to loss and delay. 2) More pings more accurately track actual latency over a much tighter interval in general, particularly during the slow start phases at the beginning of the test where things tend to get really out of hand when you fire up tons of flows. In terms of plotting, I am quite fond of smokeping's methods, so you could still show the bar chart on a per second basis, but colored as per smokeping. (It had been my hope to one day leverage the webrtc apis to be able to test udp.) On what interval is it feasible to fire off a new http ping, and can the difference between a persistent connection and a new one be determined from within the browser? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
