Internet-Geräte

Siehe neueste

VFS / Arris TG3442DE Bug: Windows10 + USB gbit dongle = geringer speed

maffle
Smart-Analyzer

Ich möchte einen bug melden für die VFS /  Arris TG3442DE.

Firmware: 01.02.068.11.EURO.SIP

Windows 10: 20H2 19042.928

 

Ich habe folgendes Problem und bin mir mittlerweile ziemlich sicher, dass das ein Bug mit der VFS sein muss.

 

Benutze ich einen USB3.0 gbit dongle bekomme ich nur 3-6mb/s, abundzu startet es hoch sinkt dann aber rapide ab auf <10mb/s.

 

Das Problem kann ich an verschiedenen Windows 10 Geräten reproduziren. Getestet wurden zwei verschiedene USB3.0 dongle, einmal Realtek, einmal Asix Chipsatz. Beide einige Treiber Versionen probiert.

 

Auch verschiedene CAT6 Kabel wurden getestet und ausgeschlossen.

 

Einen ordnungsgemäßigen Betrieb kann ich nur über eine interne PCIe gbit Karte erzeugen und auch nur, wenn diese alle Optionen für "hw offloading" abgeschaltet hat in den Treiber Einstellungen.

 

Die Optionen des "hw offloadings" hat keinerlei Auswirkung für das Problem bei den USB dongles.

 

Die dongle funktionieren korrekt im LAN selber und erzeugen normale 1gbit Geschwindigkeiten. Nur wenn diese direkt an der VFS verbunden sind ist der Fehler erzeugbar.

Mehr anzeigen
5 Antworten 5
reneromann
SuperUser

Wenn du mit einer "richtigen" Netzwerkkarte keine Probleme hast, würde ich eher auf den Dongle und nicht auf die Station tippen. Davon abgesehen sind diese USB-Adapter eh immer nur Krücken - weil sie, wenn sie nicht gerade an USB 3.2 Gen2-Anschlüssen (10 GBit/s) betrieben werden und auch USB 3.2 Gen 2 unterstützen, aufgrund des ganzen USB-Protokolloverheads limitiert sind. Und wenn dann am gleichen USB-Port noch andere Geräte, z.B. Mäuse und Tastaturen, angeschlossen sind, belegen die ebenfalls einen Teil der Bandbreite des Host-Ports und das war's dann.

(1)
Mehr anzeigen
maffle
Smart-Analyzer

Nein... deine Antwort ist vermutlich nett gemeint. Leider erzeugt sie eher nur Frust bei mir. Ich weiß schon was ich tue. Ich bin selber Informatiker.

 

Das ganze scheint ein Bug in Verbindung mit dem "TCP receive window" zu sein und vermutlich einer Fehlerhaften Implementierung von Windows 10 in Bezug auf USB3.0 gbit Adaptern und/oder in Verbindung mit der VFS. Und/oder versursacht oder verstärkt durch die VFS.

 

Setze ich den tcp und winsock zurück, reboote, kommt es erstmal zu dem beschriebenen Problem. Setze ich dann folgendes:

netsh int tcp set global autotuninglevel=experimental

Erzeugt dies keine Besserung. Setze ich nun jedoch auch noch:

 

netsh interface tcp set heuristics disabled

 

funktioniert der Download über den USB dongle kurzeitig mit maxspeed:

 

C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:20:11-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 100%[=================================================>] 562,06M 111MB/s in 5,2s

2021-04-20 18:20:16 (108 MB/s) - '/dev/null' saved [589364424/589364424]


C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:20:24-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 100%[=================================================>] 562,06M 113MB/s in 5,2s

2021-04-20 18:20:30 (108 MB/s) - '/dev/null' saved [589364424/589364424]

 

verfällt dann aber nach zufälliger Zeit wieder in den "verbuggten Zustand" und springt dann hin und her. Der verbuggte Zustand bleibt dann erhalten über den ganzen Download:

 

C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:22:37-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 10%[====> ] 56,98M 4,59MB/s eta 94s ^C
C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:23:24-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 100%[=================================================>] 562,06M 112MB/s in 5,1s

2021-04-20 18:23:29 (110 MB/s) - '/dev/null' saved [589364424/589364424]


