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 <j...@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-l...@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@nanog.org> >> wrote: >> > >> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" < >> nanog-boun...@nanog.org on behalf of j...@baylink.com> wrote: >> > >> > >> > >> >> ----- Original Message ----- >> >>> From: "Janusz Jezowicz" <jan...@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.
