<div dir="ltr">I've discovered something perhaps you guys can explain it better or shed some light.<div>It isn't specifically to do with buffer bloat but it is to do with TCP tuning.<br></div><div><div><br></div><div>Attached is two pictures of my upload to New York speed test server with 1 stream.</div><div>It doesn't make any difference if it is 1 stream or 8 streams, the picture and behaviour remains the same.</div><div>I am 200ms from new york so it qualifies as a fairly long (but not very fat) pipe.</div><div><br></div><div>The nice smooth one is with linux tcp_rmem set to '4096 32768 65535' (on the server)</div><div>The ugly bumpy one is with linux tcp_rmem set to '4096 65535 67108864' (on the server)</div><div><br></div><div>It actually doesn't matter what that last huge number is, once it goes much about 65k, e.g. 128k or 256k or beyond things get bumpy and ugly on the upload speed.</div><div><br></div><div>Now as I understand this setting, it is the tcp receive window that Linux advertises, and the last number sets the maximum size it can get to (for one TCP stream).</div><div><br></div><div>For users with very fast upload speeds, they do not see an ugly bumpy upload graph, it is smooth and sustained.</div><div>But for the majority of users (like me) with uploads less than 5 to 10mbit, we frequently see the ugly graph.</div><div><br></div><div>The second tcp_rmem setting is how I have been running the speed test servers.</div><div><br></div><div>Up to now I thought this was just the distance of the speedtest from the interface: perhaps the browser was buffering a lot, and didn't feed back progress but now I realise the bumpy one is actually being influenced by the server receive window.</div><div><br></div><div>I guess my question is this: Why does ALLOWING a large receive window appear to encourage problems with upload smoothness??</div><div><br></div><div>This implies that setting the receive window should be done on a connection by connection basis: small for slow connections, large, for high speed, long distance connections.</div><div><br></div><div>In addition, if I cap it to 65k, for reasons of smoothness,</div><div>that means the bandwidth delay product will keep maximum speed per upload stream quite low. So a symmetric or gigabit connection is going to need a ton of parallel streams to see full speed.</div><div><br></div><div>Most puzzling is why would anything special be required on the Client --> Server side of the equation</div><div>but nothing much appears wrong with the Server --> Client side, whether speeds are very low (GPRS) or very high (gigabit).</div><div><br></div><div>Note that also I am not yet sure if smoothness == better throughput. I have noticed upload speeds for some people often being under their claimed sync rate by 10 or 20% but I've no logs that show the bumpy graph is showing inefficiency. Maybe.</div><div><br></div><div>help!</div><div><span style="font-family:Menlo;font-size:11px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 12:56 PM, Simon Barber <span dir="ltr"><<a href="mailto:simon@superduper.net" target="_blank">simon@superduper.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One thing users understand is slow web access. Perhaps translating the latency measurement into 'a typical web page will take X seconds longer to load', or even stating the impact as 'this latency causes a typical web page to load slower, as if your connection was only YY% of the measured speed.'<br>
<br>
Simon<br>
<br>
Sent with AquaMail for Android<br>
<a href="http://www.aqua-mail.com" target="_blank">http://www.aqua-mail.com</a><div><div class="h5"><br>
<br>
<br>
On April 19, 2015 1:54:19 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
>>>> Frequency readouts are probably more accessible to the latter.<br>
>>><br>
>>> The frequency domain more accessible to laypersons? I have my doubts ;)<br>
>><br>
>> Gamers, at least, are familiar with “frames per second” and how that corresponds to their monitor’s refresh rate.<br>
><br>
> I am sure they can easily transform back into time domain to get the frame period ;) . I am partly kidding, I think your idea is great in that it is a truly positive value which could lend itself to being used in ISP/router manufacturer advertising, and hence might work in the real work; on the other hand I like to keep data as “raw” as possible (not that ^(-1) is a transformation worthy of being called data massage).<br>
><br>
>> The desirable range of latencies, when converted to Hz, happens to be roughly the same as the range of desirable frame rates.<br>
><br>
> Just to play devils advocate, the interesting part is time or saving time so seconds or milliseconds are also intuitively understandable and can be easily added ;)<br>
<br>
Such readouts are certainly interesting to people like us. I have no objection to them being reported alongside a frequency readout. But I think most people are not interested in “time savings” measured in milliseconds; they’re much more aware of the minute- and hour-level time savings associated with greater bandwidth.<br>
<br>
- Jonathan Morton<br>
<br></div></div><span class="">
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div><br></div>