The email server kicked back on this one thinking I was sending spam, due to the IP addresses, resending...<br><br><div class="gmail_quote">On Sat, May 21, 2011 at 6:58 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">This is the result of a simple latency under load test from Nick's site in South Africa (single threaded iperf + ping)<br>
with QoS disabled:<br><br>64 bytes from NICKINSOUTHAFRICA: seq=0 ttl=44 time=706.813 ms<br>
<br>64 bytes from NICKINSOUTHAFRICA: seq=3 ttl=44 time=878.976 ms<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[ ID] Interval Transfer Bandwidth<br>[ 3] 0.0-12.3 sec 640 KBytes 426 Kbits/sec<br><br>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...<br>
<br>TCP window size: 16.0 KByte (default)<br>------------------------------------------------------------<br>
[ 3] local NICKSITEINSA port 41609 connected with 149.20.54.82 port 5001<br>[ ID] Interval Transfer Bandwidth<br>[ 3] 0.0-11.3 sec 384 KBytes 279 Kbits/sec<br><br><br>64 bytes from NICKINSOUTHAFRICA: seq=11 ttl=44 time=313.169 ms<br>
64 bytes from NICKINSOUTHAFRICA: seq=12 ttl=44 time=313.524 ms<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br><div class="gmail_quote"><div class="im">On Sat, May 21, 2011 at 2:12 AM, Srikanth Sundaresan <span dir="ltr"><<a href="mailto:srikanth@gatech.edu" target="_blank">srikanth@gatech.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br></blockquote></div><div><br>Which is why we test.<br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<font color="#888888"><br></font></blockquote></div><div><br>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.<br>
<br>Without QoS enabled in some form, long last mile lines are effectively crippled in the first place. Worldwide. <br><br>In the above case, sans QoS:<br><br>DNS, NTP, UDP, etc are all delayed an extra <br><br>*half a second* <br>
<br>by the presence of a single TCP stream.<br><br>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.<br>
<br>Testing only in controlled settings, rather than in the field, is what has caused this problem in the first place.<br><br><br><br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888">
- Srikanth<br>
</font><div><div></div><div><br>
<br>
On May 21, 2011, at 12:12 AM, Nick Feamster wrote:<br>
<br>
> Srikanth, Walter --- please chime in.<br>
><br>
> Dave has a point here about the possibility of stopping QoS during testing.<br>
><br>
> Thoughts?<br>
><br>
> -Nick<br>
><br>
><br>
> On May 21, 2011, at 12:11 AM, Dave Taht wrote:<br>
><br>
>> And your customer experience will be poor, and you will be measuring tcp/ip malfunctioning rather than working properly.<br>
>><br>
>> How hard would it be for your scripts, when doing bandwidth testing, to do a<br>
>><br>
>> /etc/init.d/qos stop<br>
>> do the test<br>
>> /etc/init.d/qos start<br>
>><br>
>> When do they do bandwidth testing? What script does it?<br>
><br>
</div></div><div><div></div><div>> _______________________________________________<br>
> Bismark-devel mailing list<br>
> <a href="mailto:Bismark-devel@lists.bufferbloat.net" target="_blank">Bismark-devel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bismark-devel" target="_blank">https://lists.bufferbloat.net/listinfo/bismark-devel</a><br>
<br>
</div></div></blockquote></div></div><br><br clear="all"><br>-- <br><div><div></div><div class="h5">Dave Täht<br>SKYPE: davetaht<br>US Tel: <a href="tel:1-239-829-5608" value="+12398295608" target="_blank">1-239-829-5608</a><br>
<a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>