Shaper (FlowQueue-CoDel) limitiert auf 300/30 Mbit trotz N150-CPU (igc)

[FireStorm]

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!

[meyergru]

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.

Siehe dazu auch dies: https://forum.opnsense.org/index.php?topic=42985.0, Punkt 26.

Das Traffic-Shaping sollte eigentlich auch auf Deiner Hardware ziemlich gut funktionieren (siehe meine Signatur).

[FireStorm]

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

[meyergru]

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).

[FireStorm]

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.

[meyergru]

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.

[FireStorm]

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?

[meyergru]

Wenn Du nur IPv4 hast, brauchst Du offensichtlich für IPv6 auch keine Einstellungen.

Theoretisch könntest Du zum Testen lokal eine Strecke aufbauen, um die Wirksamkeit des Shapers zu überprüfen und zu checken, dass Deine Hardware oder Dein Setup nicht das Problem sind. Dazu müsstest Du ein zweites System an einen weiteren Netzwerkanschluss anschließen und dort ein separates LAN aufbauen. Dann könnte man die Performance zwischen Deinem LAN und diesem zweiten System messen. Leider hat Deine Hardware aber nur zwei Ports, die schon belegt sind.

Ich denke tatsächlich, dass sich das Verhalten des Shapers - insbesondere mit den Einstellungen gegen Bufferbloat - nicht mit einer Mobilfunk-Anbindung verträgt. Eventuell könnte es aber etwas bringen, wenn man z.B. Download-Traffic niedriger priorisiert oder Bandbreite für andere, wichtige Anwendungen (oder Clients) höher priorisiert bzw. Bandbreite dafür reserviert. Auch dazu gibt es in der Dokumentation Anleitungen.

[FireStorm]

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.