- Anzeige -

Optimale Einstellungen für D-Link DIR-300

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Wichtig:
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon 7Layers » 13.02.2011, 13:33

Die TCP-Kontrollnachrichten erzeugt der Client (auf den downstream bezogen), und er kann sie erst dann erzeugen, wenn die Situation eingetreten ist, die zu der Kontrollnachricht führt. Er kann nur einen Frame gleichzeitig auf den Draht legen, der entweder ein Payload-Paket (für die upstream-Last) oder ein Kontrollpaket (für den downstream) enthält. Ich sehe nicht, wo es dort zu messbaren Einflüssen auf den Durchsatz beim Download kommt.
7Layers
Kabelneuling
 
Beiträge: 37
Registriert: 08.01.2011, 08:48
Wohnort: Frankfurt/Main

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon piotr » 13.02.2011, 13:54

Untersuche doch mal wie sich verlorene -d.h. nicht rechtzeitig empfangene- TCP Bestaetigungspakete auf den Download auswirken. D.h. wenn der Upstream durch andere Anwendungen bereits ausgeschoepft wird und dadurch TCP Bestaetigungspakete erst spaeter eintreffen koennen als erwartet.

Einmal im original TCP und dann mit den einzelnen TCP-Erweiterungen (Slow-Start, Fast Retransmit, selective TCP ACK und ECN).
piotr
Glasfaserstrecke
 
Beiträge: 2209
Registriert: 13.08.2008, 18:26

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon oxygen » 13.02.2011, 14:28

Slow-Start eine TCP-Erweiterung? Sei besser vorsichtig mit solchen Posts wenn du nicht weißt wovon du sprichst.

Telekom Entertain IP VDSL50 mit IPv6/IPv4-Dual-Stack Router: Netgear DGNB3800B
Früher: Unitymedia
oxygen
Glasfaserstrecke
 
Beiträge: 1321
Registriert: 30.09.2009, 16:53

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon piotr » 13.02.2011, 15:16

oxygen hat geschrieben:Slow-Start eine TCP-Erweiterung? Sei besser vorsichtig mit solchen Posts wenn du nicht weißt wovon du sprichst.


Richtig, Slow-Start ist schon lange im TCP drin (genauer: seit RFC 1122, 1989).
Es war im urspruenglichen TCP aber nicht drin (RFC 761, 1980).
Zuletzt geändert von piotr am 13.02.2011, 16:12, insgesamt 2-mal geändert.
piotr
Glasfaserstrecke
 
Beiträge: 2209
Registriert: 13.08.2008, 18:26

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon 7Layers » 13.02.2011, 15:20

piotr hat geschrieben:Untersuche doch mal wie sich verlorene -d.h. nicht rechtzeitig empfangene- TCP Bestaetigungspakete auf den Download auswirken. D.h. wenn der Upstream durch andere Anwendungen bereits ausgeschoepft wird und dadurch TCP Bestaetigungspakete erst spaeter eintreffen koennen als erwartet.


RTT ist typischerweise im zweistelligen Millisekunden-Bereich, wenn das keinen Einfluss auf die Download-Rate hat, warum sollte dann die kleinere Verzögerung im Router einen haben? Das erscheint mir nicht schlüssig. Gedropte Pakete ist etwas anderes, aber TCP erlaubt es den Protokollen, bandbreitenadaptiv zu arbeiten, so dass eben keine Pakete gedropt werden müssen. Wie schon gesagt, warum sollte der Client das Senden einer TCP-Kontrollnachricht verzögern? Und während er die Kontrollnachricht schickt, kann er keine Upload-Daten schicken, weil es geht nur eins, also ist auch der timeslot vorhanden. Ich sehe hier keinen Unterschied im Durchsatz, egal, ob ich nebenher einen ftp-Upload mache oder nicht.
7Layers
Kabelneuling
 
Beiträge: 37
Registriert: 08.01.2011, 08:48
Wohnort: Frankfurt/Main

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon piotr » 13.02.2011, 16:00

Der Client verzoegert dann das Senden der TCP Acks, wenn der Sende-Buffer, der vor dem "auf den Draht gehen" kommt, bereits sehr gut gefuellt ist.

Hast Du selbst beschrieben.. es geht nur eins gleichzeitig auf den Draht.;)

Teste es doch mal, indem Du Deinen Upstream mit anderen Anwendungen auslastet und lade dann mal mit HTTP oder FTP (jeweils ohne Downloadmanager, ohne TrafficShaping und auch ohne andere QoS-Mechanismen) etwas herunter.

Je nachdem welches OS Du nutzt, wirst Du Unterschiede mehr oder weniger gut sehen.

Bei aelteren Systemen wie z.B. beim noch von Microsoft unterstuetzten XP kann es hier zum beschriebenen Verhalten mit der Herabsetzung der Downloadrate des HTTP/FTP kommen, weil XP in der Werkseinstellung (nachtraeglich aenderbar) die TCP RWIN Groesse nicht hoch genug (=passende TCP window scaling Werte fuer heute ueblichen Leitungsgeschwindigkeiten unter Beruecksichtigung typischer RTT-Werte) setzen kann.

