Zeitweiliger Paketverlust bei Vollauslastung von Telekom Glasfaser 1000 Leitung

tschan

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 offload
Disable hardware large receive offload
Enable the ALTQ support for hn NICs.

und die folgenden Tunables gesetzt (gefunden bei der Recherche im Netz):

net.isr.dispatch=deferred
net.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!

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

tschan

@micneu Ich habe mir eine neue Box mit N100 besorgt und das Problem tritt nicht mehr auf. Lag also tatsächlich an der Hardware. :)

micneu

@tschan hatte ich doch geschrieben, und ich gehe von aus das in dem N100 Intel NICs verbaut sind.