Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung

micneu

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

tschan

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

micneu

@tschan ich habe gerade mal bei mir ca. 90GByte runter geladen

PS: was für eine Hardware hast du denn genau im Einsatz?

tschan

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

micneu

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

tschan

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

micneu

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

tschan

@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 offload und Disable hardware large receive offload wieder 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:

tschan

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.

slu

@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?

tschan

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

micneu

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

tschan

@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?

micneu

@tschan kann ich dir nicht sagen, ich habe auch nie solche "billige"-hardware eingesetzt, ich hatte immer geräte die etwas besser waren

micneu

@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

slu

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

micneu

@tschan hier noch down/upload gleichzeitig, keine probleme