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 6628D2004FF for ; Sat, 21 May 2011 05:54:20 -0700 (PDT) Received: by iwn8 with SMTP id 8so5716298iwn.16 for ; Sat, 21 May 2011 06:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=VafehOvkCR1TxKeMY2Mhr4hl9buG94pAgZBj9jR9iAo=; b=mEbUSPwJQcB6KYiup57tLSekySfD3LzIwCGzhDrDwv19yUbiJoA8EyUD2IpwJx0r0h asBXC/qW/PxqFSeYvX4guVebcsnhKFt6sXSZMDAh46OHz7lOlwGMVV8QQP/7lknRiGdG lnYLLMYwY619PlzE6O8R4WAfCtYJ5ZuQdzx4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EllEMGp7+s+PzNjsomYpbWm6FE86VOuQqv1SC5sgmKtjwlprxAi8pL43Pd+FK/5LVN Yeipx7KT3pgWKiRwMpciY7FbEJelRk/UOS102CkHlRD0fGvbT5IOgh1EANVCt/xhOrWG D60QX0RC7qFj5pHF8qE3uRCSRv1fZv9tu0+54= MIME-Version: 1.0 Received: by 10.42.131.71 with SMTP id y7mr2230326ics.292.1305983178027; Sat, 21 May 2011 06:06:18 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Sat, 21 May 2011 06:06:17 -0700 (PDT) Date: Sat, 21 May 2011 07:06:17 -0600 Message-ID: From: Dave Taht To: bismark-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=90e6ba21217368b10904a3c8e7f6 Subject: [Bismark-devel] Latency under load in south africa 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 12:54:20 -0000 --90e6ba21217368b10904a3c8e7f6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The email server kicked back on this one thinking I was sending spam, due t= o the IP addresses, resending... On Sat, May 21, 2011 at 6:58 AM, Dave Taht wrote: > This is the result of a simple latency under load test from Nick's site i= n > South Africa (single threaded iperf + ping) > with QoS disabled: > > 64 bytes from NICKINSOUTHAFRICA: seq=3D0 ttl=3D44 time=3D706.813 ms > > 64 bytes from NICKINSOUTHAFRICA: seq=3D3 ttl=3D44 time=3D878.976 ms > > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-12.3 sec 640 KBytes 426 Kbits/sec > > with the revised numbers I've tossed into the QoS scripts - and NOTE, ONL= Y > a 16KByte window size was used on both tests, which is bad... > > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local NICKSITEINSA 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 > > > 64 bytes from NICKINSOUTHAFRICA: seq=3D11 ttl=3D44 time=3D313.169 ms > 64 bytes from NICKINSOUTHAFRICA: seq=3D12 ttl=3D44 time=3D313.524 ms > Tweaking the current qos-script some got me to about 310Kbits/second, and I > was going to bake that into the build last night... but didn't. > > 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 la= st >> 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. >> >> > Which is why we test. > > >> 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. >> >> > 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. > > Without QoS enabled in some form, long last mile lines are effectively > crippled in the first place. Worldwide. > > In the above case, sans QoS: > > DNS, NTP, UDP, etc are all delayed an extra > > *half a second* > > by the presence of a single TCP stream. > > 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. > > Testing only in controlled settings, rather than in the field, is what ha= s > caused this problem in the first place. > > > > - Srikanth >> >> >> On May 21, 2011, at 12:12 AM, Nick Feamster wrote: >> >> > Srikanth, Walter --- please chime in. >> > >> > Dave has a point here about the possibility of stopping QoS during >> testing. >> > >> > Thoughts? >> > >> > -Nick >> > >> > >> > On May 21, 2011, at 12:11 AM, Dave Taht wrote: >> > >> >> And your customer experience will be poor, and you will be measuring >> tcp/ip malfunctioning rather than working properly. >> >> >> >> How hard would it be for your scripts, when doing bandwidth testing, = to >> do a >> >> >> >> /etc/init.d/qos stop >> >> do the test >> >> /etc/init.d/qos start >> >> >> >> When do they do bandwidth testing? What script does it? >> > >> > _______________________________________________ >> > Bismark-devel mailing list >> > Bismark-devel@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/bismark-devel >> >> > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --90e6ba21217368b10904a3c8e7f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The email server kicked back on this one thinking I was sending spam, due t= o the IP addresses, resending...

