[Bismark-devel] about ready to do another build

Sat May 21 08:48:57 PDT 2011

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. 

- 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:
> 
> 64 bytes from 72.51.34.34: seq=0 ttl=44 time=706.813 ms
> 64 bytes from 72.51.34.34: seq=1 ttl=44 time=653.739 ms
> 64 bytes from 72.51.34.34: seq=2 ttl=44 time=616.698 ms
> 64 bytes from 72.51.34.34: seq=3 ttl=44 time=878.976 ms
> 64 bytes from 72.51.34.34: seq=4 ttl=44 time=844.259 ms
> 64 bytes from 72.51.34.34: seq=5 ttl=44 time=815.939 ms
> 64 bytes from 72.51.34.34: seq=6 ttl=44 time=825.318 ms
> 64 bytes from 72.51.34.34: seq=7 ttl=44 time=819.073 ms
> 64 bytes from 72.51.34.34: seq=8 ttl=44 time=886.615 ms
> 64 bytes from 72.51.34.34: seq=9 ttl=44 time=876.255 ms
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-12.3 sec   640 KBytes   426 Kbits/sec
> 
> with the revised numbers :
> 
> 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
> 
> 
> 64 bytes from 72.51.34.34: seq=11 ttl=44 time=313.169 ms
> 64 bytes from 72.51.34.34: seq=12 ttl=44 time=313.524 ms
> 64 bytes from 72.51.34.34: seq=13 ttl=44 time=314.121 ms
> 64 bytes from 72.51.34.34: seq=14 ttl=44 time=312.999 ms
> 64 bytes from 72.51.34.34: seq=15 ttl=44 time=313.931 ms
> 64 bytes from 72.51.34.34: seq=16 ttl=44 time=313.966 ms
> 64 bytes from 72.51.34.34: seq=17 ttl=44 time=312.992 ms
> 64 bytes from 72.51.34.34: seq=18 ttl=44 time=313.621 ms
> 64 bytes from 72.51.34.34: seq=19 ttl=44 time=406.354 ms
> 64 bytes from 72.51.34.34: seq=20 ttl=44 time=314.305 ms
> 64 bytes from 72.51.34.34: seq=21 ttl=44 time=313.683 ms
> 
> [  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
> 
> Tweaking the qos-script some got me to about 310Kbits/second, and I was going to bake that into the build.
> 
> 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 