From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A1FB6200648 for ; Sat, 21 May 2011 09:37:22 -0700 (PDT) Received: by iwn8 with SMTP id 8so5843596iwn.16 for ; Sat, 21 May 2011 09:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V1fqVbQ3V061rkmcKaLdWEvSf4t/pTDIA/JcQX4z9sE=; b=UTDJ50RGllLki6wY1ru0gTOX4TXDs845jONAuZER4DsrckeQ1DBrEiXdIZIeaHl0fs aOvTSL5CCYsFWy0r9+1B8Am4X0CH8/KOj17RCWNrE2KRRQloW0dedMlh4l6rzRLN/edR TzQOfh5ZDzbmxvjjkSpLDEeBByDTu3vxZXz3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=knx/16WQ+a6o1x4OxfVOjCACXjy5m5ifqG0Tw8zU++kRnpf9KdiWLesgbDQN1jycEE SBv7RtX4XlIaminI+jpNeec1R3Trj9rSmWq7zWXNhQ45PTfTH7rMgZNgZzF/u8yy6me3 3+XACns5qzgFfx62Osb+VnuIjl6+hscuMWFyM= MIME-Version: 1.0 Received: by 10.43.47.195 with SMTP id ut3mr6039731icb.426.1305996566305; Sat, 21 May 2011 09:49:26 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Sat, 21 May 2011 09:49:26 -0700 (PDT) In-Reply-To: <58F7BFB9-8382-427A-986C-5FAFB90A8DD4@gatech.edu> References: <9EFCAA58-92E8-45FD-9BE4-F213564264E6@cc.gatech.edu> <5C1FCBFC-B007-4B01-A7BA-6CCD5523DC34@cc.gatech.edu> <72E30C46-3045-4FBA-A464-C7120C3FECE2@gatech.edu> <58F7BFB9-8382-427A-986C-5FAFB90A8DD4@gatech.edu> Date: Sat, 21 May 2011 10:49:26 -0600 Message-ID: From: Dave Taht To: Srikanth Sundaresan Content-Type: multipart/alternative; boundary=bcaec5299591699a2f04a3cc05e9 Cc: bismark-devel@lists.bufferbloat.net Subject: Re: [Bismark-devel] about ready to do another build X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 16:37:22 -0000 --bcaec5299591699a2f04a3cc05e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan 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> wrote: > > I do not have a problem with it when we know the effective bandwidth. M= y > 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 ide= a > about each user's bandwidth. THis is feature that, in its current form ne= eds > 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 bull= s > 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 user= s 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. Certainly chats with network operators and cybercafe operators down there will also prove fruitful. If you could exit the hotel and see if you can obtain some information from the real world around you down there about those kinds of usage, (or non-usage) of QoS techniques on their systems... you might get some really good coffee and meet some interesting people. Lastly your results pointed to a knee in the curves that I was not aware of= , that happens at 256kbit, which is perilously close to the speeds you are encountering down there. I was getting about 12% overall single-threaded performance loss and nearly flat utilization with multi-threaded, while retaining good dns performance, with the existing scripts set to both 24Mbi= t and with them set to 1000/100, I was not aware of this knee until I got som= e data back from the field yesterday and had a chance to look it over this morning. I'm simulating it in the lab (or will be whenever I get there), an= d can hopefully do better. See the ongoing bug: http://www.bufferbloat.net/issues/171 > - Srikanth > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --bcaec5299591699a2f04a3cc05e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, May 21, 2011 at 10:33 AM, Srikan= th Sundaresan <= 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> 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 r= eliable information on that.
>
> I say we turn it *on only while testing*. That too, after we get an id= ea about each user's bandwidth. THis is feature that, in its current fo= rm needs to be tailored to each user. It is not a good idea to give everyon= e a default setting - as I mentioned in my previous email, unless we hit bu= lls 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= =A0a degraded user experience?

If the cost of reduced upload speed, =A0which 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&#= 39;s the higher price to pay than reduced latency.


I would urge you s= trongly to do more realistic testing, with more real users using the networ= k...

...before making that call. I am assuming you are unleashing th= ese 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.

Certainly chat= s with network operators and cybercafe operators down there will also prove= fruitful.

If you could exit the hotel and see if you can obtain some information = from the real world around you down there about those kinds of usage, (or n= on-usage) of QoS techniques on their systems...

you might get some r= eally good coffee and meet some interesting people.

Lastly your results pointed to a knee in the curves that I was not awar= e of, that happens at 256kbit, which is perilously close to the speeds you = are encountering down there. I was getting about 12% overall single-threade= d performance loss and nearly flat utilization with multi-threaded, while r= etaining good dns performance, with the existing scripts set to both 24Mbit= and with them set to 1000/100, I was not aware of this knee until I got so= me data back from the field yesterday and had a chance to look it over this= morning. I'm simulating it in the lab (or will be whenever I get there= ), and can hopefully do better.

See the ongoing bug:

http://www.bufferbloat.net/issues/171

=A0
- Srikanth




--
Dave T=E4ht
S= KYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--bcaec5299591699a2f04a3cc05e9--