Unitymedia Optimale Einstellungen für D-Link DIR-300

[franky1964]

Hallo ,hatte auch probleme mit meinen NAS und Dyndns. Erst als ich statt ner .org Adresse ne ATH.CX genommen habe ging alles ohne Probleme.
Vielleicht liegt es ja auch daran.
Hast schon mal versucht Direkt von Ausen Peer IP adresse zu Connecten? Sprich Ftp://Internet-ip:21/ so komm ich auch Ohne probleme an meine daten.
wenn du so Darufkommst ,kannst ja mal deine ftp:// Dyndns adresse gefolgt vom Port eingeben ,dann siehst ja ob die user/ PW abfrage kommt.
wichtig ist halt das du den NAS ne feste Ip vergeben hast( Im Adressbereich des D-links zb: Dlink 192.168.100.2 dann das NAS laufwerk 192.168.100.X ) und den port 21 an die Ip weiterleitest.
Franky1964

 

[Glenn]

"Vergisst" der DIR-300 manchmal die Nameserver, die ihm der ISP auf der WAN-Seite zugeteilt hat? Vornehmlich nachts?

Ich hatte es jetzt in den letzten Monaten drei oder vier mal, dass mein Browser plötzlich meldet, dass er die angeforderte Seite nicht darstellen kann. Ein beherztes "DHCP erneuern" im Status-Fenster des DIR-300 brachte jedesmal Abhilfe.

Nun hatte ich es letzte Nacht wieder und habe mal etwas genauer hingesehen. Eine Windows-Commandline mit "nslookup google.de" konnte nicht beantwortet werden. Ein Ping auf irgendeine externe IP hat jedoch noch funktioniert und auch ein Download, der vor dem "Ausfall" der Verbindung zur Namensauflösung eingeleitet wurde, lief problemlos zu Ende - bestehende Connections snid also nicht betroffen, "nur" neue Anfragen an den Nameserver können nicht mehr aufgelöst werden.

Das "DHCP erneuern" ändert rein gar nichts an der WAN-IP oder dem verwendeten Nameserver - nur, dass es danach mit der Namensauflösung wieder klappt.

Normalerweise schlafe ich nachts. Nur, wenn mich mein Weib aus dem Bett wirft, weil ich (angeblich) so laut schnarche, kann es vielleicht einmal im Monat vorkommen, dass ich nochmal kurz den PC einschalte - und dann gab's eben jedesmal nach kurzer Zeit (10 Min gesurft) den Fehler in der Verbindung.

Ist das Problem bekannt?

Danke und Grüße.

 

[koax]

@Glenn

Welche Firmwareversion hast Du im Router?

 

[ulli1961]

Hallo an die unitygemeinde hier,
vieleicht könnt ihr mir ja helfen???
bin nun auch stolzer besitzer einer 3play 32ooo leitung mit ném dir 300 router.
dieser router bringt mich noch ins grab :wut: .
unity techniker sagt mir "einfach alles verbinden und los gehts"
weit gefehlt es geht sogut wie nichts :wand: .
habe auch versucht über die obengenannte optimale einstellung es einzustellen (soweit ich das alles vestanden habe als richtiger laie)aber das ging auch nicht.
ständig brach die verbindung ab obwohl der sender nur 10 m von dem empfänger,getrennt durch 2 Wände,entfernt war.
habe bereits 3 Sticks ( HAMA / Fritz/Levelone )ausbrobiert und ich bekomme maximal 3000 kb.
mit nem kabel bekomme ich laut speedtest 29000kb.
hatte schon gedacht das es an den USB Port (USB 1) von meinem alten PC liegt.
PC hat das betriebsysrem XP Proffesional und servicepack 3 drauf.
habe soweit auch Router / Stick richtig installiert.
nun weis ich nicht mehr weiter da ich wirklich ein laie in dieser richtung bin.
kann mir vieleicht einer von euch sagen wie ich den router und pc richtig einstellen muss das ich ordentlich ins inet kann.
vielen dank schon mal im vorraus.

 

[Grothesk]

Nicht komplett gelesen. Hat deine Tastatur keine Großbuchstaben?

 

[ulli1961]

Hi,
doch,MEINE TASTATUR HAT GROSSBUCHSTABEN.
bin aber zu faul diese zu benutzen.

 

[Grothesk]

Trifft sich gut. Ich bin nämlich immer zu faul auf solche Fragen zu antworten.

 

[G00fY]

Mal ein Statement zu diesen Thread. Die optimale Einstellung gibt es nicht! Daher ist das alles mit Vorsicht zu genießen. Ich hab meinen Router zB ganz anders (und für mich optimal konfiguriert :zwinker: ).

Ich nutze den Dir 300 ausschließlich im Lan und daher hab ich das WLAN deaktiviert QoS und RTSP halte ich für sehr nützlich usw. Wie du siehst ganz andere Einstellungen.

 

