xDSL.at

Hallo,

da der Inode Support dieses Problem nicht lösen konnte bzw. wollte (es scheiterte schon beim Lesen der Problembeschreibung) versuche ich es mal hier.

Ich habe seit kurzem Inode ADSL 2048/384, erreiche aber nie die volle Bandbreite. Auffällig sind auch die spürbaren Lags (alle paar Sekunden) bei HTTP/FTP/SMTP usw. Übertragung.

Ich habe das Alcatel 546 und betreibe es im Multiuser Modus. Der neu aufgesetzte WindowsXP Client ist direkt an das Modem angeschlossen, nicht etwa über einen DSL Router.

Das Problem:

Die MTU wird vom Modem (PPPoA) mit 1500 angezeigt. Die Fragmentierungsgrenze liegt bei 1472 Byte Payload.
Bei Pings auf ping.inode.at mit einer Paketgrösse von 1460 Byte, sieht man das Problem:

C:\Documents and Settings\user>ping -n 20 -l 1460 -f ping.inode.at

Pinging ping.inode.at [195.58.160.103] with 1460 bytes of data:

Reply from 195.58.160.103: bytes=1460 time=179ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=58ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=60ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=280ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=58ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=60ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=62ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=58ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=58ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=125ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=329ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=58ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61
Reply from 195.58.160.103: bytes=1460 time=59ms TTL=61

Ping statistics for 195.58.160.103:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 58ms, Maximum = 329ms, Average = 92ms

C:\Documents and Settings\user>

Wenn ich das ganze mit MTR vom Linux Laptop aus mache, sieht man folgendes:

Host Loss% Snt Last Avg Best Wrst StDev
1. 10.0.0.138 0.0% 58 58.9 49.4 1.7 101.5 26.2
2. mac3-fe-00-000.shuttle.vien.inod 5.2% 58 49.7 62.0 47.4 213.3 39.3
3. bord-vl-00-501.shuttle.vien.inod 5.2% 58 48.7 57.9 47.7 230.4 36.6
4. viec-gb-05-004.shuttle.vien.inod 1.7% 58 70.2 54.8 47.5 150.9 16.0
5. ping.inode.at 0.0% 57 55.9 56.9 55.8 58.5 0.6

10.0.0.138 ist das Alcatel Modem, von dem der Support vermutet, es wäre ein DSL-Router zwischen PC und Modem.

Die Lags treten nur bei Paketen mit grösserer Payload auf. Das Problemverhalten ist mit normalen PING bzw. TRACEROUTE nicht reproduzierbar. Ab 1000 Byte Paketgrösse kann man den Paketverlust beobachten, die Lags treten schon bei kleineren Werten auf (500 byte).

Praktisch wirkt sich das so aus, dass die Up/Downloads dauernd zwischen 20k/Sec und 160k/Sec pendeln. Manchmal gibt es sogar Verbindungsabbrüche.

Vom Support (ich will ja keine Namen nennen) bin ich schwerst enttäuscht.
Erst versteht der Mitarbeiter die Problembeschreibung nicht (man merkts an den ignoranten Standardantworten ala "schickens uns an Ping und an Tracert Screenshot" und "Leider konnten wir keine Probleme bei uns feststellen") und jetzt krieg ich überhaupt kein reply vom Support mehr

Wenn ihr auch Inode-ADSL User seid, dann probiert doch mal das Ping Kommando von oben. Ich würde gerne wissen, ob ich der einzige mit dem Problem bin oder nicht.

Und gebt euren (konstruktiven) Senf dazu!

Greetz,
makro

Also, was soll ich eurer Meinung nach tun?

erstens: was genau siehst du als problem? die verbindung funktioniert ja.

zweitens steht die loesung schon ein paarmal im forum. st546 auf multi-user umstellen.

btw: ping kann man in jeder beliebigen groesse versenden. jfyi.

Hi Jutta.

MANN!!!!

LESEN!!!

Das Modem wurde schon auf MU umgestellt.

Greetz,
makro

opps, hab ich in dem langen posting uebersehen. dann gibts hier im forum keine schnelle loesung. dass groessere pakete laenger dauern, ist uebrigens keine sensation.

wie sieht ein speedtest aus? (mit ftp)

ich hab ein bissl schneller gepingt - im ergebenis aehnlich wie bei dir:

chili1:/home/jutta# ping -s 1460 -c 1000 -f ping.inode.at
PING ping.inode.at (195.58.160.103) 1460(1488) bytes of data.

--- ping.inode.at ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 50305ms
rtt min/avg/max/mdev = 48.153/63.634/160.460/13.765 ms, pipe 5, ipg/ewma 50.356/62.901 ms
chili1:/home/jutta#

ich hab dabei aber null problem mit meiner leitung und meinen anwendungen. (ohne -f waere die streuung vermutliche geringer)

Sorry wegen dem Pöbeln
Bin schon etwas übersensibel was das Überlesen von Informationen betrifft.

Speedtest von/zu ftp.inode.at bringt rund 1540/280 KBit/Sec.
Bei externen Netzen (Chello) komme ich konstant auf nur 1330 KBit/Sec.

Ein grosses Problem sind die Verbindungsabbrüche bei grossen Files über XDCC. Da geht die effektive Bandbreite (stark schwankend) bis auf 0 Byte/s und dann isser weg, der Download

Greetz,
makro

ich geb zu, dass ich "pingproblem" und "lag" (auch im zusammenhang mit dem st546) hier schon so oft gelesen habe, dass ich automatisch antworte - ebenfalls sorry

xdcc kenne ich leider nicht - kann man da ev einen anderen timeout einstellen?

xdcc ist ansich ein sehr fragiles medium, da die beteiligten Clients oft instabil sind und ganz gern mal den einen oder anderen Socket fallen lassen. Das muss nicht zwingend was mit der Leitung/dem Provider zu tun haben.

