I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

Fri Jul 22 22:05:18 UTC 2016

Just a quick clarifying reply, I have had DSL test give me an A for bufferbloat and a C for Speed on a 75 Meg line.

On July 22, 2016 3:23:00 PM EDT, Jim Gettys <jg at freedesktop.org> wrote:
>I don't read this list continually, but do archive it; your note was
>flagged for me to comment on.
>
>On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski <eric-list at truenet.com>
>wrote:
>
>> This is probably for Jim Gettys directly, but I’m sure most others
>have
>> input.  I could of sworn that that there was some test made to detect
>it
>> directly on switches and routers?  Sort of like iperf, but to test
>> bufferbloat specifically given the OS stack which is going to have
>issues
>> as well, as shown on bufferbloat.net <http://bufferbloat.net/>.
>>
>>
>We recommend Toke Høiland-Jørgensen's
>
> "flent" 
>
>https://flent.org/ for testing connections/devices/gear. It uses
>"netperf"
>transfers to load the link (by default with 4 simultaneous TCP
>connections
>in both directions, IIRC), and then runs another test (by default
>"ping")
>at the same time to test the connection under load.
>Turning on a netperf server is just as easy as turning on an iperf
>server
>(and the results are better, and netperf's maintainer responsive).
>
>See the documentation/paper on Toke's web site.  The "RRUL" test
>("Real-Time Response Under Load") is the one we use most/is best shaken
>down.   I'm sure Toke would love help with other tests.
>
>
>Gives you lots of useful graphs, will do diffserv marking, etc...
>
>
>> > On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG
><nanog at nanog.org>
>> wrote:
>> >
>> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <
>> nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:
>> >
>> >
>> >
>> >> ----- Original Message -----
>> >>> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>
>> >>
>> >>> Since this morning Speedtest.net is not accessible in Chrome
>> >>> Reason:
>> >>>
>>
>https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
>> >>>
>> >>> For any ISPs/content providers linking to speedtest.net you may
>want
>> to
>> >>> swap links to a different website or host your own speed test.
>> >>
>> >> So far, I am very pleased with how it works, though I think it's
>letter
>> >> grades on speed are a bit pessimistic (65Mbps is a "C").
>>
>
>
>Most applications are as sensitive/more sensitive to latency than to
>bandwidth
>; see the research in the field, for example, for web browsing.  For
>web
>browsing, you are at the point of diminishing returns on bandwidth
>after a
>few megabits/second, for most use
>.
>  For telephony, the metric is always the lower the better, and not
>more
>than 100ms or so (continental delay).
>
>So it is entirely appropriate in my view to give even "high speed"
>connections low grades; it's telling you that they suck under load
>, like when your kid is downloading a video (or uploading one for
>their
>friends); your performance (e.g. web surfing) can go to hell in a
>hand-basket despite having a lot of bandwidth on the
>connection. For most use, I'll take a 20Mbps link without bloat to a
>200Mbps one with a half second of bloat any
> 
>day.
> It will work reliably, I'll be able to make my phone calls without
>problems, I'll be able to frag my friends with the best of them, etc...
>Even video playback gets wonky with bad bufferbloat: the player's
>control
>loop is interacting with the (wildly excessive due to bloat) TCP
>control
>loop and can't find a good playback point; seeking also becomes slow,
>etc.
>
>Activities such as web browsing can/does cause transient latency on a
>link,
>since most links are not doing decent scheduling; the damage is done
>anytime the link gets used by anyone, for anything, including web
>surfing
>as well as background activities such as backup or system update.
>
>So no, I don't think dslreports grades pessimistically: it's just that
>bad
>bufferbloat is so *blinking* common and bad.  And I had nothing to do
>with
>setting the scoring system: that's the opinion of the dslreports test's
>author; but I think Justin has done a good job choosing the grades to
>boil
>down the quality of a connection to something mere mortals (your
>customer's) will understand.  So my hat is off to Justin for doing a
>great
>job.
>
>
>
>> >>
>> >> Specifically, it measures bufferbloat, with both a realtime graph
>and a
>> >
>> >
>> > Are you talking about the dslreports speedtest? I like that one,
>very
>> detailed results.
>> >
>> > http://speedtest.dslreports.com/
>> >
>> >
>> > I’d agree with the pessimistic scoring.. 160Mbit was given a “B”
>grade.
>> >
>> >
>> >
>> >
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.