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

[MUSCARIELLO Luca IMT/OLN <luca.muscariello@orange.com>]

On 04/22/2015 05:44 PM, Eric Dumazet wrote:
> On Wed, 2015-04-22 at 15:26 +0000, luca.muscariello@orange.com wrote:
>> Do I need to read this as all Google servers == all servers :)
>>
>>
> Read again what I wrote. Don't play with my words.

let the stupid guy ask questions.
In the worst  case don't answer, but no reason to get nervous.


>
>> 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?
>>
>>
> What do you think ? Do you think Google would still use sch_fq if this
> was a potential problem ?

Frankly, I do not understand this statement as it seems you tell me
that that would be the right choice as Google does it.
I believe that Google does it for technical reasons and that would be
part of your possible answers. You have the right not to share with the 
list of course.

>
>> fq_codel gives incentives to do pacing but if it's not deployed what's
>> the performance gain of using pacing?
> 1) fq_codel has nothing to do with pacing.

FQ gives you flow isolation.
Extreme example: If you share the link with a flow that saturates the 
buffer (for whatever reason)
flow isolation gives you the comfort to do whatever works better for 
your application.
Without flow isolation how can you benefit from the good features of 
pacing if
the buffer get screwed by a competing flow?

This is what I meant with incentives to do pacing in presence of flow 
isolation, as you get rewarded
if the sender behaves better no matter what others do.


>
> 2) sch_fq doesn't depend on fq_codel or codel being used anywhere.
that's clear to me.


>