[Bloat] RE : DSLReports Speed Test has latency measurement built-in

[jb]

So I find a page that explains SO_RCVBUF is allegedly the most poorly
implemented on Linux, vs Windows or OSX, mainly because the one you start
with is the cap, you can go lower, but not higher, and data is needed to
shrink the window to a new setting, instead of slamming it shut by
setsockopt

Nevertheless! it is good enough that if I set it on tcp connect I can at
least offer the option to run pretty much the same test to the same set of
servers, but with a selectable cap on sender rate.

By the way, is there a selectable congestion control algorithm available
that is sensitive to an RTT that increases dramatically? in other words,
one that does the best at avoiding buffer size issues on the remote side of
the slowest link? I know heuristics always sound better in theory than
practice but surely if an algorithm picks up the idle RTT of a link, it can
then pump up the window until an RTT increase indicates it should back off,
Instead of (encouraged by no loss) thinking the end-user must be
accelerating towards the moon..

thanks.

On Wed, Apr 22, 2015 at 6:51 PM, <luca.muscariello at orange.com> wrote:

>  cons: large BDP in general would be negatively affected.
> A Gbps access vs a DSL access to the same server would require very
> different tuning.
>
>  sch_fq would probably make the whole thing less of a problem.
> But running it in a VM does not sound a good idea and would not reflect
> usual servers setting BTW
>
>
>
>
>
>
>
>
>
> -------- Message d'origine --------
> De : Eric Dumazet
> Date :2015/04/22 12:29 (GMT+08:00)
> À : "Steinar H. Gunderson"
> Cc : bloat
> Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-in
>
>   On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote:
> > On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
> > > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket
> buffers
> > > for the application layer, they do not change the TCP window size
> either
> > > send or receive.
> >
> > I haven't gone into the code and checked, but from practical experience I
> > think you're wrong. I've certainly seen positive effects (and verified
> with
> > tcpdump) from reducing SO_SNDBUF on a server that should have no
> problems at
> > all sending data really fast to the kernel.
>
> Well, using SO_SNDBUF disables TCP autotuning.
>
> Doing so :
>
> Pros:
>
> autotuning is known to enable TCP cubic to grow cwnd to bloat levels.
> With small enough SO_SNDBUF, you limit this cwnd increase.
>
> Cons:
>
> Long rtt sessions might not have enough packets to utilize bandwidth.
>
>
> >
> > Then again, this kind of manual tuning trickery got obsolete for me the
> > moment sch_fq became available.
>
> Note that I suppose the SO_MAX_PACING rate is really helping you.
>
> Without it, TCP cubic is still allowed to 'fill the pipes' until packet
> losses.
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150422/14740faf/attachment-0003.html>