Messages

2. Die Hersteller (auch CWWK) betreiben die Nxxx CPUs meist am oberen Limit Ihrer möglichen TDP, beispielsweise beim N100 statt mit 6W mit 25 Watt, und oft genug kommt man im BIOS an diese Einstellungen nicht ohne weiteres heran.

Das stört mich am meisten, diese Geräte sind ja keine Standardware, sondern richten sich eher an Profis und Fortgeschrittene. Gerade deshalb ist die Limitierung im BIOS absolut unverständlich.

Bei mir ist die Situation ein bisschen anders. Ich habe zwar auch zur 'Rush Hour' sehr gutes Internet, aber dennoch macht es einen Unterschied, ob 600 oder 300 Mbit anliegen. Im Alltag merke ich davon allerdings nichts – 4k-Streaming läuft mit 100 Mbit schließlich genauso gut wie mit 600. Der Unterschied zum Kabel liegt eher in der Latenz.

Durch etwas Fine-Tuning und eine Outdoor-Antenne habe ich aber mittlerweile eine enorme Stabilität erreicht (konstant Grade A). Mein Ping liegt meist unter 20 ms, teilweise sogar bei 9 ms. Für meine Zwecke – ich zocke nicht – bin ich damit super zufrieden. Würde ich trotzdem Kabel bevorzugen? Natürlich!

Ich habe hier noch zwei USB-Netzwerkadapter (1x 2,5G und 1x 5Gbit RJ45). Damit könnte ich die igc-Ports testweise umgehen, um zu sehen, ob der Fehler eventuell am Treiber der Intel-Ports liegt. Oder um den oben erwähnten Test durchzuführen.

Äh nein. USB NICs sind prädestiniert dafür mieserabel zu funktionieren und machen mehr Ärger als irgendwas. Da würde ich für irgendwas halbwegs produktives WEIT die Finger davon lassen :)

Danke für den Hinweis!

Dank @Seimus habe ich meine BW verbessert und bekomme jetzt konstant ein Grade A! Wir haben die Config auf Basis der Doku aktualisiert und noch etwas Feintuning betrieben.

Leider konnten wir die Download-Latenz aufgrund der Natur von 5G nicht dauerhaft unter 10ms halten. Ein großes Danke an Seimus für die Hilfe dabei, den Sweet Spot zu finden! :D"

Thanks to @Seimus, I've improved my BW and am now getting a constant Grade A! We updated the config based on the docs and did some fine-tuning.

Unfortunately, because of the nature of 5G, we couldn't get the download latency to stay below 10ms consistently. Big thanks to Seimus for his help finding the sweet spot! :D

Never tried, but I am open to do so, any particular thing I need to take care?

Can you configure the shaper as described in docs and test again?
Can you show your whole configuration of the shaper (pipe,queue,rules with advanced mode)?
As well via CLI run these commands and show the output.

Code Select Expand

ipfw pipe show
ipfw sched show
ipfw queue show
ipfw show
 
Regards,
S.

hi, as requested (without adding queues):

Code Select Expand

root@OPNsense:~ # ipfw pipe show
10000: 550.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
 sched 75536 type FIFO flags 0x0 0 buckets 1 active
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip          0.0.0.0/0            0.0.0.0/0      11    4857  0    0  0
10001:  55.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
 sched 75537 type FIFO flags 0x0 0 buckets 1 active
  0 ip          0.0.0.0/0            0.0.0.0/0        4      406  0    0  0
root@OPNsense:~ # ipfw sched show
10000: 550.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
 sched 10000 type FQ_CODEL flags 0x0 0 buckets 0 active
 FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 NoECN
10001:  55.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
 sched 10001 type FQ_CODEL flags 0x0 0 buckets 0 active
 FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 NoECN
root@OPNsense:~ # ipfw queue show
root@OPNsense:~ # ipfw show
00100        0          0 allow pfsync from any to any
00110        0          0 allow carp from any to any
00120        0          0 allow layer2 mac-type 0x0806,0x8035
00130        0          0 allow layer2 mac-type 0x888e,0x88c7
00140        0          0 allow layer2 mac-type 0x8863,0x8864
00150        0          0 deny layer2 not mac-type 0x0800,0x86dd
00200    11616    2982200 skipto 60000 ip6 from ::1 to any
00201    4252      468624 skipto 60000 ip4 from 127.0.0.0/8 to any
00202        0          0 skipto 60000 ip6 from any to ::1
00203        0          0 skipto 60000 ip4 from any to 127.0.0.0/8
60000        0          0 return proto ip
60001 53382272 67067358644 pipe 10000 ip from any to any out via igc1 // lan: DownloadPipe
60002 24291311  7102329318 pipe 10001 ip from any to any out via igc0 // wan: UploadPipe
65533 78607935 74368736814 allow ip from any to any
65534        0          0 deny ip from any to any
65535        0          0 allow ip from any to any
root@OPNsense:~ #

