[kwlug-disc] netalyzr/ispgeeks interpreting [was: Re: Reliable Broadband speed test]

[Cedric Puddy]

On 2011-03-05, at 7:51 PM, unsolicited wrote:

> Cedric Puddy wrote, On 03/04/2011 2:51 PM:
>> ispgeeks.com has a speed test that exposes more of the underlying
>> data from which speed estimates are typically derived, so I usually
>> use theirs -- it gives me enough additional information that I can
>> you usually get a bit better idea of how the line is actually
>> performing.
>> The http://netalyzr.icsi.berkeley.edu/ also identifies lots of
>> interesting potential issues that could be holding up the train on
>> a given broadband link (including buffer-bloat).
> 
> OK, that's just way cool.
> 
> Interestingly:
> <<<<<
> Network buffer measurements (?): Uplink 1100 ms, Downlink is good
> 
> We estimate your uplink as having 1100 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
> >>>>>
> 
> Is this an allusion to the asynchronous nature of the (ISP) service? [8/512]. i.e. Rogers is accomplishing upload rate limiting via buffering / dropping?

No, this talking specificly about buffering on (probably) your router.  When you go and send a stream of packets at a rate higher than your connection speed, your router has two choices:
	a) use memory (a buffer) to queue up the packets, and then flush out that buffer as quickly as it can given the speed of the connection that it has to send them over
	b) start refusing packets

If it does (a), then the important question is "how much data will it queue up?".  If you've got a 512 kbit/sec upstream, and you go and queue up 768 kbits, then it's obviously going to take more than 1000 ms for it to work through that queue, assuming that no other packets are attempted to be sent in the meantime etc.  Besides that, unless you are running QoS, generally queues are not re-ordered after the fact so once a packet tags onto the end of that huge queue, then it's going to take 1+ seconds before it escapes.

On the other hand, if the router would limit it's queue to ~100 or 200 ms of data (queue some debates about the best number!), and just start refusing packets (there are various algorithms to determine which packets to drop), then the TCP congestion control mechanisms would do their work, and you'd get a much more responsive connection.

Check out the The Bufferbloat Project at http://www.bufferbloat.net/projects/bloat/ if you are interested in seeing what some of the active work on this issue looks like.

-Cedric


>> Between those two tools, you can get a pretty good idea of the
>> state of the nation.
> 
> ispgeeks.com is, indeed, interesting. Thank you for both links.
> 
>> Naturally, old habits die hard, and I've often typed
>> http://speakeasy.net/speedtest too... :)
> 
> Yeah, but often because digging out an ISP's own accepted test mechanisms / results criteria can be such a miserably hard process. After all, if they don't tell you what they use, when you call and complain they dismiss the legitimacy of your tests. But when you use their recognized tests, then they might actually have to do or investigate something. Just remember their good ol' fall back - we only promise speeds *up to*.
> 
> Remembering that the OP question stemmed from home use - usually the connectivity / speed questions are 'connecting?' and 'reasonable speed to ISP?'. 'cause after that, all bets are off, there is no control, and there is no choice. [You're trying to get somewhere particular, there's no alternative, and the ISP disavows that anything has anything to do with them.]
> 
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org

|  CCj/ClearLine - Unix/NT Administration and TCP/IP Network Services
|  118 Louisa Street, Kitchener, Ontario, N2H 5M3, 519-489-0478
\________________________________________________________
   Cedric Puddy, IS Director            cedric at thinkers.org
     PGP Key Available at:              http://www.thinkers.org/cedric