<div dir="ltr">That makes sense. Ok.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 12:14 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">



<div>
<div style="color:black">
<div style="color:black">
<p style="margin:0 0 1em 0;color:black">If you set the window only a
little bit larger than the actual BDP of the link then there will only be a
little bit of data to fill buffer, so given large buffers it will take many
connections to overflow the buffer. </p><span class="">
<p style="margin:0 0 1em 0;color:black">Simon </p>
<p style="margin:0 0 1em 0;color:black">Sent with AquaMail for Android<br>
<a href="http://www.aqua-mail.com" target="_blank">http://www.aqua-mail.com</a></p>
</span></div><div><div class="h5">
<div style="color:black">
<p style="color:black;font-size:10pt;font-family:Arial,sans-serif;margin:10pt 0">On
April 21, 2015 4:18:10 PM jb <<a href="mailto:justin@dslr.net" target="_blank">justin@dslr.net</a>> wrote:</p>
<blockquote type="cite" class="gmail_quote" style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex"><div dir="ltr">Regarding the low TCP RWIN max setting, and
smoothness.<div><br></div><div>One remark up-thread still bothers me. It
was pointed out (and it makes sense to me) that if you set a low TCP max
rwin it is per stream, but if you do multiple streams you are still going
to rush the soho buffer.<div><br></div><div>However my observation with a
low server rwin max was that the smooth upload graph was the same whether I
did 1 upload stream or 6 upload streams, or apparently any
number.</div><div>I would have thought that with 6 streams, the PC is going
to try to flood 6x as much data as 1 stream, and this would put you back to
square one. However this was not what happened. It was puzzling that no
matter what, one setting server side got rid of the chop.</div><div>Anyone
got any plausible explanations for this ?</div><div><br></div><div>if not,
I'll run some more tests with 1, 6 and 12, to a low rwin server, and
post the graphs to the list. I might also have to start to graph the
interface traffic on a sub-second level, rather than the browser traffic,
to make sure the browser isn't lying about the stalls and
chop.</div><div><br></div><div>This 7800N has setting for priority of
traffic, and utilisation (as a percentage). Utilisation % didn't help,
but priority helped. Making web low priority and SSH high priority smoothed
things out a lot without changing the speed. Perhaps "low"
priority means it isn't so eager to fill its
buffers..</div><div><br></div><div>thanks</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at
8:13 AM, jb <span dir="ltr"><<a href="mailto:justin@dslr.net" target="_blank">justin@dslr.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Today I've switched it back to large receive window
max.<div><br></div><div>The customer base is everything from GPRS to
gigabit. But I know from experience that if a test doesn't flatten
someones gigabit connection they will immediately assume "oh congested
servers, insufficient capacity" and the early adopters of fiber to the
home and faster cable products are the most visible in tech forums and so
on.</div><div><br></div><div>It would be interesting to set one or a few
servers with a small receive window, take them from the pool, and allow an
option to select those, otherwise they would not participate in any default
run. Then as you point out, the test can suggest trying those as an option
for results with chaotic upload speeds and probable bloat. The person would
notice the beauty of the more intimate connection between their kernel and
a server, and work harder to eliminate the problematic equipment. Or.
They'd stop telling me the test was
bugged.</div><div><br></div><div>thanks</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On
Wed, Apr 22, 2015 at 12:28 AM, David Lang <span dir="ltr"><<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>></span>
wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div>On Tue, 21 Apr 2015, David Lang wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 21 Apr 2015, David Lang wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect you guys are going to say the server should be left with a large<br>
max receive window.. and let people complain to find out what their issue<br>
is.<br>
</blockquote>
<br>
what is your customer base? how important is it to provide faster service
to teh fiber users? Are they transferring ISO images so the difference is
significant to them? or are they downloading web pages where it's the
difference between a half second and a quarter second? remember that you
are seeing this on the upload side.<br>
<br>
in the long run, fixing the problem at the client side is the best thing to
do, but in the meantime, you sometimes have to work around broken customer
stuff.<br>
</blockquote>
<br>
for the speedtest servers, it should be set large, the purpose is to test
the quality of the customer stuff, so you don't want to do anything on
your end that papers over the problem, only to have the customer think
things are good and experience problems when connecting to another server
that doesn't implement work-arounds.<br>
</blockquote>
<br></div></div>
Just after hitting send it occured to me that it may be the right thing to
have the server that's being hit by the test play with these settings.
If the user works well at lower settings, but has problems at higher
settings, the point where they start having problems may be useful to
know.<span><font color="#888888"><br>
<br>
David Lang</font></span><br></div></div><span>_______________________________________________<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>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>

_______________________________________________<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>
<br>
</blockquote>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>