Fiber Power Ultra - Wie kommt man an die volle Bandbreite?

[fallenguru]

Hallo die Zweite,

entschuldigt den Parallelthread, aber da es um etwas ganz Anderes geht, dachte ich, ich mach lieber zwei. Seit ein paar Tagen hab ich hier also Fiber Power Ultra. Vorher hatte ich nominell 35/4 und >95% davon habe ich (an einem Arris Modem) auch "netto" bekommen. Jetzt bekomme ich nominell ja 100/10. Das Arris Modem, das ich wegen eines verschleppten Modem-Tausches noch ein, zwei Tage mit dem neuen Vertrag betrieben habe, kam auf beachtliche 45/10, das Ubee, das jetzt dran hängt, "nur" auf 80/9 (wenn's hoch kommt), normal sind eher so 60/9. Gut, ist immer noch viel schneller als vorher / alles Andere, aber ich denke mir, vielleicht kann man da ja was machen.

1) Mein Linux-Router hat zwar nur 100er Interfaces, kann diese aber problemlos auslasten. Die CPU-Last ist verschwindend gering. Es kann natürlich sein, daß man den TCP/IP-Stack für diese vergleichsweise high-BDP-Verbindung wirklich manuell tunen muß ... Was macht denn z. B. dieser "Optimizer", den Chello anpreist, konkret?

2) Ist das Ubee Modem das, was man momentan haben will? Was statt dessen? An sich hatte ich mir ein Cisco ausgehandelt - I <3 Cisco -, aber sie hatten angeblich keines da ... Wichtig wäre mir ein Modem ohne oder mit vollständig deaktivierbarem WLAN - hier funkt schon genug herum und ich brauch nicht noch einen Unsicherheits-Vektor.

3) Ich kann gerne irgendwelche Leitungswerte posten, wenn mir jemand verrät, wie ich da dran komme . (Von Kabelnetzen und eigentlich Allem unter IP-Niveau hab ich keine Ahnung ...)

[Rocky_Balboa]

Ne, schneller wirds nimmer.

[Roland M.]

Hallo!