Beim bei wenigen Usern noch eingesetzten Win98 siehst Du es noch besser, weil dort auch die Moeglichkeit der Selective TCP Ack fehlen.
Zuletzt geändert von piotr am 13.02.2011, 18:27, insgesamt 1-mal geändert.
piotr
Glasfaserstrecke
 
Beiträge: 2209
Registriert: 13.08.2008, 18:26

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon 7Layers » 13.02.2011, 18:27

Hab' ich doch geschrieben, dass beim Test kein Unterschied rauskommt, egal ob ein Upload läuft oder nicht. Ich habe mehr Schwankung von Messung zu Messung als mit oder ohne parallelen Upload.

Statistisch gesehen wird vom upload-Prozess zu 49/50 der Zeit nichts gesendet, das gleiche Verhältnis müsste dann auch für eine Kollision der Prozesse beim Schreiben in den Puffer gelten, weil die Bandbreite im LAN 50 mal größer ist, als die im WAN (in meinem Fall).

Darüber hinaus kommen alle Kontrollnachrichten, selbst wenn sie immer hinten an die Warteschlange angehängt werden, mit dem gleichen Abstand voneinander, nur eben insgesamt verzögert, so dass maximal nur die ersten Kontrollnachrichten "zu spät" (tcpRtoMin ist per default 1000 ms) beim Sender einträfen. Danach läuft alles wie gehabt. Die aktuelle RTT wird meines Wissens dynamisch bestimmt, also ist aus Sicht des Servers kein Unterschied zu sehen, wenn der Abstand der Kontrollnachrichten stimmt.
7Layers
Kabelneuling
 
Beiträge: 37
Registriert: 08.01.2011, 08:48
Wohnort: Frankfurt/Main

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon piotr » 13.02.2011, 22:53

Teste es mal mit einem schmalbandigen Upstream, z.B. mit ADSL 2000 (US idR 192 kbit/s) oder ADSL light (US idR 64 kbit/s).

Wenn Du schon tcprtomin in den Raum wirfst...
Erklaere den Wert mal und zwar bezogen auf den bei Deiner verwendeten TCP-Implementation genutzten Algorithmus fuer die Berechnung des Retransmission Timeout (RTO).
Es gibt bzw. gab da nicht nur 1 Moeglichkeit.
piotr
Glasfaserstrecke
 
Beiträge: 2209
Registriert: 13.08.2008, 18:26

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon 7Layers » 14.02.2011, 00:37

Die Bandbreite macht m. E. keinen Unterschied, weil die Verzögerung konstant ist, was sich dann so auswirkt, als wäre die Verbindung lediglich ein paar tausend Kilometer länger. Ob ein Paket in einer queue wartet oder einen längeren Weg zu laufen hat, ist für den Server nicht zu unterscheiden. Nach Deiner Argumentation hätte ich bei einem Download von Auckland grundsätzlich einen schlechteren Durchsatz als von Berlin, was so nicht zutrifft. Welcher Algorithmus für die RTO-Berechung zur Anwendung kommt, ist im Grunde genommen egal. Worauf ich eigentlich hinaus wollte, ist, dass eine Sekunde eine vergleichsweise lange Zeit ist, im Verhältnis zur Verzögerung, die tatsächlich erfolgt. Selbst wenn eine Kontrollnachricht gedropt würde, würde das spätere ACK kumulativ wirken und die vorhergehende Sequenz mit bestätigen. Auch das bekräftigt mich in meiner Ansicht, dass die RTT den Durchsatz nicht beeinflusst (im Rahmen der Bandbreite), nicht beeinflussen darf.
7Layers
Kabelneuling
 
Beiträge: 37
Registriert: 08.01.2011, 08:48
Wohnort: Frankfurt/Main

Re: Optimale Einstellungen für D-Link DIR-300

Beitragvon piotr » 14.02.2011, 04:05

7Layers hat geschrieben:Auch das bekräftigt mich in meiner Ansicht, dass die RTT den Durchsatz nicht beeinflusst (im Rahmen der Bandbreite), nicht beeinflussen darf.


Dann lies mal das bandwidth delay product und das tcp scaling window (RFC 1323) nach.

Das TCP scaling window ist nicht auf jedem Betriebssystem aktiviert.

Prominentes Bsp: Ein frisch installiertes Windows XP.
Dort ist es frisch nach einer Installation nicht aktiviert, d.h. Du hast dann max 65535 Byte fuer das TCP receive window.
piotr
Glasfaserstrecke
 
Beiträge: 2209
Registriert: 13.08.2008, 18:26

VorherigeNächste

Zurück zu Internet und Telefon über das TV-Kabelnetz

Wer ist online?

Mitglieder in diesem Forum: Yahoo [Bot] und 27 Gäste