[Bismark-devel] Latency under load in south africa

[Dave Taht]

The email server kicked back on this one thinking I was sending spam, due to
the IP addresses, resending...

On Sat, May 21, 2011 at 6:58 AM, Dave Taht <dave.taht at gmail.com> 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:
>
> 64 bytes from NICKINSOUTHAFRICA: seq=0 ttl=44 time=706.813 ms
>
> 64 bytes from NICKINSOUTHAFRICA: seq=3 ttl=44 time=878.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, ONLY
> 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=11 ttl=44 time=313.169 ms
> 64 bytes from NICKINSOUTHAFRICA: seq=12 ttl=44 time=313.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 <srikanth at 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
>> 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 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
>> 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 at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bismark-devel
>>
>>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bismark-devel/attachments/20110521/a2b1d12c/attachment.html>