Hallo,
natürlich muß man seinen pppd optimieren, wenn man in Dresden im 21. Jahrhundert lebt, Glasfaser im Keller und Modem im Flur hat.
Konkret:
Nach Einwahl beobachte ich, das die ping-Zeit bei den üblichen Updates / Downloads langsam auf 20 Sekunden steigt. Ziemlich genau dann wird vom Modem der Gegenstelle aufgelegt.
Hat jemand einen Tip, wie man per Trafficshaping / QOS etc. irgendwie hinbekommt, daß die übertragenen "Streams" etwas mehr gestückelt werden, so daß der icmp-traffic "durchkommen" kann.
Es scheint so, daß "dicke" Anfragen" auf der Gegenstelle gesammelt und dann in einem großen Block "durchgequetscht" werden sollen. Dabei geht die ping Zeit hoch und das wird dummerweise als Abbruch der Verbindung gewertet.
TIA!
Bernhard
Hallo Bernhard,
Bernhard Schiffner bernhard@schiffner-limbach.de (Mo 13 Apr 2009 20:29:52 CEST):
Hallo,
natürlich muß man seinen pppd optimieren, wenn man in Dresden im 21. Jahrhundert lebt, Glasfaser im Keller und Modem im Flur hat.
Konkret:
Nach Einwahl beobachte ich, das die ping-Zeit bei den üblichen Updates / Downloads langsam auf 20 Sekunden steigt. Ziemlich genau dann wird vom Modem der Gegenstelle aufgelegt.
Hat jemand einen Tip, wie man per Trafficshaping / QOS etc. irgendwie hinbekommt, daß die übertragenen "Streams" etwas mehr gestückelt werden, so daß der icmp-traffic "durchkommen" kann.
Da Du die Empfangseite shapen willst, ist das nicht wirklich einfach.
Es scheint so, daß "dicke" Anfragen" auf der Gegenstelle gesammelt und dann in einem großen Block "durchgequetscht" werden sollen. Dabei geht die ping Zeit hoch und das wird dummerweise als Abbruch der Verbindung gewertet.
Was hat Ping mit dem Verbindungsabbruch zu tun? Ich meine, ICMP-echo-{request,response} sollten doch kein Indikator für eine bestehende Verbindung sein, oder?
Guck mal nach "wondershaper", vielleicht hilft das für den Anfang.
On Monday 13 April 2009 21:10:14 Heiko Schlittermann wrote:
Hallo Bernhard,
Bernhard Schiffner bernhard@schiffner-limbach.de (Mo 13 Apr 2009 20:29:52 CEST):
Hallo,
natürlich muß man seinen pppd optimieren, wenn man in Dresden im 21. Jahrhundert lebt, Glasfaser im Keller und Modem im Flur hat.
Konkret:
Nach Einwahl beobachte ich, das die ping-Zeit bei den üblichen Updates / Downloads langsam auf 20 Sekunden steigt. Ziemlich genau dann wird vom Modem der Gegenstelle aufgelegt.
Hat jemand einen Tip, wie man per Trafficshaping / QOS etc. irgendwie hinbekommt, daß die übertragenen "Streams" etwas mehr gestückelt werden, so daß der icmp-traffic "durchkommen" kann.
Da Du die Empfangseite shapen willst, ist das nicht wirklich einfach.
man tc ... Ja.
Es scheint so, daß "dicke" Anfragen" auf der Gegenstelle gesammelt und dann in einem großen Block "durchgequetscht" werden sollen. Dabei geht die ping Zeit hoch und das wird dummerweise als Abbruch der Verbindung gewertet.
Was hat Ping mit dem Verbindungsabbruch zu tun? Ich meine, ICMP-echo-{request,response} sollten doch kein Indikator für eine bestehende Verbindung sein, oder?
Sollten. Setzen von lcp-echo-interval im pppd meinerseits hilft nicht. Die einzige Beobachtung meinerseits, ist es, daß ein (von mir losgetretener) Ping von >=20s praktisch nie zu sehen ist. Ich weiß nicht, wie die Gegenseite überwacht. ping ist da nur eine Idee. Vielleicht auch daß bestimmte Pakete dort mehr als 20 Sekunden "rumliegen" und nicht durchkommen. 1 Stream: ping 4-8s, 2 Streams: ping 4-12s, 3 Streams: ping 6-15s, kritisch 4 Streams: praktisch unmöglich. (DNS-Query timed out, ping an 20s, sehr häufiger Abbruch)
(Müßte ich mal monitoren, Faulheit hatte bis jetzt gesiegt ...)
Guck mal nach "wondershaper", vielleicht hilft das für den Anfang.
Gucke.
Danke Heiko für die Antwort.
Bernhard
On Monday 13 April 2009, Bernhard Schiffner wrote:
Setzen von lcp-echo-interval im pppd meinerseits hilft nicht. Die einzige Beobachtung meinerseits, ist es, daß ein (von mir losgetretener) Ping von >=20s praktisch nie zu sehen ist. Ich weiß nicht, wie die Gegenseite überwacht. ping ist da nur eine Idee. Vielleicht auch daß bestimmte Pakete dort mehr als 20 Sekunden "rumliegen" und nicht durchkommen. 1 Stream: ping 4-8s, 2 Streams: ping 4-12s, 3 Streams: ping 6-15s, kritisch 4 Streams: praktisch unmöglich. (DNS-Query timed out, ping an 20s, sehr häufiger Abbruch)
Sehr seltsam.
Welcher Provider und welcher DSL-Typ ist das?
Wohin pingst Du eigentlich?
Die DSL-Strecke sollte 30ms zur RTT von Ping hinzufügen (T-DSL via Kupfer, 1-6MBit/s, gute Leitung, keine Last).
www.heise.de ist bei mir ca. 52ms entfernt (ohne Last, mit Last max. das Doppelte)
www.six.heise.de (IPv6 und da liegt zusätzlich noch ein SIXXS-Knoten in Hamburg dazwischen) ist ca. 70ms entfernt.
Google.com: www - 66ms, ipv6 - 75ms
Was ist Deine konfigurierte MTU? Ich habe sie bei mir ganz konservativ auf 1412 - 1452 sollte aber fast immer funktionieren. Pakete, die nicht in die MTU passen werden nämlich einfach verworfen - was zu Verbindungsabbrüchen führt.
Zumindes T-Offline legt nach 5min auf, wenn kein Paket mehr durchgekommen ist. Scripte, die helfen gibt es auf Anfrage per PM. ;-)
Konrad
On Tuesday 14 April 2009 08:24:13 Konrad Rosenbaum wrote:
On Monday 13 April 2009, Bernhard Schiffner wrote:
Setzen von lcp-echo-interval im pppd meinerseits hilft nicht. Die einzige Beobachtung meinerseits, ist es, daß ein (von mir losgetretener) Ping von >=20s praktisch nie zu sehen ist. Ich weiß nicht, wie die Gegenseite überwacht. ping ist da nur eine Idee. Vielleicht auch daß bestimmte Pakete dort mehr als 20 Sekunden "rumliegen" und nicht durchkommen. 1 Stream: ping 4-8s, 2 Streams: ping 4-12s, 3 Streams: ping 6-15s, kritisch 4 Streams: praktisch unmöglich. (DNS-Query timed out, ping an 20s, sehr häufiger Abbruch)
Sehr seltsam.
Welcher Provider und welcher DSL-Typ ist das?
Arcor fair (Modem (max. 48 kBit/s))
Wohin pingst Du eigentlich?
z.B. ping -i8 www.suse.de
Die DSL-Strecke sollte 30ms zur RTT von Ping hinzufügen (T-DSL via Kupfer, 1-6MBit/s, gute Leitung, keine Last).
Nice to have :-) !me
Was ist Deine konfigurierte MTU? Ich habe sie bei mir ganz konservativ auf 1412 - 1452 sollte aber fast immer funktionieren. Pakete, die nicht in die MTU passen werden nämlich einfach verworfen - was zu Verbindungsabbrüchen führt.
Nichts geändert (1450?)
Zumindes T-Offline legt nach 5min auf, wenn kein Paket mehr durchgekommen ist. Scripte, die helfen gibt es auf Anfrage per PM. ;-)
Ist ja in gewissem Sinn auch Zweck meiner ping-Übung: "Traffic" für tote Zeiten zu haben. (Aber meistens ist ja "Betrieb".)
13 MByte je Stunde. Laß da mal jemand Fotos schicken... Manchmal ist schon nach 5 Minuten Verbindungsabbruch.
Konrad
Bernhard
On Tuesday 14 April 2009, Bernhard Schiffner wrote:
On Tuesday 14 April 2009 08:24:13 Konrad Rosenbaum wrote:
Welcher Provider und welcher DSL-Typ ist das?
Arcor fair (Modem (max. 48 kBit/s))
Ahh, Uralt-Technik. Jetzt verstehe ich. Da schimmeln schon die Transistoren in der Vermittlungsstelle. Aus irgendeinem Grund hatte ich jetzt angenommen, dass Du endlich mal eine Internetverbindung hast, die sich "Verbindung" nennen darf... #-/
http://en.wikipedia.org/wiki/Modem#Using_digital_lines_and_PCM_.28V.90.2F92....
Das Modem kann sich selbst stören - wenn viel Traffic in der einen Richtung unterwegs ist, wird der Traffic in der anderen Richtung gestört (Echo, Übersprechen, ...) und damit kann es passieren dass wichtige Keep-Alive-Packets nicht rechtzeitig ankommen oder Pakete einfach verloren gehen.
Wohin pingst Du eigentlich?
z.B. ping -i8 www.suse.de
55ms bei mir.
Die DSL-Strecke sollte 30ms zur RTT von Ping hinzufügen (T-DSL via Kupfer, 1-6MBit/s, gute Leitung, keine Last).
Nice to have :-) !me
Naja, ein Analog-Telefon-Modem braucht halt etwas länger zum kodieren... :-(
4000ms ist allerdings auch dafür etwas viel.
Was ist Deine konfigurierte MTU? Ich habe sie bei mir ganz konservativ auf 1412 - 1452 sollte aber fast immer funktionieren. Pakete, die nicht in die MTU passen werden nämlich einfach verworfen - was zu Verbindungsabbrüchen führt.
Nichts geändert (1450?)
Default bei PPP over Telephone ist glaube ich 296bytes. Sollte irgendwo im Log auftauchen. Allzu groß sollte man es nicht wählen, da die Fehlerkorrektur bei Analog-Modem nicht sehr zuverlässig ist.
Konrad
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Heiko Schlittermann -
Konrad Rosenbaum