[Grothesk]

Korrekt.
Der Thread wendet sich ja auch primär an die WLAN-Fummler die möglichst viel Bandbreite rausfummeln wollen. Und für die ist QoS eine Bremse.

 

[G00fY]

Ist vielleicht für Leute mit etwas Wissen schnell ersichtlich, jedoch solltest du das vielleicht dazu schreiben. :zwinker:

 

[lienot1]

Hi, nochwas altes zu QoS:

Ich erinnere mich noch an die gute alte XP Zeit, da hies es auch immer man soll QoS im Betriebssystem ausschalten, weil es Bandbreite "festhalten" würde.
Bis dann alle gesagt haben "Bullshit, es ändert nichts an der Bandbreite..."
Ob es hier in diesem Fall auch so ist weiß ich nicht, aber 2000 bei XP war es aufjedenfall ein ganz anderes Problem...
Es ging sich darum, wenn man erst im WWW unterwegs ist, dann gleichzeitig mails zieht, dann gleichzeitig Realplayer benutzt nicht der WWW Zugang alle Resourcen für sich vereinnahmt und der realplayer keine chance hat zu streamen, also es ging sich ums gerechte aufteilen von Bandbreite im eigenen System.

Hier nochmal der Text von Microsoft:
Erläuternde Hinweise zu QoS bei Windows XP-Computern
Wie in Windows 2000 erfolgt die Nutzung von QoS in Windows XP auch über die QoS-API (Application Programming Interface). Hundert Prozent der Netzwerkbandbreite stehen für die gemeinsame Nutzung durch alle Programme zur Verfügung, sofern kein Programm explizit eine höhere Bandbreitenpriorität anfordert. Diese "reservierte" Bandbreite ist weiterhin für andere Programme verfügbar, wenn das anfragende Programm nicht gleichzeitig Daten sendet. Standardmäßig können Programme bis zu 20 Prozent der Bandbreite der verwendeten Verbindungsgeschwindigkeit auf jeder Schnittstelle eines Endgeräts reservieren. Wird die reservierte Bandbreite nicht durch das Programm ausgeschöpft, so steht der nicht benutzte Teil der reservierten Bandbreite für andere Datenströme auf demselben Host zur Verfügung.

Weitere Informationen zum QoS-Paketplaner finden Sie in der Hilfe von Windows XP. Zusätzliche Informationen zu QoS unter Windows 2000 finden Sie auf den technischen Informationsseiten zu Windows 2000.

Viele Grüße

lienot

 

[7Layers]

Na ja, in Anbetracht der Tatsache, dass Ciscos Beschreibung von QoS hundert Seiten locker und deutlich übersteigt, sind die drei Seiten "detaillierte" Aleitung von (z.B.) D-Links "automatischem QoS" wenig Vertrauen erweckend. Dann wohl lieber ausschalten. Dazu kommt, dass QoS nur beim Upload wirksam werden kann. Beim Download dagegen liegen die Frames schon fast komplett auf dem Draht, wenn das erste Bit in den Router einläuft. Da kann nicht einer rausgekickt werden und die anderen rücken in Nullzeit nach, denn die Bitzeit steht ebenfalls fest.

 

[piotr]

Deine Beschreibung, dass es bei Downloads nicht wirkt, hat nur einen entscheidenden Haken ...

TCP-basierte Downloadmoeglichkeiten wie z.B. HTTP oder FTP

Denn dann wirkt QoS auch, weil die bei TCP notwendigen Bestaetigungspakete (TCP ACK) ueber den Upstream an die Quelladresse zurueckgesendet werden. Auch die Beschleunigung/Verzoegerung der Bestaetigungspakete hat Auswirkungen auf die Downloadgeschwindigkeit.

 

[7Layers]

Ja, Upload ist missverständlich, ich hätte wohl besser auch "upstream" geschrieben.
Warum und um wieviel ändert sich die d/l-Rate bei voll ausgelasteter upstream-Verbindung?
Und ändert das QoS von D-Link etwas daran?

 

[piotr]

Schau Dir mal die TCP-Mechanismen an, v.a. Flowcontrol/Slidingwindow.

Wieviel das ausmacht, kann man nicht pauschal sagen.

Es haengt in jeden Einzelfall von diesen Faktoren ab:
- wie schnell beide Seiten angebunden sind
- wie die Latenz zwischen beiden Seiten ist
- welche TCP RWIN Groessen eingesetzt werden koennen
- ob TCP-Erweiterungen wie z.B. selective TCP ACK oder ECN genutzt werden koennen
etc.

Keine Ahnung, ob D-Links QoS daran etwas aendert.

 

[7Layers]

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.

 

[piotr]

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).

 

[oxygen]

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

 

[piotr]

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).

 

[7Layers]

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.

 

[piotr]

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.

 

[7Layers]

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.

 

[piotr]

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.

 

[7Layers]

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.

 

[piotr]

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.