On 2020-08-09 5:35 p.m., Jonathan Morton wrote:
Are the risks and tradeoffs well enough understood (and visible enough
for troubleshooting) to recommend broader deployment?
I recently gave openwrt a try on some hardware that I ultimately
concluded was insufficient for the job. Fairly soon after changing out
my access point, I started getting complaints of Wi-Fi dropping in my
household, especially when someone was trying to videoconference. I
discovered that my AP was spontaneously rebooting, and the box was
getting hot.
Most CPE devices these days rely on hardware accelerated packet forwarding to
achieve their published specs. That's all about taking packets in one side and
pushing them out the other as quickly as possible, with only minimal support
from the CPU (likely, new connections get a NAT/firewall lookup, that's all).
It has the advantages of speed and power efficiency, but unfortunately it is
also incompatible with our debloating efforts. So debloated CPE will tend to
run hotter and with lower peak throughput, which may be noticeable to cable and
fibre users; VDSL (FTTC) users might have service of 80Mbps or less where this
effect is less likely to matter.
It sounds like that AP had a very marginal thermal design which caused the
hardware to overheat as soon as the CPU was under significant load, which it
can easily be when a shaper and AQM are running on it at high throughput. The
cure is to use better designed hardware, though you could also contemplate
breaking the case open to cure the thermal problem directly. There are some
known reliable models which could be collected into a list. As a rule of
thumb, the ones based on ARM cores are likely to be designed with CPU
performance more in mind than those with MIPS.
Cake has some features which can be used to support explicit classification and
(de)prioritisation of traffic via firewall marking rules, either by rewriting
the Diffserv field or by associating metadata with packets within the network
stack (fwmark). This can be very useful for pushing Bittorrent or WinUpdate
swarm traffic out of the way. But for most situations, the default
flow-isolating behaviour already works pretty well, especially for ensuring
that one computer's network load has only a bounded effect on any other. We
can discuss that in more detail if that would be helpful.
I'm primarily thinking of /this week's/ version of the home router
problem (;-))
Because of the degree to which we're working from home and
videoconferencing, a lot of low-price, medium-performance devices are
suddenly too wimpy for their new role.
A (very!) draft version is up in Google docs, at
https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=sharing
Using myself as the guinea-pig, running pfifo-fast was clearly bad,
fq_codel was better, and cake was good with a newish Fedora and the
stock Rogers router. It's been a while since I did rrul tests, and in
any case, I think that to convince readers we need a very practical way
of making it clear that they have a problem. I'm thinking that making
VOIP fail might do the trick (;-))
The hard part, IMHO, is constructing a test that immediately
communicates the idea that the reader has a problem, and that CAKE
addresses it.
Returning to the hardware question, https://evenroute.com/iqrv3 seems to
be capable of handling up to ~300 Mbit/S connections, and my ISP only
delivers 170 (and advertises 150, which is mildly surprising!)
I just ordered one, so I'll have a 'plug in" example, along with
reflashing my linksys for the umpty-thousandth time.
--dave
I suspect not enough people are aware of the later efforts of the
bufferbloat team, so I'm thinking of one or two articles, starting
with LWN and an audience of aficionados.
The core community is aware of what we've done, but in my view we
haven't converted "grandma". Grandma, as well as a whole bunch of
ordinary engineers and partners of engineers, are dependent on
debloated performance because they're working at home now, and
competing with granddaughter playing video games while they're trying
to hold a video call.
Right now, my colleagues at work suffer from more than a second of
bloat-related lag. They therefore tend to speak over each other on
con-calls, apologize, start again and talk over each other, again.
After a little while, the picture becomes a distinctly silly one: a
bunch of grown adults putting their hands up and waving, like little
kids in school. No-one has called out “me, me, teacher” yet, but I
expect it any time.
I propose we show the results in terms that we can explain to Grandma,
specifically concentrating on functioning VOIP. I just upgraded to
Fedora 31, and the networking is absolutely stock, so I make a perfect
victim/guinea-pig (;-))
Who's interested?
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net | -- Mark Twain
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
