From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from deliverator2.gatech.edu (deliverator2.gatech.edu [130.207.160.69]) by huchra.bufferbloat.net (Postfix) with ESMTP id 1CA11200648 for ; Sat, 21 May 2011 08:40:48 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B66084801DA; Sat, 21 May 2011 11:52:50 -0400 (EDT) Received: from deliverator2.gatech.edu by deliverator2.gatech.edu with queue id 1747478-2; Sat, 21 May 2011 15:52:19 GMT Received: from mail2.gatech.edu (mail2.gatech.edu [130.207.185.162]) by deliverator2.gatech.edu (Postfix) with ESMTP id 3A12E4801DA; Sat, 21 May 2011 11:52:19 -0400 (EDT) Received: from [10.0.0.200] (196-215-46-233.dynamic.isadsl.co.za [196.215.46.233]) (Authenticated sender: ssundaresan3) by mail2.gatech.edu (Postfix) with ESMTPSA id 4B5D4185DDC; Sat, 21 May 2011 11:50:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Srikanth Sundaresan In-Reply-To: Date: Sat, 21 May 2011 17:48:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EFCAA58-92E8-45FD-9BE4-F213564264E6@cc.gatech.edu> <5C1FCBFC-B007-4B01-A7BA-6CCD5523DC34@cc.gatech.edu> <72E30C46-3045-4FBA-A464-C7120C3FECE2@gatech.edu> To: Dave Taht X-Mailer: Apple Mail (2.1082) 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 15:40:48 -0000 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.=20 - Srikanth On May 21, 2011, at 2:58 PM, Dave Taht wrote: > This is the result of a simple latency under load test from Nick's = site in South Africa (single threaded iperf + ping) > with QoS disabled: >=20 > 64 bytes from 72.51.34.34: seq=3D0 ttl=3D44 time=3D706.813 ms > 64 bytes from 72.51.34.34: seq=3D1 ttl=3D44 time=3D653.739 ms > 64 bytes from 72.51.34.34: seq=3D2 ttl=3D44 time=3D616.698 ms > 64 bytes from 72.51.34.34: seq=3D3 ttl=3D44 time=3D878.976 ms > 64 bytes from 72.51.34.34: seq=3D4 ttl=3D44 time=3D844.259 ms > 64 bytes from 72.51.34.34: seq=3D5 ttl=3D44 time=3D815.939 ms > 64 bytes from 72.51.34.34: seq=3D6 ttl=3D44 time=3D825.318 ms > 64 bytes from 72.51.34.34: seq=3D7 ttl=3D44 time=3D819.073 ms > 64 bytes from 72.51.34.34: seq=3D8 ttl=3D44 time=3D886.615 ms > 64 bytes from 72.51.34.34: seq=3D9 ttl=3D44 time=3D876.255 ms > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-12.3 sec 640 KBytes 426 Kbits/sec >=20 > with the revised numbers : >=20 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.1.106 port 41609 connected with 149.20.54.82 port = 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-11.3 sec 384 KBytes 279 Kbits/sec >=20 >=20 > 64 bytes from 72.51.34.34: seq=3D11 ttl=3D44 time=3D313.169 ms > 64 bytes from 72.51.34.34: seq=3D12 ttl=3D44 time=3D313.524 ms > 64 bytes from 72.51.34.34: seq=3D13 ttl=3D44 time=3D314.121 ms > 64 bytes from 72.51.34.34: seq=3D14 ttl=3D44 time=3D312.999 ms > 64 bytes from 72.51.34.34: seq=3D15 ttl=3D44 time=3D313.931 ms > 64 bytes from 72.51.34.34: seq=3D16 ttl=3D44 time=3D313.966 ms > 64 bytes from 72.51.34.34: seq=3D17 ttl=3D44 time=3D312.992 ms > 64 bytes from 72.51.34.34: seq=3D18 ttl=3D44 time=3D313.621 ms > 64 bytes from 72.51.34.34: seq=3D19 ttl=3D44 time=3D406.354 ms > 64 bytes from 72.51.34.34: seq=3D20 ttl=3D44 time=3D314.305 ms > 64 bytes from 72.51.34.34: seq=3D21 ttl=3D44 time=3D313.683 ms >=20 > [ 3] local 192.168.1.106 port 41609 connected with 149.20.54.82 port = 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-11.3 sec 384 KBytes 279 Kbits/sec >=20 > Tweaking the qos-script some got me to about 310Kbits/second, and I = was going to bake that into the build. >=20 > On Sat, May 21, 2011 at 2:12 AM, Srikanth Sundaresan = wrote: > My concern about QoS is that without knowing the exact connection, = it's pretty useless. If the QoS settings are less ( I think it's set to = 128K up, I see 500k up in my hotel), then it's overly restrictive. If = it's set to more than that, then it's useless as it never is activated. = With long last mile DSL lines, which I think is the default here, it's = impossible to predict the actual connection parameters, even if we knew = the exact SLA. >=20 >=20 > Which is why we test. >=20 > It's easy enough to disable QoS during testing. More important than = our testing is to make sure we don't cripple the internet connection. = Unless the QoS setting is adaptive, I am opposed to turning it on unless = we test it in a more controlled setting first. >=20 >=20 > I agree it should be somehow adaptive. Having results with QoS on and = off makes it possible to have data to provide that to the users and for = researchers to work on better QoS systems. >=20 > Without QoS enabled in some form, long last mile lines are effectively = crippled in the first place. Worldwide.=20 >=20 > In the above case, sans QoS: >=20 > DNS, NTP, UDP, etc are all delayed an extra=20 >=20 > *half a second*=20 >=20 > by the presence of a single TCP stream. >=20 > Multiple streams, such as you get by typing a single letter into = google's front page with the interactive feature on, would also suffer, = as (for example) the last one I tried issued 37 DNS lookups to load the = page. >=20 > Testing only in controlled settings, rather than in the field, is what = has caused this problem in the first place. >=20 >=20 >=20 > - Srikanth >=20 >=20 > On May 21, 2011, at 12:12 AM, Nick Feamster wrote: >=20 >> Srikanth, Walter --- please chime in. >>=20 >> Dave has a point here about the possibility of stopping QoS during = testing. >>=20 >> Thoughts? >>=20 >> -Nick >>=20 >>=20 >> On May 21, 2011, at 12:11 AM, Dave Taht wrote: >>=20 >>> And your customer experience will be poor, and you will be measuring = tcp/ip malfunctioning rather than working properly. >>>=20 >>> How hard would it be for your scripts, when doing bandwidth testing, = to do a >>>=20 >>> /etc/init.d/qos stop >>> do the test >>> /etc/init.d/qos start >>>=20 >>> When do they do bandwidth testing? What script does it? >>=20 >> _______________________________________________ >> Bismark-devel mailing list >> Bismark-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bismark-devel >=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com=20