[Bloat] is extremely consistent low-latency for e.g. xbox possible on SoHo networks w/o manual configuration?
Daniel Sterling
sterling.daniel at gmail.com
Wed Feb 19 20:02:11 EST 2020
Thanks to all for the input!
Toke, Jonathan -- you were absolutely right!
I sent this email because I -- I thought it inconceivable that "just"
setting a single bandwidth tunable could both:
* enforce / properly rate limit inbound and outbound traffic
* and, simultaneously, *prevent* non-bulk streams from seeing latency.
I know, I know. You've been telling everyone who will listen that cake
works. I just couldn't wrap my head around that possibly being true --
But boy, I was wrong. cake is as amazing as you say.
I got rid of my complex rules and swapped them out for:
cake bandwidth 60Mbit besteffort internet nat ethernet
Then I monitored my xbox game latency as I streamed videos, etc, to
generate bulk traffic.
There was no observable latency or jitter, and I did not see any
issues during actual game-play either.
Once again, I am truly amazed. Thank you to everyone who worked on
this impressive tool!
Ubuntu 19.10 finally ships with all the pieces in place (kernel, new
iproute2 package) -- so cake is now finally usable "out of the box"
for the average linux user. I look forward to telling everyone I know
to have some cake!
:)
Thanks,
Dan
On Fri, Feb 14, 2020 at 9:18 AM Michael Richardson <mcr at sandelman.ca> wrote:
>
>
> Daniel Sterling <sterling.daniel at gmail.com> wrote:
> > I am looking for input / discussion on how to achieve:
> > * on a "regular" SoHo network
>
> > * first and foremost, to the exclusion of all other goals, consistent
> > low-latency for non-bulk streams from particular endpoints; usually
> > those streams are easily identified and differentiated from all other
> > streams based on UDP/TCP port number,
>
> > * and assuming the identified and prioritized streams behave
> > themselves and stay non-bulk, decent throughput for all other traffic.
>
>
> > That is to say, some endpoints are more important than others; and
> > moreover some apps on some endpoints are most important.
>
> Distinguishing between apps is difficult in IPv4.
> IPv6 lets you naturally have many IP addresses, so it could be easier, but
> apps need to be taught to use "their" source address. Or OSes need to force
> them, or "containers".
>
> In the specific case of a single network, I'd just do static DHCPv4
> allocation and change the parameters on the qos scripts.
>
> In general, I'd want RFC8520 to announce the type of the device, and suggest
> a particular class of service. In the old days, we'd be talking RSVP to
> signal desired Diffserv behaviour ("DiffEdge"), but that specification did
> not, unfortunately, gain market momentum.
>
> > I put a linux laptop between CPE (WAN) and LAN. AT&T fiber in my case,
> > 100+ mbit up and down.
>
> It's not a terrible thing to use a laptop, but at 100Mb/s, an Omnia Turris or
> equivalenet running latest OpenWRT may be more foolproof. (I'm always the fool)
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | network architect [
> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
>
More information about the Bloat
mailing list