Man mag meinen, es sei normal das dass Internet langsam ist wenn gerade ein Download mit voller Auslastung der Bandbreite läuft, aber dass ist es nicht! Vielleicht könnt ihr mir weiter helfen, nachdem ich in einem anderen Forum anscheinend niemandem klar machen konnte das es sich um kein normales Verhalten handelt. Folgendes: Wenn auf meinem Linux (Arch Linux) ein Download mit voller Auslastung läuft, dann wird das Internet extrem langsam, z.B. wenn ich im Browser eine Webseite öffnen will dauerte es viele Sekunden bis sich was tut. Auch der Windows Rechner, der an den gleichen Router wie mein Linux Rechner angeschlossen ist, hat ebenfalls in dem Moment ein extrem langsames Internet. Man beachte: 1. Das war vorher nicht so, dass bei einem Download voller Auslastung das Internet langsamer wird ist logisch, aber so extrem war es noch nie. 2. Boote ich auf dem selben Rechner mit Windows statt mit Linux und und lasse den selben Download mit voller Auslastung laufen, gibt es das Problem nicht! Es liegt offensichtlich an meinem Linux. Irgendwas hat sich da getan. Es scheint so, als hätte Linux irgendwie eine besondere Priorität für die Bandbreite erhalten. Läuft erst einmal ein Download in Firefox oder Chromium, bekommen nicht mal andere Anwendungen in Linux eine faire Bandbreite zugeteilt, alles andere ist dann extrem benachteiligt. Leider weiß ich nicht wie man ein solches Verhalten konfigurieren kann, habt ihr etwas, was mir weiter helfen kann?
Um was für Downloads dreht es sich denn? Hast du überhaupt einen Router der QoS unterstützt und was ist dort aktiviert?
Ganz normale Browser Downloads. Am Router hat sich nichts geändert und es läuft ja auch problemlos mit den Windows Rechnern. Nur bei Linux machen die Downloads Probleme.
Gast
#3862589
Max M. schrieb: > Es liegt offensichtlich an meinem Linux. Irgendwas hat sich da getan. Es > scheint so, als hätte Linux irgendwie eine besondere Priorität für die > Bandbreite erhalten. > Läuft erst einmal ein Download in Firefox oder Chromium, bekommen nicht > mal andere Anwendungen in Linux eine faire Bandbreite zugeteilt, alles > andere ist dann extrem benachteiligt. Versuch den selben test mal mit wget. Ansonsten kannst du ja mal Firefox, Chromium und was du sonst an Browsern nutzt runterwerfen und neu installieren. Vielleicht löst das dein problem schon.
Das könnte weniger mit der Bandbreite als mit der Latenz zu tun haben. Deine Seite hat bei der Bandbreite nur begrenzt mitzureden, da beim Download der Upstream irrelevant ist und das Queueing im Downstream eher vom Server und dem Router deines Providers bestimmt wird. QoS betrifft eher VoIP parallel zum Download. Ping mal einen externen Server an, während solch ein Download läuft. In Linux wie in Windows (z.B. ping www.mikrocontroller.net). Wenn sich da ein erheblicher Unterschied ergibt, also Linux viel gösser als Windows ausfällt, dann ist das der Grund. Die Client-Server Interaktion dauert dann zu lang und das bremst Webseiten aus zig bis hunderten Elementen erheblich. Könnte dann eine Folge deutlich unterschiedlicher TCP-Windows sein.
Gast
#3862750
Du kannst das Verhalten mit Einstellungen im Router beeinflussen, allerdings nur, sofern fürs Surfen und Downloaden verschiedene Protokolle, Ports oder Quellen verwendet werden. Das Schlüsselwort nennt sich "Priorisierung", hat entfernt was mit "QOS" zu tun ...
Frank schrieb: > Das Schlüsselwort nennt > sich "Priorisierung", hat entfernt was mit "QOS" zu tun ... Dein Router definiert nur, was mit den Frames passiert, die er raussendet. Was mit den eingehenden Frames passiert, die er von der bösen Aussenwelt erhält, definiert die Gegenseite. Dummerweise geht es hier um die eingehenden Frames.
A. K. schrieb: > Frank schrieb: >> Das Schlüsselwort nennt >> sich "Priorisierung", hat entfernt was mit "QOS" zu tun ... > > Dein Router definiert nur, was mit den Frames passiert, die er > raussendet. Was mit den eingehenden Frames passiert, die er von der > bösen Aussenwelt erhält, definiert die Gegenseite. Dummerweise geht es > hier um die eingehenden Frames. Der UPLINK ist schon wichtig! Der Empänger eines eines TCP-Frames muß dem Absender den Empfang nämlich mit einem ACK-Frame quittieren. Tut er das nicht innerhalb einer gewissen Zeitspanne so hört der Sender auf neue Frames zu senden und der Download kommt ins stocken.Wen nun mehrere Clients gleichzeitig Downloads laufen haben kann es u.U. dazu kommen das einer den Uplink mit seinen ACK zustopft und der Andere keine Daten mehr vom erhält. Schön wäre darum zu wissen was das für eine INet-Verbindung ist und was das für ein Router ist.
Max Mustermann schrieb: > Der UPLINK ist schon wichtig! Du beziehst dich auf das klassische Problem des absaufenden Downlinks bei verstopftem Uplink. Weshalb es sich lohnt, im Uplink ACK Frames zu priorisieren. Hier geht es aber um einen unbedienbaren Browser bei parallel laufendem Download. Da ist der Downlink verstopft, der Uplink aber nur schwach belastet. Priorisierung auf dem Uplink bringt folglich nichts.
A. K. schrieb: > Da ist der Downlink verstopft, der Uplink aber nur schwach > belastet. Woher beziehst du diese Gewissheit? Ich lese nichts über die Art der INet-Verbindung.
Max Mustermann schrieb: > Woher beziehst du diese Gewissheit? Aus seiner Beschreibung, in der nichts über Uploads steht. Kann natürlich sein, dass sein Linux klammheimlich sein ganzes Fotoarchiv zwecks Begutachtung zum BKA transferiert und deshalb das Uplink zu ist, während in Windows die Leitung frei ist. ;-) > Ich lese nichts über die Art der INet-Verbindung. Half-Duplex Verbindungen sind etwas aus der Mode gekommen und UUCP habe ich auch schon länger nicht mehr gesehen. Die Belegung des Uplinks durch TCP-Downloads ist jedenfalls überschaubar.
A. K. schrieb: > Half-Duplex Verbindungen sind etwas aus der Mode gekommen und UUCP habe Ich binn mal von DSL-irgendwas ausgegangen. Aber da macht der TO ja ein Geheimnis draus.
Max Mustermann schrieb: > Ich binn mal von DSL-irgendwas ausgegangen. Für die Frage dürfte es egal sein, ob DSL oder Kabel.
A. K. schrieb: > Das könnte weniger mit der Bandbreite als mit der Latenz zu tun haben. Gut erkannt! Hier der Ping Test auf www.mikrocontroller.net: Linux Ohne Download, vier Ping Packete: 21.7 ms 23.2 ms 22.0 ms 22.3 ms Linux Mit Download: 1990 ms 1577 ms 1649 ms 1683 ms Windows Ohne Download, vier Ping Packete: 22 ms 23 ms 24 ms 24 ms Windows Mit Download: 45 ms 53 ms 47 ms 63 ms Krasse Unterschiede, nur voran liegt das??
Vielleicht hilft dir das hier: http://en.wikipedia.org/wiki/TCP_window_scale_option Also probier mal aus, was dabei rauskommt, wenn du das bei dem System mit dem Download abschaltest.
A. K. schrieb: > Vielleicht hilft dir das hier: > http://en.wikipedia.org/wiki/TCP_window_scale_option > Also probier mal aus, was dabei rauskommt, wenn du das bei dem System > mit dem Download abschaltest. Tatsächlich. Die Deaktivierung mit sysctl -w "net.ipv4.tcp_window_scaling=0" hat das Problem nun behoben, die Ping Werte sind wieder normal. War vielleicht der Wert für diese TCP window scale falsch eingestellt bzw. habe ich ein Nachteil durch die Deaktivierung?
Max M. schrieb: > habe ich ein Nachteil durch die Deaktivierung? Bei langer Leitung (Laufzeit, nicht Meter) könnte der Download verlangsamt werden. Ohne Scaling ist nämlich die Speicherkapazität der Strecke zwischen Server und deinem PC auf 64KB begrenzt, also das Produkt aus Durchsatz und Laufzeit. Wie du hier sehen kannst ist eine automatische Optimierung einer TCP Strecke nicht ganz so einfach.
Nützliches Tool zur Netzwerkanalyse. Ggf. Info lesen, die sammeln damit natürlich auch Daten zur weltweiten Netzwerkqualität: http://netalyzr.icsi.berkeley.edu/
Vielen Dank A.K. wieder was gelernt :-) Mfg Udo
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.