Leider nein.

XDCC ist im Prinzip "FTP-over-IRC" also sowas wie FServe, das Vorgängerprotokoll. XDCC Wird exklusiv im Internet Relay Chat zum Übetragen von Dateien verwendet.

Wenn ich ein Mail schicke gleicht die Bewegung des Fortschrittbalkens im Thunderbird einer Wellenbewegung, bleibt auch öfter ein paar Sekunden lang stehen (Wegen dem PacketLoss nehme ich an).

Mir sieht das eher nach überlasteten Routernbzw. Over-Selling aus, ich kenne das Phänomen vom Chello Netzwerk von vor ca. drei Jahren. Da gings allerdings schon bei kleineren Payloads mit Paketverlust los...

Greetz,
makro

@medice: Ich hatte bis vor einem Monat noch XDSL@home (an einem anderen Wohnort) und da gabs NULL Probleme mit XDCC bzw. Packetloss oder Lagging.
Die Down/Upstream Raten waren bei XDSL sowas von konstant. Fast wie im LAN.

Greetz,
makro

packet loss kann ich bei deinen ping auszügen aber keinen entdecken...

probleme ab paketgröße 1000 wären übrigens extrem untypisch, kein medium hat irgendeine grenze bei so einer paketgröße...

Den Packetloss siehst du beim Output von MTR im ersten Posting.
Bei diesem Beispiel hält sich der Loss eh noch in Grenzen (unter 10%), das ist aber selten der Fall.
Wenn ich google.at mit 1440 Bytes pinge, bekomme ich sogar hier jedes zehnte bis zwanzigste Paket nicht zurück (innerhalb vom timeout).

Ich finde die Problematik mit "grossen" Payloads (man denke an ATM) auch alles andere als typisch. Das hab ich in meinen fast zehn Jahren Netzwerkadministration noch nie gesehen. Naja, ausser vor 2-3 Jahren bei Chello, die wohl bei den Routern gespart, jedoch massiv over-selling betrieben haben.

Gottseidank hat sich gerade jemand anders als bisher vom Inode Support gemeldet, evtl. kann ich bei diesem Menschen mehr Kompetenz erwarten als beim Vorgänger, den ich seit gestern liebevoll "Copyn'Paste" nenne.

Greetz,
makro

also ich seh nur

Lost = 0 (0% loss)

im 1. Post

falls du aber das hier meinst

2. mac3-fe-00-000.shuttle.vien.inod 5.2% 58 49.7 62.0 47.4 213.3 39.3
3. bord-vl-00-501.shuttle.vien.inod 5.2% 58 48.7 57.9 47.7 230.4 36.6
4. viec-gb-05-004.shuttle.vien.inod 1.7% 58 70.2 54.8 47.5 150.9 16.0

manche Geräte - weiß nciht welche Exemplare da stehen - behandeln so "ICMP-Spielereien" mit allerniedrigster Priorität. nachdem 1 und 5 ohne Loss sind, würd ich das Ergebnis nicht für bare Münze nehmen.

Hi Medice,

das ist nicht immer so.
Ich hab einen Screenshot hier rumliegen, da verlieren ALLE Router UND ping.inode.at Pakete.

Gerade wenn man einen Rechner ping.domain.tld nennt, dürfte man ICMP keineswegs beschränken. ICMP wird von den Providern eh schon so abgedreht, dass man fast keine Diagnosemöglichkeiten bei Verbindungsproblemen hat (Telekom).

Auch interessant:

Die Lags kann man sehr gut mit apt-get (Ubuntu Breezer) beobachten.
Da bleibt der Download von Paketen alle paar Sekunden einfach stehen.

Ich denke bei solcherart Verhalten gibt es keine Ausrede mehr bezgl. Fehler oder Nicht-Fehler, oder doch?

Greetz,
makro

Sodala, hab die letzten beiden Tage einige Pings gestartet:

Hier mal die Route:

R1 speedtouch.lan [10.0.0.138]
R2 mac3-fe-00-000.shuttle.vien.inode.at [213.229.45.251]
R3 bord-vl-00-501.shuttle.vien.inode.at [213.229.45.249]
R4 viec-gb-05-004.shuttle.vien.inode.at [62.99.171.45]
R5 ping.inode.at [195.58.160.103]

Wenn ich alle Hops separat Pinge krieg ich:

R1: <1ms
R2: 15 bis 400 ms (schwankt)
R3: 15 bis 300 ms (schwankt)
R4: 14 bis 20ms
R5: 14 bis 18ms

Pinge ich gleichzeitig den R2 und einen beliebigen Server im Internet, dann verzögern sich die Antwortpakete in beiden Fenstern gleichzeitig:



Also das sagt mir als Netzwerkadmin eindeutig, dass die beiden Router (R2 und R3) oder die Leitung dazwischen Probleme bereiten.
Nur der 1st-Level Support kapiert das nach der zehnten Email immer noch nicht. (Oder sollte ich besser Low-Level-Support sagen?)

Naja, ich komm am Mittwoch eh in Graz vorbei, um mein altes XDSL Modem abzugeben, die 100 Euro Kaution zu kassieren und mit jemanden aus dem technischen Management zu sprechen um ihn über das Ärgernis 1stLevel-Inkompetenz aufzuklären.
Ich hab das bei Chello schon mal gemacht und hoppala - Prompt die Telefonnummer vom 2nd Level Support bekommen. ("Das nächste Mal rufens als erstes DORT an, bitte") Seit damals war ich auch mit Chello zufrieden, da ich mich ab da nicht mehr mit den 1st-lern herumärgern musste.
Bin dann mal gespannt, ob Inode da auch so unkompliziert ist....

Greetz,
makro