Which shaper is it exactly?

flowqueue-codel

[The Hardware & Goal:]

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?

Ich habe hier noch zwei USB-Netzwerkadapter (1x 2,5G und 1x 5Gbit RJ45). Damit könnte ich die igc-Ports testweise umgehen, um zu sehen, ob der Fehler eventuell am Treiber der Intel-Ports liegt. Oder um den oben erwähnten Test durchzuführen.

Ansonsten kann ich mir vorstellen, dass aufgrund der Schwankungen beim 5G der Shaper einfach damit nicht klar kommt, wobei ja ein Ergebnis doch spürbar messbar ist von Grade B -D auf meist Grade A bzw. manchmal Grade B. Nur eben muss man hierfür 50% seines Speeds im DL sowie UL opfern, was recht hart ist!

Sollte das nicht die Ursache sein, bin ich für jede weitere Idee offen! Insbesondere, falls jemand einen Grund sieht, warum es nicht am 5G-Anschluss liegen sollte, wäre ich für diesen Gedanken sehr dankbar.

Ich frage nur zur Sicherheit: Du hast nach Setzen der Tuneables einen Reboot ausgeführt?

Ich würde aber nicht ausschließen, dass eine 5G-Anbindung anders reagiert als die typischen DSL- und Glasfaser-Anschlüsse. Wenn dort Pakete in Zellen zusammengeschnürt werden, kann das problematisch sein, wenn das mit dem Timing des Shapers kollidiert.

Ich bin so paranoid gewesen, dass ich sogar zur Sicherheit nach jeder Veränderung der Einstellung einen Neustart gemacht habe. Übrigens ASPM & EEE habe ich wieder gelöscht, weil ich dadurch dann wieder deutlich schlechtere Werte hat Grade B/C im Vergleich zu Grade A (manchmal B).

Das mit der 5G Anbindung kam mir auch schon in den Gedanken, aber dachte eher unwahrscheinlich, wobei was ist heutzutage nicht möglich? Aber könnte man das nicht iwie überprüfen? Es ist halt schade, ich habe ziemlich viel Zeit investiert. Eigentlich reichen ja die 300Mbit vollkommen aus, im Alltag spürt man ja keinen Unterschied zw. 600 und 300Mbit und wenn man einen Download hat könnte man ja den Shaper deaktivieren, aber genau da sollte er ja dann greifen, damit ein intelligentes Lastmanagement greift eben wenn ein Vebraucher so intensiv das Netz nutzen möchte während ein anderer einen Video-Call zum Beispiel hat.

Das mit IPv6 vs. IPv4 macht keinen Unterschied?

Gibt es noch andere Ansätze / Ideen?

Ja, sorry, habe es korrigiert, es ist aber auch im Punkt 26 in "READ ME FIRST" verlinkt. Da stehen noch ein paar Tips...

Könnte aber auch sein, dass Du ASPM noch an hast was insbesondere I226V sehr verlangsamt, auch dazu findest Du etwas im Artikel.

P.S.: Es ist übrigens nicht damit getan, die Queues wieder anzulegen - die Regeln müssen diese auch referenzieren (und nicht die Pipes).

Zur Info ich habe besser gesagt hatte:

Tunable: hw.pci.enable_aspm

Value: 0


Tunable: hw.igc.eee_setting

Value: 0

beides deaktiviert, hat keinen Unterschied gebracht.

Der Link von dir bezieht sich auf IPv6, ich habe nur IPv4, sofern das relevant ist.

Offenbar hast Du vollkommen übersehen, die offizielle Dokumentation zu Rate zu ziehen, wenn ich dies hier richtig interpretiere:

Der Queues-Reiter ist bei mir komplett leer.

Das Traffic-Shaping funktioniert nämlich (auch auf Deiner Hardware) ziemlich gut.

Hi, danke für die schnelle Antwort. Der Link zur Doku funkt nicht, aber das ist kein Problem, ich hatte davor die Queues drinnen habe aber anhand von Google gelesen, dass man auf die verzichten kann/soll weil angeblich so Probleme entstehen könnten (weil FlowQueue-CoDel die Queue selbst managed angeblich) und tatsächlich war es zumindest subjektiv so, dass ich öfters Grade A erreicht habe, also zuvor mit Grade B. Ich habe jz in der Doku auf die Schnelle aber auch nichts gefunden was ich nicht bereits in der Queue hatte (aber dann wieder gelöscht habe). Beziehst du dich auf diese Doku Shaper Queue config

