<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Do I need to read this as all Google servers == all servers :)
<div><br>
</div>
<div>BTW if a paced flow from Google shares a bloated buffer with a non paced flow from a non Google server, doesn't this turn out to be a performance penalty for the paced flow? </div>
<div><br>
</div>
<div>fq_codel gives incentives to do pacing but if it's not deployed what's the performance gain of using pacing? </div>
<br>
<br>
<div>-------- Message d'origine --------</div>
<div>De : Eric Dumazet </div>
<div>Date :2015/04/22 21:51 (GMT+08:00) </div>
<div>À : MUSCARIELLO Luca IMT/OLN </div>
<div>Cc : "Steinar H. Gunderson" , bloat </div>
<div>Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-in </div>
<div><br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, 2015-04-22 at 08:51 +0000, luca.muscariello@orange.com wrote:<br>
> cons: large BDP in general would be negatively affected. <br>
> A Gbps access vs a DSL access to the same server would require very<br>
> different tuning. <br>
> <br>
Yep. This is what I mentioned with 'long rtt'. This was relative to BDP.<br>
> <br>
> sch_fq would probably make the whole thing less of a problem. <br>
> But running it in a VM does not sound a good idea and would not<br>
> reflect usual servers setting BTW <br>
> <br>
No idea why it should mater. Have you got some experimental data ?<br>
<br>
You know, 'usual servers' used to run pfifo_fast, they now run sch_fq.<br>
<br>
(All Google fleet at least)<br>
<br>
So this kind of argument sounds not based on experiments.<br>
<br>
<br>
</div>
</span></font>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></body>
</html>