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

[unsolicited]

Cedric Puddy wrote, On 03/07/2011 9:22 AM:
> 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 specifically 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.

Thank you for this.

A DOH! moment. Or, more likely, connecting the dots - as to WHICH
buffer is being referred to.

It's long been time to retire my venerable PIXie (501) - your note
just reinforces that, however, it's getting me by for the moment.

Since myth, lmce, asterisk, egroupware, et al, all want to be top dog
next to the ISP, I've long been intending to get around to a new box,
which would presumably solve this issue. But the learning curve, or
rather, curveS, makes it all a little daunting. But I recognize I'll
have to go through the learning curve / translation to the linux-speak
of what I already know one, hopefully LAST, time. Let alone the need
for a new subnet, migration strategy, and so on and so forth.

So many curves, so little time ...