Shaper Limit on N150/igc - Tunables (Offloads, kern.hz, ASPM) failed. 5G issue?

[FireStorm]

Hi everyone,

I'm summarizing the findings from my German forum thread (Topic 49664) as the issue remains unsolved, and I'm hoping for new insights.

The Hardware & Goal:

System: Aoostar N1 Pro (Intel N150, 12GB RAM, igc 2.5G ports).

Connection: 5G Router (Bridge Mode, IPv4 only), providing 600/60 Mbps.

Goal: Use Shaper (FlowQueue-CoDel) to achieve Grade A(+) bufferbloat.

The Problem: When I disable the shaper, I get full speed (585/62) but Grade C/D bufferbloat. When I enable the shaper (Pipes at 550/55, correct LAN-out/WAN-out rules, empty Queues tab), my speed collapses to 300/30 Mbps, but I achieve Grade A bufferbloat.

The CPU is NOT the bottleneck. Using top -P during the test shows the N150 CPU is bored (max 20-25% load on a single core).

Summary of Troubleshooting (What I Already Tried)
I have systematically ruled out all common configuration errors and tuning parameters:

Hardware Offloads (TSO/LRO):

I disabled TSO, LRO, and CRC in Interfaces > Settings.

I verified via SSH (ifconfig -v igc0/1) that TSO and LRO were successfully disabled in the driver's options=.

Result: No change. Still 300/30.

Kernel Timer (kern.hz):

With Offloads still disabled, I set kern.hz=1000 (and rebooted).

Result: No change. Still 300/30.

Setting kern.hz=2000 made the system unstable and bufferbloat worse (Grade B/C). This tunable was removed.

Power Management (ASPM/EEE):

Following advice (like in thread 42985), I set hw.pci.enable_aspm=0 and hw.igc.eee_setting=0 (and rebooted).

Result: Made the problem WORSE. Speed dropped further to ~200/25. These tunables were removed.

Scheduler Type (FIFO):

I tested using the FIFO scheduler (instead of CoDel) on the Upload pipe.

Result: No change. The upload remained stuck at 30 Mbps.

Community Feedback (The "Queues" Debate):

Forum member @meyergru (thx for your support!) pointed out that the official documentation uses both Pipes and Queues, and my rules should target the Queues.

I explained that I intentionally left the Queues tab empty based on advice that FlowQueue-CoDel (in the Pipe) manages itself, and that this setup (empty Queues) actually gave me a better Grade A result in earlier tests (before the 300/30 bug became the main problem).

Conclusion: This configuration difference does not seem to be the cause of the 300/30 limit.

The Final, Unsolved Question: Is 5G the Culprit?
After exhausting all software tuning (ipfw, drivers, kernel, offloads, power management), my last theory is this:

Is the volatile, "bursty" nature of a 5G connection fundamentally incompatible with the ipfw shaper? The shaper relies on a stable baseline, which 5G by nature cannot provide. The shaper's math might be collapsing due to the extreme, millisecond-level speed variations.

Does anyone have experience with shapers on 5G, or any other idea what I might have missed?