Hi, habe seit kurzem T-DSL und die 1&1 Flatrate. suse 7.3 und smpppd. Die pure Einwahl über dod dauert hier ca. 15 Sekunden. Kommt noch die Firewall hinzu, kann man weitere 5 Sekunden hinzurechnen. Kann bei der Flatrate natürlich den hangup timeout beliebig hochsetzten, und wenn ich erst mal "drin" bin, gibt's keine Probleme. Aber anders wär's mir eigentlich lieber. Ist so eine lange Einwahlzeit normal, bzw. kann ich da was dran ändern, wenn ich mit einem anderen Paket reingehe? Ansonsten scheint das dod auch nicht immer so richtig zu klappen. Offenbar werden gelegentlich Pakete versschluckt, so daß zwar eine Verbingung aufgebaut wird, aber erst ein erneuter Browser-Request fruchtet. An der Firewall scheint das allerdings nicht zu liegen, und eine Regelmäßigkeit konnte ich bisher noch nicht entdecken. Bin für jegliche Tips/Erfahrungsberichte dankbar. -- viele Gruesse Rolf
Hallo, at Wednesday 31.10.2001 (01:46 +0100), Rolf Hillen wrote:
habe seit kurzem T-DSL und die 1&1 Flatrate.
Ich habe die rosa DSL-Flat.
suse 7.3 und smpppd.
Redhat 7.0, dürfte aber keinen unterschied machen.
Die pure Einwahl über dod dauert hier ca. 15 Sekunden.
Die dauert bei mir, auch dod, ca. 5 sek.
Kommt noch die Firewall hinzu, kann man weitere 5 Sekunden hinzurechnen.
Die braucht bei mir auch ca. 5 sek. Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
Rolf Hillen wrote:
habe seit kurzem T-DSL und die 1&1 Flatrate. suse 7.3 und smpppd. Die pure Einwahl über dod dauert hier ca. 15 Sekunden.
Die lange Einwahlzeit ist ein bekanntes Problem. Wurde in einer der letzen ct's mal erörtert. Liegt nicht an Deiner persönlichen Konfiguration. - Matthias
Matthias Kleine schrieb:
suse 7.3 und smpppd. Die pure Einwahl über dod dauert hier ca. 15 Sekunden.
Die lange Einwahlzeit ist ein bekanntes Problem. Wurde in einer der letzen ct's mal erörtert. Liegt nicht an Deiner persönlichen Konfiguration. Habe mir den Artikel aus der c't 20/2001 nochmals zu Gemüte geführt. Da konnte ich aber nix finden. Sorry für die Frage: Du verwechselst das jetzt nicht mit den Ping-Zeiten?
-- viele Gruesse Rolf Hillen GPG/PGP-key 55BEEFD0
Rolf Hillen wrote:
Habe mir den Artikel aus der c't 20/2001 nochmals zu Gemüte geführt. Da konnte ich aber nix finden. Sorry für die Frage: Du verwechselst das jetzt nicht mit den Ping-Zeiten?
Nein, das ist die Latenzzeit, nicht die Einwahlzeit. In benannter ct war auch von Einwahlzeiten die Rede. Wenn ich zu Hause bin schau ich nachher nochmal nach.. - Matthias
Am Mittwoch, 31. Oktober 2001 17:51 schrieb Matthias Kleine:
Rolf Hillen wrote:
Habe mir den Artikel aus der c't 20/2001 nochmals zu Gemüte geführt. Da konnte ich aber nix finden. Sorry für die Frage: Du verwechselst das jetzt nicht mit den Ping-Zeiten?
Nein, das ist die Latenzzeit, nicht die Einwahlzeit. In benannter ct war auch von Einwahlzeiten die Rede. Wenn ich zu Hause bin schau ich nachher nochmal nach..
Ok, das hier beschriebene Problem betrifft offenbar nur Windows-Clients auf spezieller Hardware. Durch eine Vertauschung der Optionen während der PPP-Aushandlung dauert hier der Verbindungsaufbau besonders lange. Bis zu 10 Sekunden sind jedoch auch hier bei mir keine Seltenheit. Manchmal geht es auch in 2-3 Sekunden, aber der Verbindungsaufbau dauert in jedem Fall länger als bei ISDN. - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Matthias Kleine wrote:
Ok, das hier beschriebene Problem betrifft offenbar nur Windows-Clients auf spezieller Hardware. Durch eine Vertauschung der Optionen während der PPP-Aushandlung dauert hier der Verbindungsaufbau besonders lange.
Bis zu 10 Sekunden sind jedoch auch hier bei mir keine Seltenheit. Manchmal geht es auch in 2-3 Sekunden, aber der Verbindungsaufbau dauert in jedem Fall länger als bei ISDN.
Danke für das nochmalige Nachschauen. Also 2 bis 3 Sekunden hab' ich noch nie gehabt. Muß das nochmal genauer beobachten. -- viele Gruesse Rolf Hillen GPG/PGP-key 55BEEFD0
* Mittwoch, 31. Oktober 2001 um 01:46 (+0100) schrieb Rolf Hillen:
habe seit kurzem T-DSL und die 1&1 Flatrate. suse 7.3 und smpppd. Die pure Einwahl über dod dauert hier ca. 15 Sekunden. [ ... ] Ist so eine lange Einwahlzeit normal,
Wie definierst du "Einwahlzeit"? Die Zeit zwischen Verbindungsanforderung und Verbindungsaufbauende (Zuweisung der dyn. IP und der NS) beträgt im optimalen Fall ca. 1 s. Allerdings gibt es zwei Einschränkungen: 1.) Der AC stammt von Siemens: Wegen einer fehlerhaften PPP-Implementierung dauert der Verbindungsaufbau typisch ca. 6 s. Angeblich wird an einer Lösung gearbeitet. 2.) Der Radius-Server antwortet nicht sofort und verzögert den Verbindungsaufbau entsprechend.
bzw. kann ich da was dran ändern, wenn ich mit einem anderen Paket reingehe?
Unwahrscheinlich, da alle PPPoE-Pakete den Verbindungsaufbau dem pppd
überlassen. Und falls es doch Unterschiede gibt, dann war vermutlich
der pppd nicht richtig konfiguriert.
Welche Ursache den Verbindungsaufbau bei dir verzögert, lässt sich am
besten durch Setzen der "debug"-Option des pppd erkennen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke wrote:
habe seit kurzem T-DSL und die 1&1 Flatrate. suse 7.3 und smpppd. Die pure Einwahl über dod dauert hier ca. 15 Sekunden. [ ... ] Ist so eine lange Einwahlzeit normal, ....... bzw. kann ich da was dran ändern, wenn ich mit einem anderen Paket reingehe?
Unwahrscheinlich, da alle PPPoE-Pakete den Verbindungsaufbau dem pppd überlassen. Und falls es doch Unterschiede gibt, dann war vermutlich der pppd nicht richtig konfiguriert.
Welche Ursache den Verbindungsaufbau bei dir verzögert, lässt sich am besten durch Setzen der "debug"-Option des pppd erkennen. Danke für die Hinweise. Meinte mit Verbindungsaufbau die Zeit, bis ip-up gestartet wird. Habe mir eben mal die betreffenden Stellen in den logs der letzten 24 Stunden angesehen, und es scheint, als ob es besser geworden ist.
So grob geschätzt liegen 80% bei 6 bis 7 Sekunden, 10 Prozent bei (ich
wollte es kaum glauben) 3 Sekunden, und 10 Prozent bei 15 Sekunden. 1x
waren 20 Sekunden dabei. (Früher hatte ich immer(?) beobachtet, daß es
erst nach dem 5ten pap-Ahthentifizierungsversuch in Reihe geklappt hat.
Kam mir zwar komisch vor, aber mangels Erfahrung....)
Dann habe ich mal die Meldungen eines 7 Sekunden-logs mit denen eines
3ers verglichen (s.u.). Macht es noch Sinn, das mit der debug-option
anzusehen, oder ist die etwa schon angeschaltet?
Offenbar wird das PPP-Protokoll mit der Gegenseite (ist das der
Radius-Server?) unterschiedlich schnell/störungsfrei abgehandelt. Liegt
das vielleicht daran, wie stark der gerade ausgelastet ist?
Nov 2 00:51:09 wiesel pppd[6762]: Starting link
Nov 2 00:51:09 wiesel pppd[6762]: Sending PADI
Nov 2 00:51:09 wiesel pppd[6762]: HOST_UNIQ successful match
Nov 2 00:51:09 wiesel pppd[6762]: HOST_UNIQ successful match
Nov 2 00:51:09 wiesel pppd[6762]: Got connection: 117e
Nov 2 00:51:09 wiesel pppd[6762]: Connecting PPPoE socket:
00:90:1a:10:0f:fb 7e11 eth1 0xxxxxxxx
Nov 2 00:51:09 wiesel pppd[6762]: using channel 3
Nov 2 00:51:09 wiesel pppd[6762]: Connect: ppp0 <--> eth1
Nov 2 00:51:09 wiesel pppd[6762]: Couldn't increase MTU to 1500.
Nov 2 00:51:09 wiesel pppd[6762]: Couldn't increase MRU to 1500
Nov 2 00:51:09 wiesel pppd[6762]: sent [LCP ConfReq id=0x1
* Freitag, 02. November 2001 um 02:30 (+0100) schrieb Rolf Hillen:
So grob geschätzt liegen 80% bei 6 bis 7 Sekunden,
Das ist typisch für "deinen" Siemens-AC.
10 Prozent bei (ich wollte es kaum glauben) 3 Sekunden,
Hm, das ist schon ungewöhnlich schnell für einen Siemens-AC. Ich weiss nicht, warum sich "dein" Siemens-AC meist "normal" und manchmal besser aufführt, aber das fehlerhafte PPP-Verhalten der ACs ist bekannt und die Telekom arbeitet seit einem knappen Jahr daran. Vielleicht haben sie in "deinen" AC eine Firmware-Version eingespielt, die sich immerhin bei 20% der Verbindungen besser verhält. Trotzdem seltsam...
und 10 Prozent bei 15 Sekunden. 1x waren 20 Sekunden dabei. (Früher hatte ich immer(?) beobachtet, daß es erst nach dem 5ten pap-Ahthentifizierungsversuch in Reihe geklappt hat. Kam mir zwar komisch vor, aber mangels Erfahrung....)
Das liegt an den angesprochenen "gut ausgelasteten" Radius-Servern. AFAIR wird an denen z.Zt. bundesweit gearbeitet, so dass sich das im Laufe der Zeit bessern sollte (Ja, ich bin ein Optimist ;-) ).
Macht es noch Sinn, das mit der debug-option anzusehen, oder ist die etwa schon angeschaltet?
Ja, die debug-Option ist eingeschaltet.
Offenbar wird das PPP-Protokoll mit der Gegenseite (ist das der Radius-Server?)
Nein, der PPP-Partner ist der AC. Der Radius-Server verwaltet Benutzerkennung, Passwort und dyn. IP und wird vom AC "befragt".
unterschiedlich schnell/störungsfrei abgehandelt. Liegt das vielleicht daran, wie stark der gerade ausgelastet ist?
Die PAP-Authentifizierung ja, der Rest der PPP-Verhandlungen IMHO nein.
[ "6s-Log"]
Typisches "Siemens-Log" mit 2 Pausen je 3s, einem TermAck-"Bäuerchen"
im Verbindungsaufbau und doppelter Aushandlung der Remote-IP...
[ "3s-Log"]
Untypisches "Siemens-Log" mit nur noch einer Pause, ohne
TermAck-"Bäuerchen" und ordentlicher Aushandlung der Remote-IP.
Vielleicht schaffen Telekom und Siemens es ja bald, die eine Pause
auch noch zu eleminieren...
Gruß
Andreas, der glücklich ist, an einem Cisco-AC "zu hängen".
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke schrieb:
Die PAP-Authentifizierung ja, der Rest der PPP-Verhandlungen IMHO nein.
[ "6s-Log"]
Typisches "Siemens-Log" mit 2 Pausen je 3s, einem TermAck-"Bäuerchen" im Verbindungsaufbau und doppelter Aushandlung der Remote-IP...
[ "3s-Log"]
Untypisches "Siemens-Log" mit nur noch einer Pause, ohne TermAck-"Bäuerchen" und ordentlicher Aushandlung der Remote-IP. Vielleicht schaffen Telekom und Siemens es ja bald, die eine Pause auch noch zu eleminieren... Na da bin ich mal gespannt. Nochmals Danke - damit wäre die Sache wohl geklärt. Werde das mal im Auge behalten.
Wollte das insbesondere auch genauer wissen, weil ich demnächst ein DSL-Router bei einem Kunden (irgendwie muß ich mein Studium finanzieren) aufstellen muß. Und bisher haben mir zwei Leute gesagt, z.B. dieser ADSL-Router von Elsa würde das schneller machen - die Verbindung wäre quasi direkt da. Linux wäre mir aber aus verschiedenen Gründen lieber. Aber bis auf den Regelaufbau der Firewall dürfte es doch eigentlich keinen Unterschied geben!? -- viele Gruesse Rolf Hillen GPG/PGP-key 55BEEFD0
* Freitag, 02. November 2001 um 16:43 (+0100) schrieb Rolf Hillen:
Und bisher haben mir zwei Leute gesagt, z.B. dieser ADSL-Router von Elsa würde das schneller machen - die Verbindung wäre quasi direkt da. Linux wäre mir aber aus verschiedenen Gründen lieber. Aber bis auf den Regelaufbau der Firewall dürfte es doch eigentlich keinen Unterschied geben!?
Ja, das würde ich auch sagen...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (5)
-
Andreas Koenecke
-
Matthias Kleine
-
Matthias Kleine
-
Michael Raab
-
Rolf Hillen