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