[CPU-Limit:]

Hallo liebes OPNsense-Forum,

ich verzweifle langsam an meinem Shaper-Setup und hoffe, jemand hier hat noch eine Idee. Ich nutze einen leistungsstarken N1 Pro und möchte meinen 5G-Anschluss (der starke Latenzschwankungen hat) mittels Shaper auf ein stabiles "Grade A" Bufferbloat bringen.

Das Problem ist: Sobald ich den Shaper aktiviere, bricht mein Speed ein, aber auf einen (für mich) unerklärlichen Wert.

Meine Hardware
System: Aoostar N1 Pro

CPU: Intel N150

RAM: 12 GB

Interfaces: Intel 2.5G Ports (Treiber: igc)

Anbindung: 5G Router

Das Problem im Detail
Mein 5G-Anschluss (600/60) im Bridge Modus (IPv4) liefert eigentlich stabile ~585 Mbit/s Download und ~60-65 Mbit/s Upload.

1. Test: Shaper-Regeln DEAKTIVIERT

Ergebnis: Speedtest zeigt 585 / 62 MBit/s.

Bufferbloat: Grade C / D (das ist zu erwarten).

2. Test: Shaper-Regeln AKTIVIERT Ich habe versucht, eine saubere Konfiguration mit FlowQueue-CoDel einzurichten. So sieht mein aktuelles Setup aus:

Pipe 1 (Download): 550 Mbit/s, Scheduler: FlowQueue-CoDel

Pipe 2 (Upload): 55 Mbit/s, Scheduler: FlowQueue-CoDel

Regel 1 (Download): Interface LAN, Direction out, Target DownloadPipe

Regel 2 (Upload): Interface WAN, Direction out, Target UploadPipe

Der Queues-Reiter ist bei mir komplett leer.

Ergebnis: Speedtest zeigt nur noch ~300 / 30 MBit/s.

Bufferbloat: Grade A (der Shaper scheint also zu greifen, limitiert aber auf einen völlig falschen Wert).

Das Merkwürdigste: Die CPU (N150) ist bei diesem Test (laut top -P) maximal bei 20-25% Last auf einem Kern. Die CPU scheint also nicht das Problem zu sein.

Was ich bereits (erfolglos) versucht habe
Ich habe versucht, alle üblichen Verdächtigen auszuschließen:

CPU-Limit:

Wie oben erwähnt, top -P zeigt, dass sich die CPU langweilt.

Hardware Offloads (TSO/LRO):

Ich habe TSO, LRO und CRC unter Interfaces > Settings deaktiviert.

Verifizierung per SSH: ifconfig -v igc0 (und igc1) hat bestätigt, dass TSO und LRO in den options= nicht mehr auftauchen. Die Offloads SIND also deaktiviert.

Ergebnis: Brachte keinerlei Änderung. Immer noch 300 / 30 MBit/s.

Kernel Timer (kern.hz):

Ich habe (mit deaktivierten Offloads) den Tunable kern.hz auf 1000 gesetzt und neu gestartet.

Ergebnis: Keinerlei Änderung. Immer noch 300 / 30 MBit/s.

Eine testweise Erhöhung auf 2000 machte das System instabiler und der Bufferbloat wurde schlechter (B/C). kern.hz habe ich daher wieder entfernt.

Scheduler-Test (FIFO):

Ich habe die UploadPipe testweise von FlowQueue-CoDel auf FIFO umgestellt.

Ergebnis: Keinerlei Änderung. Der Upload blieb bei 30 MBit/s.

Flow Control:

Diese Einstellung ist für meinen igc-Treiber in der OPNsense-GUI (selbst unter "Overwrite global settings") leider nicht verfügbar.

Fazit: Ich komme also zu dem Schluss, dass die CPU nicht limitiert und die Konfiguration (nach bestem Wissen) jetzt stimmen sollte. Trotzdem bringen die bekannten Workarounds (Offloads, kern.hz) absolut nichts.

Könnte das Probem an einer Inkompatibilität zwischen der ipfw-Engine und dem igc-Treiber sein? Hat irgendjemand mit 2.5G-Ports (igc) ein ähnliches Phänomen beobachtet oder eine Idee, was ich noch übersehen haben könnte?

Danke für eure Hilfe!