Jonathan Morton wrote:
On 1 May, 2017, at 14:32, Andy Furniss <[email protected]>
wrote:
Well it seems distance is important for BBR. It seems to have a
design whereby your rtt to the server determines how badly it will
bork your latency. Unlike cubic it doesn't take loss/ecn as a hint
to get out of its exponential phase, which is IMHO not a friendly
thing to do, I mean didn't they think people have to share
connections :-(
Playing with a sim, something like dash that grabs a meg waits
then gets another with a new connection needs crazy amount of back
off to avoid borking latency every chunk. The amount of disruption
getting worse the higher the RTT of the TCP.
Just to be sure - are you running sch_fq on the egress interface(s)
of the BBR sender? If not, *you are not running BBR*. BBR needs
the pacing functionality of sch_fq to work correctly.
No, I was trying to pretend that the flow was not local (though looking
I see sch_fq can handle routed).
Reading random high level descriptions of BBR I didn't see it mentioned.
I did read that bbr tries to probe 2x rtt, which is what I see in a pure
buffer.
Does google/valve/every bbr user run it?
I mean Dendari is clearly having issues with valve. I can't really test
latency properly with steam on my real wan as my ISP does QOS.
I'll try to cook up another sim, but will probably run out of interfaces.
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