das Ubee, das jetzt dran hängt, "nur" auf 80/9 (wenn's hoch kommt), normal sind eher so 60/9.

Hint: "bis zu"!
Und schneller als das nächst kleinere Produkt ist es allemal...


Roland

[fallenguru]

Hint: "bis zu"!

Sehr hilfreich. Mir ist schon klar, daß die Bandbreite nicht garantiert ist ... ...
Trotzdem, viele Leute erreichen zumindest unter optimalen Bedingungen (= 3 Uhr früh ) die vollen 100 Mbps, ich nicht. Da wüßte ich halt gerne zumindest, ob es
* am Modem
* am Router und/oder dessen TCP/IP stack
* an den Leitungswerten
* an der Auslastung des geteilten Netzes (vergessen zu erwähnen: 1190 Wien)
* an ...
liegt, daß hier nicht mehr geht. Je nach dem kann man dann ev. etwas machen oder eben auch nicht.

[Sin10]

kann auch sein, das du an deinen verteiler paar sauger drinen hast, dann erreichst du die bandbreite auch nicht mitten in der nacht.

[berndy2001]

Es kann natürlich sein, daß man den TCP/IP-Stack für diese vergleichsweise high-BDP-Verbindung wirklich manuell tunen muß ...

Hast du das schon ausgeschlossen, sprich ohne irgendwelche Router probiert?

[sim-value]

Mein Linux-Router hat zwar nur 100er Interfaces, kann diese aber problemlos auslasten.

Also was ich weiß wäre Gigabit ethernet schon pflicht für so eine verbindung.

Sicher das du im Lokalen netzwerk die vollen 12.5 MB/s zusammenbekommst?

[pepo83]

warum probierst du nicht mal direkt mit PC per lan kabel am modem, dann könntest den Router usw. mal auschließen.

[test0nger]

Klar hat man auf einem 100MBit/s-Ethernet-Interface auch Overhead -> auf jeden Fall mit Gigabit testen!

[fallenguru]

Für die Nachwelt:

Ich hab jetzt das Board vom Router getauscht, auf ein weit schnelleres mit 2 Gbit-Interfaces. Jetzt bekomme ich die volle Geschwindigkeit, zumindest, wenn Chello grad nicht spinnt. Es dürfte also tatsächlich an den 100-Mbit-Interfaces gelegen haben. Komisch, weil ich mit FTP, netpipe u. ä. (auf der LAN-Seite) auch mit dem alten Router viel näher ans theoretische Maximum gekommen bin, als mit dem Chello-Modem ... aber egal, Ende gut, alles gut.

Tuning-Tip:
net.core.rmem_max = 4194304 # 4MB
net.core.wmem_max = 4194304 # 4MB
Wenn das Maximum (dritte Zahl) bei net.ipv4.tcp_rmem bzw. tcp_wmem standardmäßig niedriger sein sollte, das auch noch abändern. Den ganzen Rest braucht man nicht angreifen, bringt nix.
Theoretisch sollte ein delay-basierter congestion avoidance alg. mit der teilweise doch etwas packet-loss-geplagten Chello-Infrastruktur besser zurecht kommen als ein klassischer. Momentan hab ich vegas im Probebetrieb und bin sehr zufrieden, aber da ich keine objektive Testmethode habe, ist das mit Vorsicht zu genießen.

[Rocky_Balboa]

Für die Nachwelt:

Ich hab jetzt das Board vom Router getauscht, auf ein weit schnelleres mit 2 Gbit-Interfaces. Jetzt bekomme ich die volle Geschwindigkeit, zumindest, wenn Chello grad nicht spinnt. Es dürfte also tatsächlich an den 100-Mbit-Interfaces gelegen haben. Komisch, weil ich mit FTP, netpipe u. ä. (auf der LAN-Seite) auch mit dem alten Router viel näher ans theoretische Maximum gekommen bin, als mit dem Chello-Modem ... aber egal, Ende gut, alles gut.

Tuning-Tip:
net.core.rmem_max = 4194304 # 4MB
net.core.wmem_max = 4194304 # 4MB
Wenn das Maximum (dritte Zahl) bei net.ipv4.tcp_rmem bzw. tcp_wmem standardmäßig niedriger sein sollte, das auch noch abändern. Den ganzen Rest braucht man nicht angreifen, bringt nix.
Theoretisch sollte ein delay-basierter congestion avoidance alg. mit der teilweise doch etwas packet-loss-geplagten Chello-Infrastruktur besser zurecht kommen als ein klassischer. Momentan hab ich vegas im Probebetrieb und bin sehr zufrieden, aber da ich keine objektive Testmethode habe, ist das mit Vorsicht zu genießen.

Ein Test ohne Tuning und mit Tuning wäre interessant, konnte keine großartigen Unterschiede feststellen, habe aber auch nur ein 35/4er Paket.

http://systembash.com/content/tweaking- ... -on-linux/

[fallenguru]

http://systembash.com/content/tweaking-tcp-for-fast-100mbps-connections-and-transfers-on-linux/

Also entweder das ist ein Scherz-Artikel oder er ist älter als die Polizei erlaubt. Ich kann mich nicht erinnern, daß Linux (2.4+) jemals Tuning für 100 Mb/s LANs gebraucht hätte, schon gar nicht für 80% Auslastung.
(net.ipv4.tcp_sack = 1 und net.ipv4.tcp_window_scaling = 1 sind seit längerem sowieso ein, Timestamps sollte man gerade bei einer WAN-Verbindung nicht ausschalten, die 12 byte, die da im Header frei werden, sind's nicht wert. net.core.?mem_default wirkt sich auf TCP-Verbindungen nicht aus, deshalb hab ich es bis jetzt in Ruhe gelassen.)

Pontential für Optimierung haben v. a. Hochgeschwindigkeits-LANs (1+ Gb/s, Latenz <1 ms) und High-End Breitband-Internetzugänge (100+ Mb/s, Latenz 10 ms oder auch viel mehr). Im zweiten Fall ist die Crux, daß Bandbreite und Latenz nicht "zusammenpassen". Speedguide.net an sich ist als Ausgangspunkt zum Einlesen ganz brauchbar.

Ein Test ohne Tuning und mit Tuning wäre interessant, konnte keine großartigen Unterschiede feststellen, habe aber auch nur ein 35/4er Paket.

In Tests, die mehrere Verbindungen aufmachen, wird man generell keine dramatischen Veränderungen sehen. Da werden ohne Optimierung zwar überflüssig ACKs verschickt, weil die Fenster zu klein sind, aber die verbleibende Bandbreite füllen die Verbindungen schon auf. Interessanter ist da der ftp.inode.at Speedtest, der pendelt "vorher" zwischen 7 und 9 MB/s, "nacher" recht stabil bei 11.5 MB/s.

Als ich noch 35/4 hatte, hab ich die Leitung auch so ausgelastet. Aber teste einmal andere congestion control algos, das könnte auch bei 35/4 was bringen, weniger, was die Bandbreite angeht, als Fairness (z. B. Online-Spiele neben Monster-Download).