Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung
-
Hallo zusammen,
heute wurde mein Anschluss der Telekom auf Glasfaser 1000 umgestellt. Ein Speedtest auf speedtest.net zeigt einen Peak-Download von ~900Mbit/s und einen Peak-Upload von ~550Mbit/s. Wenn ich den Upload aber nicht limitiere, bricht die Verbindung direkt zusammen, sobald die Leitung voll ausgelastet ist.
Ich habe testweise einen CoDel Limiter nach dieser Anleitung konfiguriert und denn Download auf 850Mbit/s und den Upload auf 95Mbit/s reduziert. In dieser Konfiguration bricht die Verbindung zwar nicht direkt zusammen, aber wenn ich etwas hochlade, bekomme ich regelmäßiger "Aussetzer", wo scheinbar gar kein Traffic mehr rein oder raus geht. In dieser Zeit kommen zum Beispiel auch keine Antworten auf pings zu google.de zurück. Im Graph sieht das beispielsweise so aus:
Ich lasse pfSense auf einem ZimaBoard 832 laufen mit angesteckter Intel X550-T2 Netzwerkkarte.
Ich habe allerlei Schalter umgelegt und an Zahnrädchen geschraubt in der Hoffnung, die Stabilität und Performance zu erhöhen. Insbesondere habe ich die folgenden Einstellungen deaktiviert (=abgehakt):
Disable hardware TCP segmentation offloadDisable hardware large receive offloadEnable the ALTQ support for hn NICs.
und die folgenden Tunables gesetzt (gefunden bei der Recherche im Netz):
net.isr.dispatch=deferrednet.isr.maxthreads=4
Die Statusdaten vom Modem sehen eigentlich ok aus, wobei ich gerade eben folgenden Screen hatte:
Bei TxPower steh
-- dBm. Die ganze Zeit sah das so aus:
Würdet ihr sagen das ist ein Problem mit meiner Leitung oder Limitierungen meiner pfSense Hardware? Oder habe ich einfach noch irgendwo den Mach-dass-es-funktioniert-Knopf noch nicht gefunden?
Danke schonmal!
-
@tschan ich persönlich finde jetzt deine Hardware (CPU) nicht unbedingt optimal. Was für NICs sind verbaut (Realtek)?
Ich habe auch Glasfaser an einer Willy.tel Leitung (1000/250) und meine Netgate 6100 macht das Ohne große Probleme. -
@micneu Ich kann dir gar nicht sagen, was der Onboard Netzwerkchip ist, aber das Glasfaser-Modem und LAN hängen wie gesagt an einer angesteckten Intel X550-T2.
Edit: Gerade folgenden Beitrag gefunden. Der Poster sagt, dass er mit einer Baremetal Installation auf derselben Hardware 800Mbit/s Up und Down erreichen kann. Das würde jetzt ja eher dagegen sprechen, dass die Hardware an ihr Limit kommt.
-
@tschan ich habe gerade mal bei mir ca. 90GByte runter geladen
PS: was für eine Hardware hast du denn genau im Einsatz?
-
@micneu Ein Zimaboard 832.
Hat vielleicht jemand eine Idee, wie ich ein potentielles Hardware-Bottleneck ausfindig machen könnte? Mal angenommen das Modem ist nicht das Problem, dann muss es ja einen Grund geben, warum ich diese brutalen Traffic-Einbrüche habe.
-
@tschan ok, ich denke du solltes deine eingesetze Hardware kennen und was sie kann. Wenn du einen PCIe v3.0 Intel
Ethernet Controller X550 an einem PCIe 2.0 x4-Steckplatz betreibst, gibt es einige technische Auswirkungen und potenzielle Einschränkungen, die beachtet werden sollten:- PCIe 3.0 x4 hat eine maximale theoretische Bandbreite von etwa 4 GB/s (pro Richtung).
- PCIe 2.0 x4 bietet hingegen nur 2 GB/s (pro Richtung).
-
@micneu Also an diese Limits sollte ich ja mit 900Mbit down und 550Mbit up nicht ansatzweise drankommen.
Aber ich kann mal testweise den internen Netzwerkanschluss ausprobieren und schauen, ob das einen Unterschied macht.
-
@tschan wie hoch ist denn die CPU ausgelastet?
Mach doch auch mal einen größeren Download und schaue es dir mal an.PS: macht deine Sense PPPoE oder das Modem. Wie genau ist der Netzwerkaufbau bei dir (gerne einen grafischen netzwerkplan)
-
@micneu Bei einem großen Download sieht die Prozessliste so aus (der abgeschnitte Teil beinhaltet nur noch Prozesse im einstelligen Prozentbereich):
last pid: 79545; load averages: 3.28, 2.75, 1.49 up 0+00:09:47 21:24:27 277 threads: 8 running, 248 sleeping, 21 waiting CPU: 13.9% user, 0.2% nice, 26.9% system, 18.5% interrupt, 40.4% idle Mem: 94M Active, 116M Inact, 438M Wired, 7054M Free ARC: 133M Total, 40M MFU, 88M MRU, 267K Anon, 785K Header, 3422K Other 104M Compressed, 228M Uncompressed, 2.20:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K RUN 3 4:23 88.67% [idle{idle: cpu3}] 0 root -60 - 0B 1328K CPU0 0 4:06 81.05% [kernel{if_io_tqg_0}] 11 root 187 ki31 0B 64K CPU1 1 4:38 77.10% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K CPU2 2 3:36 58.69% [idle{idle: cpu2}] 0 root -60 - 0B 1328K CPU2 2 1:48 34.08% [kernel{if_io_tqg_2}] 12 root -60 - 0B 272K WAIT 1 2:51 20.56% [intr{swi1: netisr 1}] 11 root 187 ki31 0B 64K RUN 0 3:32 19.38% [idle{idle: cpu0}] ...Der Trafficgraph dazu sieht so aus:
Während einer der Einbrüche sieht die Prozessliste so aus:
last pid: 92189; load averages: 2.87, 2.78, 1.70 up 0+00:12:13 21:26:53 284 threads: 12 running, 251 sleeping, 1 zombie, 20 waiting CPU: 12.2% user, 0.2% nice, 28.9% system, 18.3% interrupt, 40.4% idle Mem: 99M Active, 115M Inact, 439M Wired, 7051M Free ARC: 133M Total, 40M MFU, 88M MRU, 286K Anon, 787K Header, 3443K Other 104M Compressed, 228M Uncompressed, 2.20:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K RUN 3 5:29 91.55% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K RUN 2 4:38 86.28% [idle{idle: cpu2}] 11 root 187 ki31 0B 64K RUN 1 5:58 86.08% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K RUN 0 4:05 71.88% [idle{idle: cpu0}] 0 root -60 - 0B 1360K CPU0 0 5:35 27.20% [kernel{if_io_tqg_0}] 0 root -60 - 0B 1360K - 2 2:32 10.50% [kernel{if_io_tqg_2}] 12 root -60 - 0B 272K CPU1 1 3:49 6.79% [intr{swi1: netisr 1}] ...Also scheinbar "Weniger Pakete" -> "Weniger Load", stellt sich nur die Frage, warum weniger Pakete.
Mein Setup sieht so aus:
┌───────────┐ PPPoE (VLAN7, ix0.7) ┌──────────────────────┐ ┌────────────────┐ │ pfSense ├───────────────────────►│ Glasfaser-Modem 2 ├─────►│ Anschlussdose │ └───────────┘ └──────────────────────┘ └────────────────┘Edit: Ich habe die Optionen
Disable hardware TCP segmentation offloadundDisable hardware large receive offloadwieder aktiviert. Damit kriege ich das Sägezahnmuster aus dem Graph. Leider kommt es immer noch zu den Einbrüchen:Nicht während Einbruch:
last pid: 71003; load averages: 4.50, 3.93, 2.10 up 0+00:08:06 21:46:22 277 threads: 8 running, 248 sleeping, 21 waiting CPU: 18.6% user, 0.2% nice, 28.8% system, 23.3% interrupt, 29.0% idle Mem: 93M Active, 116M Inact, 433M Wired, 7060M Free ARC: 133M Total, 40M MFU, 88M MRU, 263K Anon, 782K Header, 3432K Other 103M Compressed, 227M Uncompressed, 2.19:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -60 - 0B 1328K CPU0 0 3:31 71.29% [kernel{if_io_tqg_0}] 11 root 187 ki31 0B 64K RUN 1 2:37 69.58% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K RUN 3 2:32 64.79% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K RUN 2 1:59 47.66% [idle{idle: cpu2}] 12 root -60 - 0B 272K WAIT 3 3:27 31.79% [intr{swi1: netisr 2}] 11 root 187 ki31 0B 64K RUN 0 2:36 29.79% [idle{idle: cpu0}] 12 root -60 - 0B 272K WAIT 1 3:38 22.46% [intr{swi1: netisr 3}] 0 root -60 - 0B 1328K RUN 1 1:08 18.80% [kernel{if_io_tqg_1}] 0 root -60 - 0B 1328K RUN 3 0:54 16.55% [kernel{if_io_tqg_3}] ...Während Einbruch:
last pid: 18392; load averages: 4.06, 3.93, 2.22 up 0+00:09:04 21:47:20 277 threads: 5 running, 251 sleeping, 21 waiting CPU: 17.3% user, 0.2% nice, 29.1% system, 23.7% interrupt, 29.7% idle Mem: 95M Active, 117M Inact, 433M Wired, 7058M Free ARC: 133M Total, 40M MFU, 88M MRU, 267K Anon, 782K Header, 3429K Other 103M Compressed, 227M Uncompressed, 2.19:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K CPU1 1 3:04 77.59% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K CPU3 3 2:55 77.49% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K CPU2 2 2:16 68.55% [idle{idle: cpu2}] 11 root 187 ki31 0B 64K RUN 0 2:54 63.57% [idle{idle: cpu0}] 0 root -60 - 0B 1328K - 0 4:01 30.37% [kernel{if_io_tqg_0}] 12 root -60 - 0B 272K WAIT 1 3:57 11.96% [intr{swi1: netisr 2}] 12 root -60 - 0B 272K WAIT 3 4:10 9.57% [intr{swi1: netisr 3}] 0 root -60 - 0B 1328K - 1 1:18 8.15% [kernel{if_io_tqg_1}] 0 root -60 - 0B 1328K - 3 1:01 7.18% [kernel{if_io_tqg_3}] ...Graph dazu:
