Unitymedia Origin und Vodafone

[maffle]

https://eternallybored.org/misc/wget/releases/wget-1.21.1-1-win64.zip runterladen und zb in c:\temp entpacken, nix installiern

dann cmd.exe öffnen cd c:\temp\wget

 

[floh667]

hab das nun einige male gemacht. Also die 10mb/s erreich ich nie, aber er lädt dann immer abwechselnd mit ~65mb/s oder mit ~90mb/s runter. Ich kann das Phänomen von dir sozusagen reproduzieren, aber in stark abgeschwächter Form.

 

[maffle]

Das deutet auf das besagte Problem hin. Zwar nicht so extrem wie bei mir, aber auch teilweise. Normal ist dass er immer bei jedem Try max speed liefert. Wenn du den "broken" state hast mit um die 60, läuft er den ganzen download durch mit 60 oder "fängt" er sich später und geht hoch? Teste mal mit ner größeren Datei wo du etwas länger laufen lassen kannst:

wget -O /dev/null http://v4.speedtest.belwue.net/10G

An meinem Windows 10 Pc mit der 10 Euro Karte und aktuellsten Treibern von 2021 UND allen hw offload force off kann ich den download 100 mal anhaun abbrechen und er fängt jedesmal mit >=90mb/s an und ist rock stable dann bei 112mb/s nach 2 Sekunden über den gesamten Download. Mit Treiber default settings kommt es auch zu dem bug.

Das mit dem "zufällig" niedrigen Wert und dann durchgehend niedrig hatte ich ja wie gesagt mit dem "uralt" Broadcom lan chip.

Und auch mit 2 (einmal Realtek und einmal ASIX ) usb3.0 gbit dongles, und die sind dann sogar bei 5-10mb/s broken randomartig. Bei denen hab ich den Verdacht, dass der Windows 10 tcp window irgend ein bug hat mit usb dongles, vielleicht wegen dem energiesparmodus. Oder die hw offload off setting nicht berücksichtigt wird wieso auch immer.

Kann natürlich aber auch sein, dass deine Leitung Fehler aufwirft und das Segment runterregeln wegen zu vielen Fehler bzw Fehlerkorrektur nich hinterher kommt.

Du brauchst dringend ein zweiten vergleichs PC mit Windows 10 und neuster Hardware um das gegen zu testen. Kein Laptop oder Tablet mit usb3 gbit dongle!

 

[maffle]

Wenn du n realtek chip auf dem Board hast lad mal neusten Treiber von:

https://www.realtek.com/en/componen...0-100-1000m-gigabit-ethernet-usb-3-0-software

Ich nutz zzt: 10.47.121.2021

Und dann setz folgendes in den Treiber settings:

Das alles auf deaktiviert setzen und reboot.

Bei einigen Treibern/Herstellern hab ich den verdacht, dass die Einstellungen fehlerhaft umgesetzt werden oder ignoriert werden, insbesondere bei usb3.0 gbit donglen.

 

[floh667]

ich könnte vorsichtig behaupten, dass das gänzliche Abschalten jeglicher Prüfsummenabladungen eine leichte stabilisierung bewirkt hat. egal wie oft ich den nvidia download starte, geht er auf mindestens 70mb/s hoch. manchmal startet er fürn bruchteil von einer sekunde bei so 40mb/s, geht aber dann sofort hoch, auch oft auf 80mb/s+
Ähnliches bei belwue. die 100mb/s erreich ich aber bei keinen der beiden. Aber das kann durchaus an windows 7 vllt liegen oder dem 0815 realtek chip. Aber so gravierende Einbrüche wie du sie aufgezeigt hattest, hab ich nicht. Vorhin kams kurz mal vor dass er mal 3 sekunden mit 8mb/s gestartet hat, ging dann aber auch auf die 70mb/s+ hoch.

Was die treiber angeht, so hab ich die aktuellsten für windows 7 drauf. die sind vom Oktober 2020
was erreichst du bei https://www.computerbase.de/downloads/betriebssysteme/windows-10/ ?

 

[maffle]

Ja. Und jetzt noch bitte n vergleichs Windows 10 PC mit aktuellen Treibern, dazu dann die settings von oben damit. Zeig mal was TcpOptimizer dir anzeigt im start gui:

das rechte sollte alles auf disabled stehn. ist etwas vermischt mit settings die es unter Win7 nicht gibt.

Bei mir funktioniert der Broadcom chip zb nicht und erzeugt das Problem, so wie die usb3 dongles auch. Erst der neure Realtek PCIe chip mit den obigen settings hat das Problem gelöst.

 

[floh667]

sieht unauffällig aus, wie bei dir

 

[maffle]

Kannst ja mal nochn Test die Tage machen mit ner neuesten Ubuntu LiveCD, und dann auch mit wget wie oben. Die settings sollten aber passen jetzt.

https://ubuntu.com/download/desktop

https://rufus.ie/en_US/

gpt partition (bei uefi, aber dein pc dürfte dafür zu alt sein dann mbr denke ich), fat32.

Nach boot einfach try out, beim booten auf Deutsch setzen, dann in der GUI "terminal" öffnen und wget selbe Befehle. Kannst die wget commands auch ine txt file packen auf dem usb stick ist ja fat32.

hier noch zwei:

wget -O /dev/null http://speed.hetzner.de/1GB.bin
wget -O /dev/null http://speedtest.tele2.net/1GB.zip

 

[floh667]

ja versuch ich die tage mal, muss mir allerdings neue rohlinge zulegen, hab keine mehr.
die beiden laufen auch unauffällig, wobei tele2 tendentiell besser geht und öfters die 90mb/s schaff. hetzner liegt bei ~80mb/s

 

[maffle]

Rohlinge!?????? usb stick... !?

https://www.amazon.de/SanDisk-Ultra-Flair-USB-Flash-Laufwerk-150-MB/dp/B015CH1JIW/ref=sr_1_4?__mk_de_DE=ÅMÅŽÕÑ&dchild=1&keywords=usb+stick&qid=1619403799&sr=8-4

Ja wie gesagt, mit den settings von oben mit dem offloading off sollte es besser laufen.

 

[floh667]

ich könnts meinen, aber kann auch nur placebo sein. ich werd die einstellungen mal so beibehalten und die tage einfach schauen wie alles so läuft und demnächst die linux lvie mal noch testen.

 

[floh667]

@maffle
hab mal nen ubuntu image auf den usb stick geschrieben, aber es will nicht booten. krieg irgend nen grub boot fehler

symbol grub_register_command_lockdown not found

*edit*
hat sich erledigt. Ich musste rufus 3.14 beta nutzen, mit der .13 macht grub wohl Probleme.

also nach ein paar tests unter linux konnte ich weiterhin keine Abfälle der datenrate reproduzieren. ich komm allerdings auch bei keinen der testfiles (inklusive dem nvidia server) über 75mb/s

 

[shm0]

Das Abschalten der Offloads hat aber mehr CPU Last zur Folge.
Large Send Offload hat nur auf Uploads Einfluss.
Unterstützt die Netzwerke Receive Side Scaling (RSS) um die Rechenlast auf mehrere CPU Kerne zu verteilen?

Das Problem mit den FX CPUs ist, dass sich 2 CPU Kerne, die jeweils in einem Modul stecken, sich viele Sachen teilen müssen (Prediction Engine, L1/L2 Cache, Floating Point Unit etc...)
Da gab es glaub ich auch eine Klage gegen AMD deswegen.

 

[maffle]

@shm0 daher sagte ich ja, was er da hat ist Elektroschrott. Und das hat auch das fiepen verursacht mit neueren Settings, vermutlich weil die CPU dann aus den Löchern fliegt. Er braucht dringend ein neueren PC.

Und nein, die mehrlast ist gering. Ich hatte doch alles zu gesagt, dass die settings nicht funktionieren auf den meisten Treibern, dazu gibt es auch ein post hier von den Machern vom TcpOptimizer:

https://www.speedguide.net/faq/should-i-enable-tcp-offloading-449

Specific hardware recommendations:
In Realtek Gigabit Network Adapters, disable: Flow Control (Rx & Tx DISABLED). Disabling Flow Control can reduce timeouts and considerably improve throughput under Windows 8, most likely due to buggy implementation at the driver level.

For Intel/Broadcom Adapters, Large Send Offload (LSO) can cause issues, disable it at the adapter driver level, and possibly in the OS TCP/IP network stack.

This recommendation stems from some buggy NIC drivers, that, when combined with TCP Offloading and multi-threaded applications can cause havoc to the NIC driver. It seems to be related to applications switching threads causing the NIC driver to switch its active TCP Offload connection in the NIC hardware and that switching process is prone to failure or excessive delay.

Das ist ein reinstes Debakel unter Windows und dürfte das Problem bei vielen sein die Download Probleme haben.

Ich habe mir gestern 2,4GBit Wifi zum testen geholt und auch dort zeigt sich das Problem mal wieder, und bei der Intel Wifi Karte kann man offload nicht deaktivieren.

 

[floh667]

daher sagte ich ja, was er da hat ist Elektroschrott. Und das hat auch das fiepen verursacht mit neueren Settings, vermutlich weil die CPU dann aus den Löchern fliegt. Er braucht dringend ein neueren PC.

Welches fiepsen?
mein PC ist i.O die CPU hat keinerlei Probleme mit 1gbit durchsatz. Wenn dann ist es eher der 0815 realtek chipsatz. Jtzt hört mal auf die CPU zu dissen, ihr tut grad so als wäre die zu schwach 1gbit durchsatz zu generieren, was totaler Blödsinn ist. Die langweilt sich, wenn bei speedtest.net 940mbit durch die leitung kommen.

 

[shm0]

....
This recommendation stems from some buggy NIC drivers, that, when combined with TCP Offloading and multi-threaded applications can cause havoc to the NIC driver.
.....

Ich glaube das letzte OS das TCP Offloading unterstützt hat, ist Windows Server 2008.

https://docs.microsoft.com/de-de/wi...ork-subsystem/net-sub-performance-tuning-nics

Verwenden Sie nicht die Auslagerungs Features ... oder TCP Chimney Auslagerung. Diese Technologien sind in Windows Server 2016 veraltet und können sich negativ auf die Server-und Netzwerkleistung auswirken. Außerdem werden diese Technologien möglicherweise in Zukunft nicht von Microsoft unterstützt.

Ich hab bis jetzt auch noch nicht einen Netzwerkadapter für den Home Gebrauch gesehen, der TCP Offload unterstützt.

Und ja, ein FX 8350 sollte für Gbit reichen.

 

[maffle]

Ich glaube das letzte OS das TCP Offloading unterstützt hat, ist Windows Server 2008.

Nein. Wie oft soll ich eigentlich hier noch posten, dass die Deaktivierung sämtlicher Offloading settings, darunter auch checksum offloading und LSO, im Realtek Treiber meine Probleme beseitigt hat? Ich habe jetzt noch mal die Probe gemacht, angemacht, reboot. Direkt Fehler reproduzierbar. Deaktiviert, reboot, Fehler weg zu 100%.

Ist mir jetzt aber egal dass du hier Fake News verbreitest.

Mit usb3 adaptern und Wifi kann ich das Problem jedoch nicht beheben wenn ich das offloading abschalte. Vielleicht ist die Option nicht nutzbar für usb und ist nur als "Leiche" in den Optionen, weil der chip der selbe ist für PCIe und USB3, wird aber ignoriert. Bei den Wifi Intel Treibern Fehlt die Option gänzlich.

Mit den Intel Wifi hab ich fener das Problem, dass die offloading settings sich nach jedem reboot wieder auf enable setzen, die ich per TcpOptimizer ausstellen kann per registry. Könnte sein, dass der Intel Treiber die einfach immer auf on resettet.

 

[shm0]

Vielleicht hat deine Realtek Karte bzw der Treiber wirklich Probleme mit den Offloads.
Ich nutze eine Intel Karte, mit aktivierten Offloads + LSO aktiviert + Flow Control aktiviert und keine Probleme.

LSO "sammelt" Netzwerk Pakete (bis zu 64kb glaub ich) bevor diese an die Netzwerkkarte übergeben werden. Der einzige Vorteil wäre vielleicht eine geringere Latenz (in Senderichtung), da die Pakete direkt an den Netzwerkadapter weitergeleitet werden. Aber keine Ahnung wie viel man da an Latenz einspart, 1-2 ms?

Auf Routern mit QoS/Traffic Shaping kann es von Vorteil sein LSO zu deaktivieren (heißt da GSO (Linux) glaub ich), da die Queue Discipline(s) dann nicht mit dem (gemischten) Super-Paket arbeiten müssen sondern direkt mit den wirklich einzelnen Paketen.
Ist die Upload Bandbreite aber ausreichend, macht dass auch nicht wirklich einen Unterschied.

TCP Time Stamps sollte man jetzt auch nicht unbedingt deaktivieren, da manche TCP Congestion Algos diese nutzen, um die Round Trip Time zu bestimmen (Googles neuer BBR zum Beispiel und wahrscheinlich auch andere) und damit das TCP Window dynamisch anpassen.
Time Stamps haben auch andere Vorteile

 

[maffle]

TCP Time Stamps

Die Theory hatte ich auch schon, das Problem kann ich nämlich nur zu bestimmen servern auslösen, wenn es auftritt. Aber das kann auch an dem tcp window liegen, wenn die strecke etwas weiter ist oder latenzlastiger. Jedenfalls ist da irgendwo der Wurm drinn in Windows. Bei mir ist es jedoch auch so, dass ich unter Linux weniger Durchsatz schaffe, meistens um die 70-80mb/s anstatt konstant 100-112mb/s wenn es "läuft".

Ich kann es mir nicht erklären woran es nun genau liegt, es scheint ein Zusammenspiel von Faktoren zu sein, die dann das Problem auslösen.

Ich habe jetzt schon mehrfach gelesen, dass der Windows 10 tcp algo nur mit "neueren routern" zusamm funktioniert, wie ist das bitte zu erklären? Was hat mein Router nun damit zu tun, vielleicht ist die VFS ja doch irgendwie inkompatibel damit.

Schalte ich zb den tcp algo aus mit:

netsh int tcp set global autotuninglevel=disabled

erzeugt das instant das Problem was ich habe, es kommen nur noch um die 4-5mb/s durch egal von welcher Quelle.

Schalte ich es dann wieder zurück auf

netsh int tcp set global autotuninglevel=normal

kommt es oft vor, dass die Verbindungen für ne gewisse Zeit "gestört" sind also immer noch auf 4-5mb/s rumgammeln, und dann randomartig wieder funktioniern, dann aber randomartig wieder gestört sind.

Schalte ich alle offload settings aus im Realtek Treiber, kommt das Problem nicht mehr vor, zumindest sieht es danach aus.

Teste ich dann wieder mit anderen Endgeräten, zB usb3 dongles, kann ich das Problem wieder erzeugen.

Selbes Problem über Wifi6 mit ner Intel AX200 Karte mit stabiler 2,4Gbit Verbindung. Dort hab ich zb wieder das selbe Problem, dass es oft bei 5mb/s anfängt und erst nach sage und schreibe 40-60 Sekunden plötzlich hoch springt auf 90mb/s.

In dem tcp algo von Windows ist also irgendwo der Wurm drinn. Wie ich das verstanden habe soll der algo das ja "ausloten" und die bytes der tcp verbindung stückweise hochsetzen, und somit "erkennen" dass es eine gute Leitung ist die diese liefern kann. Irgendwie erkennt er das aber nicht immer korrekt.

Bei Windows 7 konnte man das tcp window noch manuell einstellen, das geht bei Windows 10 aber nicht mehr.

 

[shm0]

autotuninglevel=disabled limitiert die Window Size auf 65,535 bytes.
"Normal" erlaubt es die Window Size über diesen Wert hinaus zu vergrößern (Hohe Bandbreite und/oder hohe Latenz)

Die Window Size wird nur von den End Points ausgehandelt.
Also ich wüsste jetzt nicht was der Router damit zu tun haben sollte.
Vielleicht wenn Paket Loss auf der Leitung auftritt (oder der Router unterdimensioniert ist und Pakete verwirft)
und der Windows Algo das erkennt und daraufhin das TCP Window verkleinert...

Dass die Geschwindigkeit am Anfang langsamer ist, ist eigentlich normal (TCP Slow Start).
Das TCP Window wird erst nach und nach vergrößert um Paket Loss vorzubeugen.
Die Anfangsgröße dieses Fensters lässt sich anpassen. (Linux -> initcwnd, Windows -> InitialCongestionWindow)
Diverse Hosting Dienste nutzen da unterschiedliche Werte.