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

[luca.muscariello at orange.com]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150422/b9db9096/attachment-0003.html>