<br><br><div class="gmail_quote">On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan <span dir="ltr"><<a href="mailto:srikanth@gatech.edu">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;">
<div><div></div><div class="h5"><br>
On May 21, 2011, at 6:08 PM, Dave Taht wrote:<br>
<br>
><br>
><br>
> On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan <<a href="mailto:srikanth@gatech.edu">srikanth@gatech.edu</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>

><br>
> It could potentially seriously downgrade user experience.<br>
><br>
><br>
> What part about 800ms latencies under load without QoS isn't about  a degraded user experience?<br>
<br>
</div></div>If the cost of reduced upload speed,  which could perhaps be as much as 30%, (if the default is 340kbps - the DSL connection here in my B&B gets up to 450k), can't be reduced, I certainly think that it's the higher price to pay than reduced latency.<br>

<font color="#888888"><br></font></blockquote><div><br>I would urge you strongly to do more realistic testing, with more real users using the network...<br><br>...before making that call. I am assuming you are unleashing these devices on real users? with more than one person on the network?<br>
<br>RTT times will probably get even worse than 800ms with multiple streams running. I have not tested that, I'll get to it.<br><br>Certainly chats with network operators and cybercafe operators down there will also prove fruitful. <br>
<br>If you could exit the hotel and see if you can obtain some information from the real world around you down there about those kinds of usage, (or non-usage) of QoS techniques on their systems...<br><br>you might get some really good coffee and meet some interesting people.<br>
<br>Lastly your results pointed to a knee in the curves that I was not aware of, that happens at 256kbit, which is perilously close to the speeds you are encountering down there. I was getting about 12% overall single-threaded performance loss and nearly flat utilization with multi-threaded, while retaining good dns performance, with the existing scripts set to both 24Mbit and with them set to 1000/100, I was not aware of this knee until I got some data back from the field yesterday and had a chance to look it over this morning. I'm simulating it in the lab (or will be whenever I get there), and can hopefully do better.<br>
<br>See the ongoing bug:<br><br><a href="http://www.bufferbloat.net/issues/171">http://www.bufferbloat.net/issues/171</a><br><br> <br></div><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>
<br>
</font></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>