On Wed, 4 Aug 2021, Sebastian Moeller wrote:
I guess the point is AQM is not really that expensive, even FQ AQM,
traffic shaping however is expensive. But for wifi shaping is not
required so AQM became feasible.
My point is that CPU based forwarding has very bad performance on some
On Wed, 4 Aug 2021, Jonathan Morton wrote:
Linux-based CPE devices have AQM functionality integrated into the Wifi
stack. The AQM itself operates at layer 3, but the Linux Wifi stack
implementation uses information from layers 2 and 4 to improve
scheduling decisions, eg. airtime-fairness and
On Thu, 25 Feb 2021, Simon Barber wrote:
The ITU say voice should be <150mS, however in the real world people are
a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few
people complain about that. That said the quality of the conversation is
affected, and staying under 150mS is
On Wed, 24 Feb 2021, Sina Khanifar wrote:
https://www.waveform.com/tools/bufferbloat
I thought I just wanted to confirm that the tool seems to accurately seems
to measure even higher speeds.
This is my 1000/1000 debloated with FQ_CODEL to 900/900:
On Fri, 22 Jan 2021, Stuart Cheshire via Bloat wrote:
Is implementing CoDel queueing really 10x more burden than running
“Ubiquiti’s proprietary Deep Packet Inspection (DPI) engine”? Is CoDel
4x more burden than Ubiquiti’s IDS (Intrusion Detection System) and IPS
(Intrusion Prevention
On Fri, 4 Sep 2020, Jonathan Morton wrote:
We're usually seeing problems with the smaller-scale CPUs found in CPE
SoCs, which are very much geared to take advantage of hardware
accelerated packet forwarding. I think in some cases there might
actually be insufficient internal I/O bandwidth to
On Thu, 3 Sep 2020, Sebastian Moeller wrote:
Mmmh, how did you measure the sirq percentage? Some top versions
show overall percentage with 100% meaning all CPUs, so 35% in a quadcore
could mean 1 fully maxed out CPU (25%) plus an additional 10% spread
over the other three, or something more
On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote:
Yup, the number of cores is only going to go up, so for CAKE to stay
relevant it'll need to be able to take advantage of this eventually :)
https://www.hardkernel.com/shop/odroid-h2plus/ is an interesting platform,
it has a quad core machine
On Mon, 31 Aug 2020, Toke Høiland-Jørgensen wrote:
And what about when you're running CAKE in 'unlimited' mode?
I tried this:
# tc qdisc add dev eth0 root cake bandwidth 900mbit
This seems fine from a performance point of view (not that high sirq%,
around 35%) and does seem to limit my
On Mon, 31 Aug 2020, Toke Høiland-Jørgensen wrote:
Hmm, you say CAKE and FQ-Codel - so you're not enabling the shaper (that
would be FQ-CoDel+HTB)? An exact config might be useful (or just the
output of tc -s qdisc).
Yeah, I guess I'm also using HTB to get the 900 megabit/s SQM is looking
--- Begin Message ---
On Tue, 2 Jun 2020, Tianhe wrote:
What does it mean?
What I do is that on my WAN, I do bidirectional shaping/AQM at 90% of the
ISP configured rate, meaning buffering will generally be done in my device
instead of the ISP device, and my device has proper AQM so I have
11 matches
Mail list logo