On Sat, = May 21, 2011 at 6:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
This is the resul= t of a simple latency under load test from Nick's site in South Africa = (single threaded iperf + ping)
with QoS disabled:

64 bytes from NICKINSOUTHAFRICA: seq=3D0 ttl=3D44= time=3D706.813 ms

64 bytes from NICKINSOUTHAFRICA: seq=3D3 ttl=3D44 time=3D878.976 ms
=
=A0
[ ID] Interval=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bandwidth
[=A0 3]= =A0 0.0-12.3 sec=A0=A0 640 KBytes=A0=A0 426 Kbits/sec

with the revis= ed numbers I've tossed into the QoS scripts - and NOTE, ONLY a 16KByte = window size was used on both tests, which is bad...

TCP window size: 16.0 KByte (default)
------------------------------= ------------------------------
[=A0 3] local NICKSITEINSA port 41609 connected with 149.20.54.82 port 5001=
[ ID] Interval=A0=A0=A0=A0=A0=A0 Transfer=A0=A0=A0=A0 Bandwidth
[=A0= 3]=A0 0.0-11.3 sec=A0=A0 384 KBytes=A0=A0 279 Kbits/sec


64 byte= s from NICKINSOUTHAFRICA: seq=3D11 ttl=3D44 time=3D313.169 ms
64 bytes from NICKINSOUTHAFRICA: seq=3D12 ttl=3D44 time=3D313.524 ms

Twe= aking the current qos-script some got me to about 310Kbits/second, and I wa= s going to bake that into the build last night... but didn't.

On Sat, May 21, 2011 at 2:= 12 AM, Srikanth Sundaresan <srikanth@gatech.edu> 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 m= ile DSL lines, which I think is the default here, it's impossible to pr= edict the actual connection parameters, even if we knew the exact SLA.


Which is why we test.
=A0
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. Unle= ss the QoS setting is adaptive, I am opposed to turning it on unless we tes= t it in a more controlled setting first.


I agree it s= hould be somehow adaptive. Having results with QoS on and off makes it poss= ible to have data to provide that to the users and for researchers to work = on better QoS systems.

Without QoS enabled in some form, long last mile lines are effectively = crippled in the first place. Worldwide.

In the above case, sans QoS= :

DNS, NTP, UDP, etc are all delayed an extra

*half a second= *

by the presence of a single TCP stream.

Multiple streams, such a= s you get by typing a single letter into google's front page with the i= nteractive feature on, would also suffer, as (for example) the last one I t= ried issued 37 DNS lookups to load the page.

Testing only in controlled settings, rather than in the field, is what = has caused this problem in the first place.



- Srikanth


On May 21, 2011, at 12:12 AM, Nick Feamster wrote:

> Srikanth, Walter --- please chime in.
>
> Dave has a point here about the possibility of stopping QoS during tes= ting.
>
> Thoughts?
>
> -Nick
>
>
> On May 21, 2011, at 12:11 AM, Dave Taht wrote:
>
>> And your customer experience will be poor, and you will be measuri= ng tcp/ip malfunctioning rather than working properly.
>>
>> How hard would it be for your scripts, when doing bandwidth testin= g, to do a
>>
>> /etc/init.d/qos stop
>> do the test
>> /etc/init.d/qos start
>>
>> When do they do bandwidth testing? What script does it?
>
> _____________________________________= __________
> Bismark-devel mailing list
> Bismark-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bismark-devel




--
=
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-8= 29-5608
http://the-edge.= blogspot.com



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--90e6ba21217368b10904a3c8e7f6--