Realtek 2,5 Gbit - Alle 2 Sekunden Timeout bei Übertragungen

conf_t

Admiral
Registriert
Juni 2008
Beiträge
8.827
Hallo,

ich habe aktuell nicht die wirklich zündende Idee (mehr) woran das Problem liegen kann. Folgende Hardware

PC:
AMD 5900x
Gigabyte Aorus B550 Pro V2 BIOS F15d (mit besagter Realtek 2,5 Gbit) (Realtek Treiber 1125.11.1206.2022, aktuelle AMD Treiber)
Windows 11 Pro x64 [Version 10.0.22621.1265]
Seagate Firecude 520 SSD (Nvme)

PC ist angeschlossen an
Linksys LGS308 Switch mit aktuellstem Rommon und Firmware
Links: 1 Gbit/s FD
Über die das Internet per FB 7590 (7.50) bereitgestellt wird, aber das Problem ist weder das Internet, noch die FB noch der Linksys Switch.

Netzwerkübersicht (zum besseren Verständnis, was ihc getestet habe.
1676825991666.png



Problem:
Sobald ich eine Datei auf mein NAS kopiere, bricht für alle 2 Sekunden die Verbindungsgeschwindigkeit für 2 Sekunden ein. Was ist NICHT habe, ist eine Verbindungsunterbrechung und ohne Dateiübertragung auch absolut unauffällige Latenz. Im Ping sehr schön zu sehen, aber auch in der Übertragung:

Ab dem 14. Ping ist die Übertragung beendet, das Ziel, was ich hier anpinge ist nicht das Ziel der Dateiübertragung, die geht auf 192.168.3.4, einfach um das Ziel als Ursache auszuschließen:
1676822718438.png


1676822784284.png


Das Problem war mir vor Wochen, ich weiß schon nicht mehr genau, aufgefallen, hatte aber nie Lust mich zu kümmern. Aber irgendwann nervt es halt doch. Da das schon so lange zurück liegt kann ich nicht sagen, wann es auftrat (habe mit Haussanierung und Umzug gerade zu viel um die Ohren). Früher jedenfalls also 2021 defintiv, gab es mit gleicher HW das Problem nicht. Mangels Zeit habe ich an dem PC schon ewig nichts mehr installiert.

Im Wireshark sieht das recht interessant aus. Es sind parallel die Verbindung mit meinem VPN Client (192.168.3.128) und em NAS (192.168.3.4) zu sehen. Beide Traffic behandelt der PC gleich (Traffic ist ohne Anzeige- oder Capturefilter, dur das eine Paket, was eine der Public IPs verraten könnte habe ich unkenntlich gemacht).

Ich habe mir verschiedenen Traffic angeschaut zu verschiedenen Zielen und komme zu dem Schluss, dass scheinbar die eingehenden Pakete zulange gepuffert werden, oder der Interrupt zur CPU zu spät ist. Da das auch ICMP betrifft, hat das jetzt nichts mit dem eigentlichen SMB Protokoll oder TCP zu tun. Sondern hier muss der Fehler ab IPv4 abwärts in den OSI-Layer liegen. Das kann natürlich dann am PC Retransmissions auslösen.


1676824772849.png





Was ich bisher gemacht habe:
  • Den NIC Treiber auf die (oben aufgelietete) Treiberversion geupdatet, davor war der Treiber von 09/22 drauf (weiß gerade nicht die Version.
  • TCP-IP Stack zurückgesetzt
  • mit TCP Optimizer die Windows Defaults hergestellt (war eigentlich auch nichts verstellt)
  • Den AMD-Chip Treiber aktualisiert (halte das aber nicht für die Ursache).
  • Während einer Übertragen von verschiedene Ziele verschiedene Ziele angepingt. Das Verhalten ist nur an dem PC zu sehen, also vermute ich auch dort die Ursachen.
  • Mir die Portstatistiken am Switch angeschaut - 0 Errors (CRC), also es sind keine Pakete verloren gegangen auf der Infrastruktur.
  • Gegoogelt (Realtek 2,5 2000 ms Spikes)
  • Mit den Traffic mit Wireshark angeschaut, hat mir zumindest gezeigt, dass eingehend das Problem ist und unterhalb von OSI-Layer4 und wegen der anderen Tests oberhalb von OSI-Layer 2.
  • Switch rebootet
  • Während einer Übertragung zwischen PC und NAS vom Switch die 192.168.3.1 angepingt. Die rund 2000 ms Latenz, die ich vom PC aus zum gleichen Ziel habe, waren nicht auszumachen:
1676825727149.png
 
Zuletzt bearbeitet:
Hast Du mal im Treiber die Einstellungen bei kontrolliert ? Green Ethernet und sonstige Energieeinsparoptionen würde ich mal ausschalten. Eigentlich sind die Realtek in der letzten Zeit recht unproblematisch.
 
  • Gefällt mir
Reaktionen: conf_t
wtf.. Route Flapping und co können zu solcher symptomatik führen.
Ich habe schon VMs gesehen, die sich aufgrund von Bugs im Hypervisor so verhalten haben.
Aber alles in der Richtung ist bei dir nicht anwendbar und vermutlich hast du da auch schon dran gedacht.

Bei Mellanox Connect-X 5 karten habe ich was ähnliches mal unter Freebsd gesehen. Hier wurde beim Upgrade auf FreeBSD13 eine neue Firmware geflashed und nach dem Rollback gab es ein Zusammenspiel zwischen neuer Firmware und dem in FreeBSD 12 geladenen treibern.

Boote kurz Ubuntu und schau ob es a auch passiert? Einfach um Treiber halbwegs auszuschließen
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: conf_t
@Mummi74 Guter Einwurf, es war aber nicht "Green-Ethernet", oder "Energy-Efficient Ethernet, sondern im Treiber der "Power Saving Mode". Die 3 Optionen klingen irgendwie austauschbar. ;)
 
  • Gefällt mir
Reaktionen: Engaged und Mummi74
conf_t schrieb:
Es sind parallel die Verbindung mit meinem VPN Client (192.168.3.128) und em NAS (192.168.3.4) zu sehen.
Übers VPN läuft offenbar eine RDP Verbindung. Die Datenmenge sollte signifikant kleiner sein, als die der SMB Verbindung. Das kannst du mit den Wireshark Analysen herausfinden. Ist das so?
Gibt es das Problem nur in Upload- oder auch in Downloadrichtung?
Was ergeben iperf Tests? Im Moment testest du ja eher den Massenspeicher, nicht die Netzwerkverbindung.

conf_t schrieb:
Ich habe mir verschiedenen Traffic angeschaut zu verschiedenen Zielen und komme zu dem Schluss, dass scheinbar die eingehenden Pakete zulange gepuffert werden, oder der Interrupt zur CPU zu spät ist.
Wie kommst du darauf? Das kann ich den Traces nicht entnehmen. Und selbst wenn die Pakete gepuffert werden, wäre das bei einem entsprechenden RWIN Wert unkritisch. Der wird aber von Windows automatisch angepasst in der Default-Einstellung.

Um einen Einfluss des Massenspeichers auszuschließen, solltest du auf jeden Fall iperf3 Tests machen, und zwar mit TCP und UDP.
 
Ihr habt das Thema eigentlich schon gut abgearbeitet. Ich sehe im Schaubild leider nicht, wohin die Datenübertragung stattfindet. Vermutlich ist es auch egal, da der Ping zum Router ja auch stockt.

Als erste Diagnose, also deutlich vor Wireshark ;-), würde ich empfehlen Mal eine direkte Verbindung (ohne Switch etc) zu probieren. Wie sieht es da aus?
 
Danke für eure Beiträge, ich weiß aber nicht wohin die Diskussion noch führen soll:
conf_t schrieb:
es war […] im Treiber der "Power Saving Mode"
…. Reproduzierbar.
 
  • Gefällt mir
Reaktionen: Mu Wupp, Mummi74 und andy_0
_anonymous0815_ schrieb:
https://www.reddit.com/r/gigabytega...orus_pro_realtek_25g_network_adapter_problem/

Dort meckern auch einige mit dem Board über diverse Probleme.

Einer hat es "behoben" indem er auf eine ältere Treiberversion zurück ist.

Probiere aktuell mehrere Treiber für den "Realtek PCIe Family Controller" und kann sagen das der neueste Treiber nicht der schnellste ist. Ich habe keine Belege dafür, aber arbeite stets mit den selben Settings um besser vergleichen zu können. Mögen es auch nur Nuancen sein sind sie dennoch spürbar.

Seit letztem Jahr im Oktober gab es keinen neuen Treiber mehr. Angepasst wurden bis heute heute lediglich die *.inf Dateien und das war es auch schon.
 
Ich würde mir testhalber bei Amazon mal eine 2.5G Karte mit Realtek Chipsatz bestellen und mit dieser testen.

Ansonsten, falls vorhanden, folgende Sachen testhalber ausstellen: Interrupt Moderation, Jumbo Frames, Fluss-Steuerung (Flow Control) sowie alles, was mit Energy Efficient, Green oder Power-Save zu tun hat.
 
Ein schnödes Treiberupdate (1125.14.611.2023) hat das Problem der geringen Upload-Bandbreite grundlegend behoben, denn später im 2,5 Gbit/s LAN war noch immer nicht an Volle Geschwindigkeit zu denken.
 
  • Gefällt mir
Reaktionen: Mummi74 und madmax2010
Zurück
Oben