C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:23:31-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 7%[==> ] 42,39M 4,87MB/s eta 67s ^C
C:\Programme (frei)\wget>wget -O /dev/null http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
--2021-04-20 18:23:38-- http://de.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving de.download.nvidia.com (de.download.nvidia.com)... 192.229.221.58
Connecting to de.download.nvidia.com (de.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: '/dev/null'

/dev/null 41%[===================> ] 230,57M 105MB/s ^C

 

Ein schneller Wechsel lässt das Problem nach einiger zufälligen Zeit erscheinen, indem man wie in diesen Beispielen TCP Downloads startet diese schnell abbricht und neue startet.

 

Das Problem tritt nur in Verbindung mit USB3.0 gbit Adaptern auf in Kombination von Windows 10 und der VFS.

 

Und jetzt bitte keine "Das Internet ist ein shared Medium" oder "dein Segment könnte überlastet sein" Unfug, die Antwort darauf ist nein und nein. Und nein, an dem Server in diesen Beispielen liegt es auch nicht.

Mehr anzeigen
reneromann
SuperUser

Wenn es Probleme mit dem TCP Receive Window gibt, hat das aber nichts mit der Vodafone Station zu tun - denn die hat mit dem Receive Window des Clients rein gar nichts zu tun - das Receive Window wird alleine zwischen Client und Server ausgehandelt, die Router in der Kette dazwischen machen daran rein gar nichts.

Wenn es sich also um ein Treiber- oder TCP-Stack-Problem handelt, kann die VFS da rein gar nichts dran ändern.

 

Mal ganz davon abgesehen, dass dein "Test" kein richtiger Test ist - ein CDN muss nicht zwangsläufig immer mit maximaler Geschwindigkeit die Dateien anbieten können; das hängt vom jeweiligen Edge Node ab (da können auch mehrere verschiedene Edge Nodes unter der gleichen IP erreichbar sein).

(1)
Mehr anzeigen
maffle
Smart-Analyzer

"Mal ganz davon abgesehen, dass dein "Test" kein richtiger Test ist - ein CDN muss nicht zwangsläufig immer mit maximaler Geschwindigkeit die Dateien anbieten können" ...

 

Ich habe extra angemerkt, dass es sich NICHT um Probleme des Servers handeln. Das habe ich in allenmöglichen Test Szenarien bereits ausgeschlossen. Auch Iperf Tests habe ich durchgeführt, das war mir aber zu läsig in den Post zu packen mit Beispielen.

 

Den Test kann ich über eine PCIe Karte unendlich oft wiederholen, ohne dass das Problem auftritt. Es tritt nur in Verbindung mit bestimmten Endgeräten auf und in Verbindung der VFS. In diesem Falle USB3.0 Adapter.

 

Ich habe noch eine uralte onboard gbit Karte mit Broadcom chip, die das Problem auch zeigt aber in selteren Perioden. Daraufhin hatte ich mir eine 10 Euro PCIe Karte gekauft mit Realtek chip. Auch diese zeigte die Probleme bis ich alle tcp und checksum "hw offload" settings deaktiviert habe in den driver settings. Erst dann und auch nur mit der heuristic disabled läuft es stabil und ich erreiche zu 100% jedesmal max speed. Egal wie oft ich die Downloads neu starte. 10 mal oder 100 mal hintereinander.

 

Vor einigen Monaten bei einer älteren FW Version < 01.02.068.11.EURO.SIP kam das Problem auch öfter vor, und auch bei einer Karte, bei der es jetzt nicht mehr auftritt. Daher habe ich sehr wohl den Verdacht, dass die VFS einen Einfluss auf das Problem hat. Ping mant die VFS zB auch an:

 

root@wrtarm:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=1.725 ms
64 bytes from 192.168.0.1: seq=1 ttl=64 time=1.564 ms
64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.880 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.057 ms
64 bytes from 192.168.0.1: seq=4 ttl=64 time=1.136 ms
64 bytes from 192.168.0.1: seq=5 ttl=64 time=2.004 ms
64 bytes from 192.168.0.1: seq=6 ttl=64 time=2.150 ms

 

bekommt man ungewöhnlich hohe Ping antworten von der VFS, was nicht normal ist im LAN. Dies könnte sich negativ auf den tcp receive window algorhtimus auswirken. Normale Ping Antwortzeiten im LAN sind <= 0.5ms:

 

root@wrtarm:~# ping 10.0.0.124
PING 10.0.0.124 (10.0.0.124): 56 data bytes
64 bytes from 10.0.0.124: seq=0 ttl=64 time=0.466 ms
64 bytes from 10.0.0.124: seq=1 ttl=64 time=0.416 ms
64 bytes from 10.0.0.124: seq=2 ttl=64 time=0.442 ms
64 bytes from 10.0.0.124: seq=3 ttl=64 time=0.456 ms

Mehr anzeigen
kabelmantel
Digitalisierer

Ob es sich hier um ein verhunztes Engeriemanagement handeln könnte (Green Ethernet und Konsorten bzw. evtl. sogar USB-Seitig induziert)?

 

Als ob der Netzwerkchip nicht richtig aus dem energy saving kommt und deshalb hoher durchsatz nur zur Verfügung steht, wenn die CPU alles übernimmt...

Mehr anzeigen