Re: [Bismark-devel] about ready to do another build

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On 05/21/2011 12:49 PM, Dave Taht wrote:
>
>
> On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan 
> <srikanth@gatech.edu <mailto:srikanth@gatech.edu>> wrote:
>
>
>     On May 21, 2011, at 6:08 PM, Dave Taht wrote:
>
>     >
>     >
>     > On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan
>     <srikanth@gatech.edu <mailto:srikanth@gatech.edu>> wrote:
>     > I do not have a problem with it when we know the effective
>     bandwidth. My question is, what when do not? We cannot rely on
>     volunteers to give us reliable information on that.
>     >
>     > I say we turn it *on only while testing*. That too, after we get
>     an idea about each user's bandwidth. THis is feature that, in its
>     current form needs to be tailored to each user. It is not a good
>     idea to give everyone a default setting - as I mentioned in my
>     previous email, unless we hit bulls eye (unlikely), it is either
>     crippling, or useless.
>     >
>     > It could potentially seriously downgrade user experience.
>     >
>     >
>     > What part about 800ms latencies under load without QoS isn't
>     about  a degraded user experience?
>
>     If the cost of reduced upload speed,  which could perhaps be as
>     much as 30%, (if the default is 340kbps - the DSL connection here
>     in my B&B gets up to 450k), can't be reduced, I certainly think
>     that it's the higher price to pay than reduced latency.
>
>
> I would urge you strongly to do more realistic testing, with more real 
> users using the network...
>
> ...before making that call. I am assuming you are unleashing these 
> devices on real users? with more than one person on the network?
>
> RTT times will probably get even worse than 800ms with multiple 
> streams running. I have not tested that, I'll get to it.
>

Take a look at the ISCI data on bufferbloat. The colour versions are in: 
http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/  
You can get an explanation for the structure you will see from the 
Netalyzr papers. The diagonal lines show the potential latency, and the 
"green" line of .5 seconds is already 3x telephony standards.  So a high 
fraction of the internet has serious bloat problems.

Several things:

1) the dataset *underdetected* the problem: there was a bug in Netalyzr 
only detected last October (and the dataset covers most of 2010 and back 
into 2009).  So the situation is worse than that shown.  How much, we 
don't know.

2) the amount of bloat varies *all* over; some DSL lines are up in the 6 
second range.

3) the amount of buffering is fixed: so the lower the provisioning, the 
longer the latency on the same devices.  I was seeing > 1.2 seconds on 
20Mbps cable, at which point web surfing is painful indeed.

4) If the bottleneck is elsewhere, then the broadband connection 
bufferbloat isn't the buffers that will affect the results.  So if the 
backhaul is lower bandwidth than the broadband/wireless connections, 
then the problem will be in the network routers, where RED (if enabled!) 
can control it.

I call the problem the "Daddy, the Internet is slow today" problem: I 
was usually the person who was causing saturation on the line, so when 
my family was experiencing slowdowns, they would come to me and I'd try 
to debug it, and stop whatever it was that was doing them in.  Who may 
be saturating the link most often varies from household to household: 
bittorrent can induce bufferbloat suffering.

Now, what you do is for you to determine; just understand the 
bufferbloat problem is extremely common and extremely variable.  Your 
mileage *will* vary.
                     - Jim




[-- Attachment #2: Type: text/html, Size: 5532 bytes --]