The email server kicked back on this one thinking I was sending spam, due to the IP addresses, resending...
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
--