Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung
-
@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:
-
Was auch noch interessant ist: Der Traffic-Graph sieht so aus
Aber der Systemgraph zur selben Zeit so:
D.h. zur selben Zeit, wenn die Einbrüche des Traffics sind, werden auch keine Prozessordaten mehr aufgezeichnet? Das würde ja darauf hindeuten, dass die Box so überlastet ist, dass gar nichts mehr geht, aber ich bin mir ziemlich sicher, dass ich während so einer Phase problemlos die Web-UI weiter nutzen konnte.
-
@tschan said in Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung:
In dieser Zeit kommen zum Beispiel auch keine Antworten auf pings zu google.de zurück.
Was passiert wenn Du auf das LAN Interface ein Ping laufen lässt, kommt da auch schon nichts mehr zurück?
-
@slu Das Verhalten ist wirklich sehr strange. Wenn der Upload Limiter auf 50Mbit/s beschränkt ist, kann ich relativ stabil 800Mbit/s down und 50Mbit/s uploaden. Erhöhe ich das Uploadlimit auf 100 Mbit/s reicht es schon aus, nur hochzuladen, um innerhalb kürzester Zeit das Problem zu provozieren. Die Pings zu google.de haben für 10-20 Sekunden 100% Paketverlust. Die Pings zur LAN-IP bleiben unbetroffen.
Das kann doch nicht eine simple Überlastung sein? 800Mbit down geht, aber nicht 100 Mbit up? Das ist doch sehr seltsam.
-
@tschan Also, auch wenn theoretisch die Hardware ausreichen könnte, denke ich das mit der CPU PPPoE das Problem ist. Ich habe es so verstanden das deine Sense PPPoE macht.
-
@micneu Genau, die Box macht PPPoE. Aber ist diese Asymmetrie zwischen Upload und Download nicht komisch? Warum machen 800 Mbit Download über PPPoE viel weniger Probleme als 100 Mbit Upload über PPPoE?
-
@tschan kann ich dir nicht sagen, ich habe auch nie solche "billige"-hardware eingesetzt, ich hatte immer geräte die etwas besser waren
-
@tschan kann ich dir nicht sagen, ich habe auch nie solche "billige"-hardware eingesetzt, ich hatte immer geräte die etwas besser waren
hier diese CPUs hatte/habe ich im einsatz:- Atom C3558
- Core i5-1145G7
- Core i7-7500U
PS: habe noch ein baar screenshost während ich was downloade
Upload
-
@tschan said in Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung:
Warum machen 800 Mbit Download über PPPoE viel weniger Probleme als 100 Mbit Upload über PPPoE?
Tatsächlich habe ich so ein Verhalten bei einer PPPoE FTTH auch schon beobachtet aber noch nicht weiter untersucht.
-
@tschan hier noch down/upload gleichzeitig, keine probleme
-
@micneu Ich habe mir eine neue Box mit N100 besorgt und das Problem tritt nicht mehr auf. Lag also tatsächlich an der Hardware. :)
-
@tschan hatte ich doch geschrieben, und ich gehe von aus das in dem N100 Intel NICs verbaut sind.
-
@tschan Fein!
Ich denke das hier
0 root -60 - 0B 1328K CPU0 0 4:06 81.05% [kernel{if_io_tqg_0}]aus deiner Prozessliste war ein Anhaltspunkt. CPU0 ist der CPU Master und wenn CPU0 ausgelastet ist, gibt es immer wieder Möglichkeit für Probleme, Drops oder Fallouts. CPU0 mit 81% auf IO Tag/Queue sieht mehr sehr danach aus, als wäre die alte kleine Celeron CPU da nicht mehr mit den Acks der Verbindung klar gekommen. Das aber nur ein Verdacht, das hätte man dann ggf. etwas länger beobachten müssen. Sieht aber schon danach aus. Da nutzen dann auch gute NICs nichts mehr, wenn die I/O Lanes oder Queues voll sind und die CPU nichts mehr schieben kann :)
Cheers
