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@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@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@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