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
platforms
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 b
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:
https://www.waveform.com/tools/bufferbloat
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 System)?
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 b
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 w
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 upst
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
for
Hi,
I migrated to an APU2 (https://www.pcengines.ch/apu2.htm) as residential
router, from my previous WRT1200AC (marvell armada 385).
I was running OpenWrt 18.06 on that one, now I am running latest 19.07.3
on the APU2.
Before I had 500/100 and I had to use FQ_CODEL because CAKE took too m
--- 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 no
12 matches
Mail list logo