Re: [Cake] Getting Cake to work better with Steam and similar applications

[Andy Furniss <adf.lists@gmail.com>]

Jonathan Morton wrote:
> 
>> On 1 May, 2017, at 16:03, Andy Furniss <adf.lists@gmail.com>
>> wrote:
>> 
>> Does google/valve/every bbr user run it?
> 
> By definition, yes.  Without sch_fq, there is no pacing available for
> BBR to use, and pacing is the mode it normally tries to operate in.
> Without pacing, you are not in fact running BBR, but something quite
> different and inferior.
> 
> Please redo your measurements with the correct configuration at the
> sender.

Well I can't really test cake like this. If I need to put fq on eth of
sender then I can't double queue to sim cake behind ISP.

What I can do though is use ingress on target box just to sim ISP buffer
and compare how it gets filled.

So sender, bbr just fq on eth. netem is on ingress.

Target/downloader hfsc on ingress with bfifo sim 18meg dsl oh 40.

Differences to previous setup - One tcp is now very low "ISP" buffer
fullness, before it was a bit higher.

5 tcps are a bit different but may fill the buffer 280ms for a while
before eventually falling back to about 60ms in the case of a staggered
start. Simultaneous start straight to 60ms sometimes falling to 0 then
rising.

Testing repeated one meg downloads looks just the same as my previous
set up (ie if I just looked at "ISP" buffer by setting cake high).

The latency spikes to roughly 2x the netem delay per download. Given
this is the same as seen with my non pacing sim then I expect cake would
have trouble stopping this (though it did make the spikes shorter
time wise and a bit lower depending on backoff amount).

You would miss a lot of this just pinging normally. I am testing as if
on a 30Hz gameserver and plotting pings live (gnuplot).