KabelBW sooo laaannngssaaamm

[Alexander Burger]

KabelBW ist oft unerträglich langsam.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?

Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.
Das sind fast schon Modem-Geschwindigkeiten.
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.

KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben. So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
nicht alle Provider haben.

[Marc Haber]

Post by Alexander Burger
KabelBW ist oft unerträglich langsam.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?

Ich habe einen KabelBW Businessanschluß. Die erreichte Datenrate ist
ungefähr das einzige, an dem ich nichts auszusetzen habe.

Den (zugenagelten) Router muss man so etwa einmal in der Woche
resetten, wenn Latenzen in der Größenordnung von 2 Sekunden auftreten.
Es gibt nur IPv4, kein IPv6, und der Service ist unterirdisch
mieserabel.

Gäbe es eine Alternative, die an meinem Standort mehr als 1 Mbit
Upstream liefern kann, hätte ich spätestens nach dem unangekündigten
Werksreset des Routers, der mit Verlust sämtlicher lokaler
Konfiguration einher ging, längst gekündigt.

Post by Alexander Burger
Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.
Das sind fast schon Modem-Geschwindigkeiten.
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.

Ich könnte mir vorstellen, dass dies aufgrund der technischen
Realisierung von Kabel-Internet regional extrem unterschiedlich sein
kann. Hier[tm] ist die Performance jedenfalls in Ordnung.

Grüße
Marc

[Jörg Tewes]

Marc Haber schrub

Post by Marc Haber
Den (zugenagelten) Router muss man so etwa einmal in der Woche
resetten, wenn Latenzen in der Größenordnung von 2 Sekunden
auftreten.

Zu einer Domain die in D gehostet wird, oder außerhalb?

Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
welcher Firmware?

Wenn du eine Fritzbox 6360 hast, und es innerhalb von D ist, siehst du
mich massiv erstaunt.

Ich dachte die Fritzboxen werden bei den Kabelbetreibern größtenteils
gleich konfiguriert, und meine 6360 mit 6.05 braucht nicht resettet zu
werden, um die Latenz wieder in normale Größenordnungen zu bringen.
Meine 6360 läuft jetzt seit Anfang des Jahres durchgehen, und hat zu
heise.de unter 30ms, was ich mit dem Entertainanschluß auch bei der
Telekom hatte. Mit einem Telekom Businessanschluß könntest du da auf
weniger kommen, aber alle Privatkundenanschlüsse kommen auf ähnliche
Werte. Zumindest das was aktuell geschaltet wird.


Bye Jörg

[Marc Haber]

Post by Jörg Tewes
Marc Haber schrub

Post by Marc Haber
Den (zugenagelten) Router muss man so etwa einmal in der Woche
resetten, wenn Latenzen in der Größenordnung von 2 Sekunden
auftreten.

Zu einer Domain die in D gehostet wird, oder außerhalb?

Zu einer Domain hat man keine Latenzen.

Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
Fritzbox auf. Wenn ich mich richtig erinnere, lässt sich die Fritzbox
noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
nicht mehr aufgetreten.

Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
in den USA aber mit überdimensional hoher Latenz, dann ist der Fehler
im allgemeinen nicht im CPE zu suchen.

Post by Jörg Tewes
Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
welcher Firmware?

FRITZ!Box 6360 Cable (kbw), fritz-6360-kbw FRITZ!OS 06.04

Grüße
Marc

[Jörg Tewes]

Marc Haber schrub

Post by Marc Haber

Post by Jörg Tewes
Marc Haber schrub

Post by Marc Haber
Den (zugenagelten) Router muss man so etwa einmal in der Woche
resetten, wenn Latenzen in der Größenordnung von 2 Sekunden auftreten.

Zu einer Domain die in D gehostet wird, oder außerhalb?

Zu einer Domain hat man keine Latenzen.

Naja dann eben zum Zeil. :-)

Post by Marc Haber
Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
Fritzbox auf.

Schon klar. Ich meinte halt ob es bei dir z.B. zu heise.de auftritt,
oder zu asus.com

Post by Marc Haber
Wenn ich mich richtig erinnere, lässt sich die Fritzbox
noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
nicht mehr aufgetreten.

Wenn sich die Fritzbox noch normal anpingen läßt, kann es doch kaum an
ihr liegen, warum also einen Reset? Wäre für mich unlogisch. Oder bin
ich da irgendwie auf dem Holzweg?

Post by Marc Haber
Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
in den USA aber mit überdimensional hoher Latenz, dann ist der Fehler
im allgemeinen nicht im CPE zu suchen.

Das dachte ich mir auch. Aber warum dann resetten?

Post by Marc Haber

Post by Jörg Tewes
Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
welcher Firmware?

FRITZ!Box 6360 Cable (kbw), fritz-6360-kbw FRITZ!OS 06.04

Hier genau dieselbe. Keinerlei Probleme, seit über 2 Jahren. Hmmm.


Bye Jörg

[Marc Haber]

Post by Jörg Tewes
Marc Haber schrub

Post by Marc Haber
Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
Fritzbox auf.

Schon klar. Ich meinte halt ob es bei dir z.B. zu heise.de auftritt,
oder zu asus.com

Egal wohin.

Post by Jörg Tewes

Post by Marc Haber
Wenn ich mich richtig erinnere, lässt sich die Fritzbox
noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
nicht mehr aufgetreten.

Wenn sich die Fritzbox noch normal anpingen läßt, kann es doch kaum an
ihr liegen, warum also einen Reset? Wäre für mich unlogisch. Oder bin
ich da irgendwie auf dem Holzweg?

Ich könnte mir vorstellen, dass da irgendwas auf der Kabelseite "aus
dem Sync" geraten ist, das muss den Prozessor der Fritzbox selbst
nicht notwendigerweise betreffen.

Post by Jörg Tewes

Post by Marc Haber
Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
in den USA aber mit überdimensional hoher Latenz, dann ist der Fehler
im allgemeinen nicht im CPE zu suchen.

Das dachte ich mir auch. Aber warum dann resetten?

Weil hohe Latenz überall hin durchaus am CPE liegen kann.

Grüße
Marc

[Ulrich F. Heidenreich]

Post by Alexander Burger
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.

CU!
Ulrich

[Sven Hartge]

Post by Ulrich F. Heidenreich

KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.

Du hast im Kabel ja nicht nur ausschließlich 50MBit für alle.

Pro _Kanal_ sind da bei EuroDOCSIS-2.0/3.0 50MBit möglich, und es gibt
mehr wie einen Kanal für Daten im Kabel.
<http://en.wikipedia.org/wiki/DOCSIS>

Bei EuroDOCSIS-3.0 werden Kanal auch gebündelt, um die höheren
Datenraten über 50MBit zu erreichen.

Eigentlich sollte das CMTS die Modems auf einen anderen Kanal schieben,
wenn einer voll sein sollte, aber nicht immer haben die Provider das so
eingestellt.

Was Alexander helfen könnte, wäre einmal sein
Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
der Hoffnung auf einen anderen Kanal zugewiesen zu werden.

Falls der direkte Netzanschluss und nicht der Backbone das Problem ist.

S

[Alexander Burger]

Post by Sven Hartge

Post by Ulrich F. Heidenreich

KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.

Du hast im Kabel ja nicht nur ausschließlich 50MBit für alle.
Pro _Kanal_ sind da bei EuroDOCSIS-2.0/3.0 50MBit möglich, und es gibt
mehr wie einen Kanal für Daten im Kabel.
<http://en.wikipedia.org/wiki/DOCSIS>
Bei EuroDOCSIS-3.0 werden Kanal auch gebündelt, um die höheren
Datenraten über 50MBit zu erreichen.
Eigentlich sollte das CMTS die Modems auf einen anderen Kanal schieben,
wenn einer voll sein sollte, aber nicht immer haben die Provider das so
eingestellt.
Was Alexander helfen könnte, wäre einmal sein
Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
der Hoffnung auf einen anderen Kanal zugewiesen zu werden.
Falls der direkte Netzanschluss und nicht der Backbone das Problem ist.
S

ok, vielen Dank. Beim nächsten Stau im Kabel werde ich mal versuchen, mein
Modem und Router zu resetten. Vielleicht hilft das ja wirklich.
Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
Internet-backbones angeschlossen wird, oder?
Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
ausgelegt sein.
Das fände ich aber sehr ärgerlich, weil KabelBW mit Bandbreiten von 50
Mbit/s und 100 Mbit/s und 150 Mbit/s Werbung macht. Was nützt es dann, wenn
man zwar direkt am Haus diesen Netzanschluss hat, die backbones aber einen
solchen Traffic nicht hergeben?
Klar schauen immer mehr Leute video über das Internet. Ich selbst habe auch
eine set-top-box für den Fernseher, mit der ich über den Fernseher ins
Internet gehen kann. In den Mediatheken von ARD, arte usw. liegen ja sehr
viele Filme herum, die man anschauen kann. Was ich bislang wenig tue. Aber
ich kann mir schon vorstellen, dass viele Leute gerade am samstagabend so
das Internet belagern.

Gruß
Alex

[Sven Hartge]

Post by Alexander Burger

Post by Sven Hartge
Was Alexander helfen könnte, wäre einmal sein
Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
der Hoffnung auf einen anderen Kanal zugewiesen zu werden.

ok, vielen Dank. Beim nächsten Stau im Kabel werde ich mal versuchen, mein
Modem und Router zu resetten. Vielleicht hilft das ja wirklich.
Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.

Möglich. Aber von aussen schwer zu erkennen.

Post by Alexander Burger
Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
Internet-backbones angeschlossen wird, oder?

Das hängt auch wieder vom Provider ab.

Manche peeren mit anderen Providern nur an einer Stelle (z.B. dem DECIX
in Frankfurt), andere wiederum haben recht viele Peering-Punkte.

Post by Alexander Burger
Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
ausgelegt sein.

Auch möglich.

Die (werbewirksame) mögliche Bandbreite an den Endanschlüssen ist
schneller und stärker gewachsen wie die Bandbreite im Backbone.

Post by Alexander Burger
Das fände ich aber sehr ärgerlich, weil KabelBW mit Bandbreiten von 50
Mbit/s und 100 Mbit/s und 150 Mbit/s Werbung macht. Was nützt es dann, wenn
man zwar direkt am Haus diesen Netzanschluss hat, die backbones aber einen
solchen Traffic nicht hergeben?

Tja. Willkommen in der Wirklichkeit,

Teste doch einfach mal folgendes:

Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
um festzustellen, wie es mit der Strecke im Ziel aussieht:

z.B.:

tracert www.heise.de

Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.

Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.

S°

[Alexander Burger]

Post by Sven Hartge
Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
tracert www.heise.de
Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.

ah, danke. dass ich da nicht früher darauf gekommen bin.
ich habe zwar Linux, aber da geht das dann mit traceroute:


/usr/sbin/traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms
7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *


das sieht ziemlich übel aus, oder?
Der ping selbst liegt unter 30 ms.
Hat aber 53prozent paketverlust :-(

ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=244 time=14.7 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=244 time=14.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=244 time=14.6 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=6 ttl=244 time=17.9 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=7 ttl=244 time=15.2 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=12 ttl=244 time=12.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=13 ttl=244 time=15.3 ms
(...)
64 bytes from www.heise.de (193.99.144.85): icmp_seq=203 ttl=244 time=13.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=204 ttl=244 time=14.3
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=207 ttl=244 time=24.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=210 ttl=244 time=18.2
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=211 ttl=244 time=14.6
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=213 ttl=244 time=15.8
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=214 ttl=244 time=16.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=219 ttl=244 time=16.7
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=221 ttl=244 time=11.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=222 ttl=244 time=17.6
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=223 ttl=244 time=14.4
ms
^C
--- www.heise.de ping statistics ---
223 packets transmitted, 103 received, 53% packet loss, time 222139ms
rtt min/avg/max/mdev = 11.193/16.756/100.554/8.968 ms

kann man daraus etwas ablesen?

Gruß
Alex

[Sven Hartge]

Post by Alexander Burger

Post by Sven Hartge
Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
tracert www.heise.de
Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.

ah, danke. dass ich da nicht früher darauf gekommen bin.

Wenn du Linux hast, dann nimm mal mtr (Paket mtr-tiny in Debian z.B.)

Post by Alexander Burger
das sieht ziemlich übel aus, oder?

Nein, du hast nur eine kaputte Implementierung von traceroute erwischt.
Es gibt z.B. in Debian diverse Pakete, die traceroute bereitstellen.
Versuche mal inetutils-traceroute.

Ich persönlich mag mtr lieber, weil man es z.B. dauerhaft laufen lassen
kann oder mit

mtr -r 100 heise.de

einen Report über 100 Zyklen anzeigen lassen kann, welcher
Aufschlussreicher ist wie nur einen Momentaufnahme.

Sieht bei mir z.B. so aus:

***@ds9:~$ mtr -4 -r 100 heise.de
Start: Sun Sep 7 19:02:35 2014
HOST: ds9 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.40.64.1 0.0% 10 7.7 7.7 6.4 9.2 0.6
2.|-- 7211a-mx960-01-ae10-1020. 0.0% 10 7.0 10.1 5.6 34.4 8.7
3.|-- 7211a-mx960-02-ae0.gie.un 0.0% 10 6.4 11.6 6.1 37.7 10.0
4.|-- 1211f-mx960-01-ae5.dtm.un 0.0% 10 10.8 12.7 8.3 38.6 9.1
5.|-- 1411g-mx960-01-ae8.nss.un 0.0% 10 10.6 12.0 10.4 15.8 1.5
6.|-- gi1-15.c1.d.de.plusline.n 0.0% 10 12.4 12.2 11.2 13.8 0.7
7.|-- 212.19.61.13 0.0% 10 15.7 12.6 11.2 15.7 1.4
8.|-- redirector.heise.de 0.0% 10 11.4 11.9 10.6 12.5 0.3

(Das -4 bewirkt die Nutzung von IPv4.)

S°

[Juergen Ilse]

Hallo,

Post by Alexander Burger
ah, danke. dass ich da nicht früher darauf gekommen bin.
/usr/sbin/traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *

Bis hierhin anscheinend nur Hops mit ICMP-Paketfiltern und/oder so
konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
Aussage machen (solange man das droüüen von ICMP nicht bereits als
"mangelnde Qualitaet des Netzes" wertet).

Post by Alexander Burger
6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms

Ob hier das gedropte Paket auf ein wirkliches Problem hinweist, ist
IMHO nicht wirklich klar. Dass hier die 2 beantworteten Pakete an
verschiedene Router gingen, muss kein Problem sein. Die Antwortzeiten
weisen hier auch noch nicht unbedingt auf ein Problem hin, auch wenn
der Unterschied (13,8 zu 30.5 ms) etwas auffaellig ist.

Post by Alexander Burger
7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *

Hier koennten die Paketverluste auch durch aggresives ICMP-Rate-Limiting
hervorgerufen worden sein. Die Paketverluste *koennten* ein Indiz fuer
ein Problem sein, das muss aber nicht der Fall sein. Hohe Antwortzeiten
waeren da schon eher ein Indiz ... 21 ms sind aber fuer die Verbindung
nach Frankfurt (vermutlich zum DE-CIX, wenn ich mir den Rest der Ausgabe
ansehe) nicht so schlecht).

Post by Alexander Burger
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *

Hier wieder droppen von ICMP (siehe oben), eine Aussage darueber, ob ein
Netzwerkproblem vorliegt, ist aufgrund dessen nicht moeglich.

Post by Alexander Burger
23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *

Das duerfte eine IP-Adresse des Loadbalancers von Heise zu sein,
die Paketverluste duerften auf ICMP-Rate-Limiting und abweisen
des traceroutes beruhen. Da die Antwortzeiten bis zum 8.Hop nicht
sonderlich hoch waren und der Heise-Server im Netz von Plusline
steht, duerften hier die etwas hoeheren Antwortzeiten kein Indiz
fuer ein Problem im Netz deines Providers sein.

Post by Alexander Burger
das sieht ziemlich übel aus, oder?

Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
deines Providers treffen.

Post by Alexander Burger
Der ping selbst liegt unter 30 ms.
Hat aber 53prozent paketverlust :-(

Die mehr als 50% Paketverluste beim ping auf www.heise.de sind schon
eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
(den anderen Informationen im Thread nach zu schliessen) bei deinem
Provider, evt. auch auf der "last mile".

[ ping-Ausgabe gesnippt ]

Post by Alexander Burger
kann man daraus etwas ablesen?

Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
fahrung mit "Internet ueber TV-Kabel".

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Sven Hartge]

Post by Juergen Ilse
Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ...

Dito. Die Kombi "geringe Latenz, hohe Verluste" deuten meist auf ein
ICMP-Rate-Limit hin, meiner Erfahrung nach. (OK, einmal hatte ich einen
defekten SFP, der ca. 10% der Pakete zerstörte, so dass der empfangene
Switch sie wegwarf. Das äußerte sich an TCP-Verbindungen mit
Modem-Geschwindigkeit und eben 10% Paket-Verlust beim ICMP.)

Überlastete Leitungen zeigen sich meist zuerst durch eine hohe Latenz
und _dann_ erst durch verlorene Pakete.

In meinem anderen Artikelt sagte ich ja schon, dass er einmal andere
Tools benutzen soll, weil ich die von ihm gepostete Ausgabe von einer
mistigen Implementierung von traceroute schon kenne.

Post by Juergen Ilse
Allerdings habe ich keinerlei Er- fahrung mit "Internet ueber
TV-Kabel".

Eigentlich ist Internet via Kabel was Latenz und Paket-Verlust angeht
DSL überlegen.

Wenn der Anbieter den Coax-Strang bis zum Kabelverzweiger nicht
gnadenlos überbucht.

S°

[Alexander Burger]

Post by Sven Hartge

Post by Juergen Ilse
Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ...

Dito. Die Kombi "geringe Latenz, hohe Verluste" deuten meist auf ein
ICMP-Rate-Limit hin, meiner Erfahrung nach. (OK, einmal hatte ich einen
defekten SFP, der ca. 10% der Pakete zerstörte, so dass der empfangene
Switch sie wegwarf. Das äußerte sich an TCP-Verbindungen mit
Modem-Geschwindigkeit und eben 10% Paket-Verlust beim ICMP.)
Überlastete Leitungen zeigen sich meist zuerst durch eine hohe Latenz
und _dann_ erst durch verlorene Pakete.
In meinem anderen Artikelt sagte ich ja schon, dass er einmal andere
Tools benutzen soll, weil ich die von ihm gepostete Ausgabe von einer
mistigen Implementierung von traceroute schon kenne.

Post by Juergen Ilse
Allerdings habe ich keinerlei Er- fahrung mit "Internet ueber
TV-Kabel".

Eigentlich ist Internet via Kabel was Latenz und Paket-Verlust angeht
DSL überlegen.
Wenn der Anbieter den Coax-Strang bis zum Kabelverzweiger nicht
gnadenlos überbucht.
S°

vielen Dank.
ok, hier habe ich mal noch ein Beispiel mit mtr:

/usr/sbin/mtr --report -c 100 hetzner.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5 4.2
4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4 3.9
5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2 3.9
6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7 4.4
7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5 4.4
8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9 13.0
12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6 10.2
13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5 13.1
14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7 3.9
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3



Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%

ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.

Gruß
Alex

[Rupert Haselbeck]

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 hetzner.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst
8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
[...]
Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%

Der Router dort ist vermutlich gut ausgelastet und wirft daher ICMP-Pakete
einfach weg, statt sie zu beantworten. Das sagt also nichts aus

Post by Alexander Burger
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.

Dann solltest du aber besser UDP verwenden statt ICMP

MfG
Rupert

[Sven Hartge]

Post by Rupert Haselbeck

Post by Alexander Burger
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.

Dann solltest du aber besser UDP verwenden statt ICMP

Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
ICMP-basierten.

Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.

S°

[Rupert Haselbeck]

Post by Sven Hartge
Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
ICMP-basierten.

Die Lücken in der Hop-Liste sind doch nicht von Interesse, solange der
jeweils darauffolgende Hop keine Paketverluste zetgt

Post by Sven Hartge
Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.

Das ist natürlich richtig. Aber damit ist man ja immerhin schonmal an die
Grenzen des Zielsystems gekommen und das mit Paketen, welche unterwegs als
Nutzlast behandelt werden

MfG
Rupert

[Sven Hartge]

Post by Rupert Haselbeck

Post by Sven Hartge
Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.

Das ist natürlich richtig. Aber damit ist man ja immerhin schonmal an
die Grenzen des Zielsystems gekommen und das mit Paketen, welche
unterwegs als Nutzlast behandelt werden

Ich würde eher ein TCP-basiertes traceroute auf dem intendierten
Zielport machen, z.B. mit tcptraceroute oder "mtr -T -P 80"

S°

[Marc Haber]

Post by Rupert Haselbeck

Post by Sven Hartge
Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
ICMP-basierten.

Die Lücken in der Hop-Liste sind doch nicht von Interesse, solange der
jeweils darauffolgende Hop keine Paketverluste zetgt

Es verwirrt Leute, die sich nicht auskennen, und erhöht die Dauer des
Traces.

Grüße
Marc

[Heiko Schlichting]

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 hetzner.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5 4.2
4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4 3.9
5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2 3.9
6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7 4.4
7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5 4.4
8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9 13.0
12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6 10.2
13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5 13.1
14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7 3.9
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%

Das sieht alles richtig und völlig normal aus. Zum Ziel (www.hetzner.de)
hast Du weder Paketverluste noch unübliche Laufzeiten --> alles ist in
Ordnung.

Dass es auf dem Weg dorthin Router gibt, die besseres zu tun haben, als
Deine traceroute-Pakete zu beantworten, ist nicht ungewöhnlich und kein
Fehler. Wenn es Paketverluste aufgrund von Engpäßen gäbe, dann hätten auch
*alle* folgenden Hops Verluste, insb. auch das Ziel.

Da in diesem Fall offenbar alles richtig ist, kann man daraus nicht
ablesen, wo die Ursache sein kann. Zum Zeitpunkt der Messung wirst Du auch
selbst festgestellt haben, dass es (zu www.hetzner.de) gar kein Problem
gab. Du musst also die Messung nochmal wiederholen, wenn es Probleme gibt
(Dein ping mit hohen Verlusten war sicherlich ein solcher Zeitpunkt) und
das Ergebnis hier posten.

Dass es am Backbone Deines Providers liegt, kann ich zwar auch nicht ganz
ausschließen, aber in mindestens 9 von 10 Fällen, wo das jemand als Ursache
behauptet hat, stellte es sich als falsch heraus. Das liegt daran, dass die
Erweiterung von Bandbreite im eigenen Backbone für einen Provider eher
kostengünstig¹ ist, er die Auslastung leicht messen sowie überwachen kann
und dort oft die besten Techniker einer Firma das Sagen haben, die sich bei
Paketverlusten im Backbone auf Lebenszeit Gespött anhören müssen.

Heiko

¹ verglichen mit Erweiterungen an anderen Stellen der Infrastruktur

[Heiko Schlichting]

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 hetzner.de

Die Paketverluste hattest Du zu www.heise.de, hier testest Du mit
hetzner.de, wo alles ok ist. Wie sieht es denn zu www.heise.de aus (am
besten zu einem Zeitpunkt, wo ping auch Verluste hat)?

Ohne Probleme (von Kabel Deutschland) sieht das so aus:

[***@ech] 121 (~): mtr -w -c 100 www.heise.de
HOST: ech Loss% Snt Last Avg Best Wrst StDev
1.|-- DD-WRT 0.0% 100 0.6 0.7 0.6 1.0 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 83-169-180-62-isp.superkabel.de 0.0% 100 7.7 9.2 7.0 30.4 3.2
4.|-- ip5886c154.dynamic.kabel-deutschland.de 0.0% 100 9.4 10.1 8.0 23.8 2.5
5.|-- ip5886cb0a.dynamic.kabel-deutschland.de 0.0% 100 10.0 11.3 8.4 26.0 2.3
6.|-- ip5886ca47.dynamic.kabel-deutschland.de 0.0% 100 15.2 15.4 13.8 30.9 2.2
7.|-- plusline.ber.ecix.net 0.0% 100 14.5 23.2 13.8 181.0 27.5
8.|-- 212.19.61.13 0.0% 100 22.2 24.2 21.1 77.8 7.3
9.|-- www.heise.de 0.0% 100 21.3 23.7 21.2 61.5 4.9

Heiko

[Marc Haber]

Post by Heiko Schlichting

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 hetzner.de

Die Paketverluste hattest Du zu www.heise.de, hier testest Du mit
hetzner.de, wo alles ok ist. Wie sieht es denn zu www.heise.de aus (am
besten zu einem Zeitpunkt, wo ping auch Verluste hat)?
HOST: ech Loss% Snt Last Avg Best Wrst StDev
1.|-- DD-WRT 0.0% 100 0.6 0.7 0.6 1.0 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 83-169-180-62-isp.superkabel.de 0.0% 100 7.7 9.2 7.0 30.4 3.2
4.|-- ip5886c154.dynamic.kabel-deutschland.de 0.0% 100 9.4 10.1 8.0 23.8 2.5
5.|-- ip5886cb0a.dynamic.kabel-deutschland.de 0.0% 100 10.0 11.3 8.4 26.0 2.3
6.|-- ip5886ca47.dynamic.kabel-deutschland.de 0.0% 100 15.2 15.4 13.8 30.9 2.2
7.|-- plusline.ber.ecix.net 0.0% 100 14.5 23.2 13.8 181.0 27.5
8.|-- 212.19.61.13 0.0% 100 22.2 24.2 21.1 77.8 7.3
9.|-- www.heise.de 0.0% 100 21.3 23.7 21.2 61.5 4.9

Und so von KabelBW (Business 50 mbit, unter der Woche tagsüber
gemessen):

|[1/501]***@fan:~$ mtr -4 -w -c 100 www.heise.de
|Start: Tue Sep 9 11:01:12 2014
|HOST: fan Loss% Snt Last Avg Best Wrst StDev
| 1.|-- 192.168.251.254 0.0% 100 0.6 0.4 0.3 1.2 0.0
| 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
| 3.|-- 172.30.22.101 0.0% 100 9.1 12.5 9.1 29.4 3.9
| 4.|-- 84.116.190.81 0.0% 100 13.3 15.5 10.3 69.8 7.8
| 5.|-- 84.116.190.6 0.0% 100 14.6 15.9 12.2 29.1 2.8
| 6.|-- te0-0-2-3.c350.f.de.plusline.net 0.0% 100 14.5 17.6 13.4 45.7 4.6
| 7.|-- 82.98.102.5 0.0% 100 16.7 19.6 14.8 71.3 7.3
| 8.|-- 212.19.61.13 0.0% 100 14.6 17.4 13.0 45.4 5.3
| 9.|-- www.heise.de 0.0% 100 16.8 18.3 14.9 31.5 3.5

Ja, für Reverse DNS scheinen sich sowohl KabelBW, Plusline als auch
Heise zu fein zu sein in diesen Tagen.

Grüße
Marc

[Sven Hartge]

Post by Alexander Burger
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.

Interessant ist die Anzeige nur und ausschließlich dann, wenn beim
_letzten_ Hop diese Verluste auftreten. Alles vorher ist gerne
ICMP-Ratelimiting.

Nur wenn die Paketverluste sich ab einem Hop und dann bis zum letzten
Hop durchgehend zeigen, dann ist es interessant zu schauen, was zwischen
dem letzten guten und dem ersten schlechten Hop los ist und wo dieser
liegt.

S°

[Juergen Ilse]

Hallo,

Post by Sven Hartge

Post by Alexander Burger
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.

Interessant ist die Anzeige nur und ausschließlich dann, wenn beim
_letzten_ Hop diese Verluste auftreten. Alles vorher ist gerne
ICMP-Ratelimiting.
Nur wenn die Paketverluste sich ab einem Hop und dann bis zum letzten
Hop durchgehend zeigen, dann ist es interessant zu schauen, was zwischen
dem letzten guten und dem ersten schlechten Hop los ist und wo dieser
liegt.

... und man sollte sich vor falschen und/oder voreiligen Schluessen
hueten, dennasymmetrisches Routing ist zwischen verschiedenen Providern
nichts ungewoehnliches und bei traceroute und Konsorten sieht man immer
nur die Route "fuer den Hinweg" aber niemals die "fuer den Rueckweg"
der Pakete.

Vor etlichen Jahren hat mal ein Kunde behauptet, der erste Backbone-
Router im Netz meines Arbeitgebers muesse ein Problem haben, weil ein
traceroute bis zum letzten Hop vor diesem Router kurze Latenzen und
keine Paketverluste zeigten, aber an dem Hop tauchten Paketverluste
und hohe delays auf (der Kunde hatte einen Server bei meinem Arbeit-
geber gemietet und stellte fest, dass sein Zugriff auf diesen Server
unangenehm langsam war) ...
Die Schlussfolgerung war voreilig und falsch. Ab diesem Host verlief
der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
ueber einen anderen Provider als der Hinweg, und bei jenem anderen
Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
richtung ansehen muessen ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Rupert Haselbeck]

Post by Juergen Ilse
Die Schlussfolgerung war voreilig und falsch.

Das kann dem Kunden völlig egal sein

Post by Juergen Ilse
Ab diesem Host verlief
der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
ueber einen anderen Provider als der Hinweg, und bei jenem anderen
Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
richtung ansehen muessen ...

Das ist Sache des Hosters. Wenn dieser schon suboptimale Massnahmen
unternimmt, um seine Kosten zu senken, so ist es seine Aufgabe, die dabei
unweigerlich auftretenden zusätzlichen Probleme in den Griff zu bekommen

MfG
Rupert

[Juergen Ilse]

Hallo,

Post by Rupert Haselbeck

Post by Juergen Ilse
Die Schlussfolgerung war voreilig und falsch.

Das kann dem Kunden völlig egal sein

Eine falsche Schlussfolgerung als Tatsache vorgetragen kann ggfs.
die Zeit bis zur Fehlerbehebung erhoehen, weil der zustaendige
Techniker auf die falsche Faehrte gelockt werden koennte.

Post by Rupert Haselbeck

Post by Juergen Ilse
Ab diesem Host verlief
der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
ueber einen anderen Provider als der Hinweg, und bei jenem anderen
Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
richtung ansehen muessen ...

Das ist Sache des Hosters.

Um das Problem zu beheben, ist aber eine vom Kunden vorgetragene
falsche Diagnose nicht hilfreich.

Post by Rupert Haselbeck
Wenn dieser schon suboptimale Massnahmen unternimmt, um seine Kosten
zu senken,

Es ging nicht um "suboptimale Massnahmen um Kosten zu senken". Es gab
genau zu jenem Zeitpunkt eine Situation im Netz, wo der (ansonsten
einwabdfrei funktionierende) Weg vom Netz meines Arbeitgebers in das
Netz des Providers unseres Kunden mal nicht opzimal funktionierte
bzw. ueberlastet war. Das war eine nicht vorgerzusehende Ausnahme-
situation. Wie kommst du hier auf "suboptimale Massnahmen um Kosten
zu senken"? Es ist nun mal so, dass die meisten Kunden aus ihren
Heimnetzen nur "symmetrisches Routing" kennen, dass "symmetrisches
Routing" im weltweiten Routing zwischen verschiedensten autonomen
Systemen eher die Ausnahme als die Regel ist, und das Schlussfol-
gerungen, die stillschweigend symmetrisches Routing implizit voraus-
setzen, nur allzu oft voellig falsch sind. Die Geschichte war nur
ein Beispiel dafuer ...

Post by Rupert Haselbeck
so ist es seine Aufgabe, die dabei unweigerlich auftretenden
zusätzlichen Probleme in den Griff zu bekommen

Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
Ahnung hast?

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Rupert Haselbeck]

Post by Juergen Ilse
Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
Ahnung hast?

Hoppala, da hat wohl einer ein grösseres Problem, wenn man den Finger in die
Wunde legt. Aber du hast ja Recht, warum sachlich bleiben, wenn man auch
persönlich "argumentieren" kann...

Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des Kunden
das Problem nicht identifizieren kann, sollte man für Aufgaben einsetzen,
welche seinen Fähigkeiten angemessener sind

MfG
Rupert

[Juergen Ilse]

Hallo,

Post by Rupert Haselbeck

Post by Juergen Ilse
Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
Ahnung hast?

Hoppala, da hat wohl einer ein grösseres Problem, wenn man den Finger in die
Wunde legt.

Nein.

Post by Rupert Haselbeck
Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des Kunden
das Problem nicht identifizieren kann,

Es geht nicht um "nicht identifizieren kann" sondern um "sich erst einmal
auf die falsche Faehrte fuehren lassen", und das kann passieren (insbeson-
dere, wenn $KUNDE bevorzugt seine Schlussfolgerungen und erst auf mehr-
fachesa nachfragen die Fakten, die in zu dieser Schlussfolgerung gebracht
haben, anfuehrt ... So etwas merkst du spaetestens dann, wenn du als der-
jenige, der solche Probleme beseitigen soll, mit solchen Kundeninforma-
tionen beliefert wirst (schlimmstenfalls noch als "stille Post" via 1st-
Level-Support).

So ein Gelaber wie von dir hoere ich dirchaus oefter von Leuten, die nicht
die geringste Vorstellung haben, wie denn das Internet wirklich aussieht:
ein Konglomerat von mehr als einer halben Million IPv4-Netzbloecken, deren
Erreichbarkeit via BGP ausgetauscht und bei dem das routing (beeinflusst
von *allen* daran beteiligten Providern) sich staendig aendern kann, wo
niemand wirklich auch nur zu irgend einem Zeitpunkt einen annaehernden
Gesamtueberblick ueber alle daran beteiligten Routen hat und wo so gut
wie alle Aenderungen automatisiert ohne manuelles eingreifen passieren.

Manchmal denkt man sich da schon "es ist fast ein Wunder, dass das ganze
Zeug ueberhaupt noch so gut funktioniert".

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Helmut Hullen]

Hallo, Juergen,

Du meintest am 10.09.14:

[...]

Post by Juergen Ilse

Post by Rupert Haselbeck
Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des
Kunden das Problem nicht identifizieren kann,

Es geht nicht um "nicht identifizieren kann" sondern um "sich erst
einmal auf die falsche Faehrte fuehren lassen", und das kann
passieren (insbeson- dere, wenn $KUNDE bevorzugt seine
Schlussfolgerungen und erst auf mehr- fachesa nachfragen die Fakten,
die in zu dieser Schlussfolgerung gebracht haben, anfuehrt ...

Lass mich raten:
a) Du arbeitest im Kundendienst,
b) Deine Kunden sind allesamt IT-Fachleute und diagnostizieren stets
korrekt und umfassend?

Viele Gruesse!
Helmut

[Alexander Burger]

Post by Alexander Burger

Post by Sven Hartge

Post by Juergen Ilse
Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ...

Dito. Die Kombi "geringe Latenz, hohe Verluste" deuten meist auf ein
ICMP-Rate-Limit hin, meiner Erfahrung nach. (OK, einmal hatte ich einen
defekten SFP, der ca. 10% der Pakete zerstörte, so dass der empfangene
Switch sie wegwarf. Das äußerte sich an TCP-Verbindungen mit
Modem-Geschwindigkeit und eben 10% Paket-Verlust beim ICMP.)
Überlastete Leitungen zeigen sich meist zuerst durch eine hohe Latenz
und _dann_ erst durch verlorene Pakete.
In meinem anderen Artikelt sagte ich ja schon, dass er einmal andere
Tools benutzen soll, weil ich die von ihm gepostete Ausgabe von einer
mistigen Implementierung von traceroute schon kenne.

Post by Juergen Ilse
Allerdings habe ich keinerlei Er- fahrung mit "Internet ueber
TV-Kabel".

Eigentlich ist Internet via Kabel was Latenz und Paket-Verlust angeht
DSL überlegen.
Wenn der Anbieter den Coax-Strang bis zum Kabelverzweiger nicht
gnadenlos überbucht.
S°

vielen Dank.
/usr/sbin/mtr --report -c 100 hetzner.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6
0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
0.0
3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5
4.2
4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4
3.9
5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2
3.9
6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7
4.4
7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5
4.4
8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
0.0
11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9
13.0
12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6
10.2
13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5
13.1
14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7
3.9
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5
3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7
3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3
3.3
Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.
Gruß
Alex

es gab wieder Probleme am samstagabend, wie immer eigentlich:

hier ein Beispiel:

/usr/sbin/mtr --report -c 100 spiegel.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 19.0% 100 19.9 28.5 7.7 396.0 65.6
4.|-- 84.116.191.25 22.0% 100 10.9 22.9 8.5 284.6 44.5
5.|-- 84.116.191.2 21.0% 100 26.8 21.1 11.1 175.5 28.5
6.|-- xe-0.de-cix.frnkge03.de.b 21.0% 100 25.8 18.6 12.6 65.4 11.1
7.|-- 212.119.27.190 23.0% 100 14.3 40.5 12.7 463.8 90.5
8.|-- unknown.prolexic.com 20.0% 100 14.3 35.3 11.9 352.4 67.5
9.|-- unknown.prolexic.com 23.0% 100 13.9 27.0 11.7 257.9 43.6

die Verluste liegen bei 20 Prozent.
Das ist aber nur gemittelt.
Wenn ich das live anschaue, können die Verluste für einige Sekunden auch mal
bei 100 Prozent auf der ganzen Strecke liegen. Danach klappt es wieder, dann
wieder nicht usw.

Gruß
Alex

[Sven Hartge]

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 spiegel.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 19.0% 100 19.9 28.5 7.7 396.0 65.6
4.|-- 84.116.191.25 22.0% 100 10.9 22.9 8.5 284.6 44.5
5.|-- 84.116.191.2 21.0% 100 26.8 21.1 11.1 175.5 28.5
6.|-- xe-0.de-cix.frnkge03.de.b 21.0% 100 25.8 18.6 12.6 65.4 11.1
7.|-- 212.119.27.190 23.0% 100 14.3 40.5 12.7 463.8 90.5
8.|-- unknown.prolexic.com 20.0% 100 14.3 35.3 11.9 352.4 67.5
9.|-- unknown.prolexic.com 23.0% 100 13.9 27.0 11.7 257.9 43.6
die Verluste liegen bei 20 Prozent.
Das ist aber nur gemittelt.
Wenn ich das live anschaue, können die Verluste für einige Sekunden auch mal
bei 100 Prozent auf der ganzen Strecke liegen. Danach klappt es wieder, dann
wieder nicht usw.

Da die Verluste schon ab deinem lokalen Router auftreten, ist entweder
der defekt, oder, wenn du WLAN benutzt, das gestört.

Oder natürlich das Gerät, von dem du den Test aus machst, hat ein
Problem, da die Verluste scheinbar bei dir lokal entstehen.

Hast du ein zweites Gerät neben dem solchen, von dem du die Tests
gemacht hast, zur Hand?

Zeigt das zur gleichen Zeit die gleichen Probleme? Dann würde ich den
Router mal resetten, wenn die Probleme bestehen und schauen, was
passiert.

Was passiert, wenn du, während die Probleme bestehen, nur deinen Router
direkt anpingst, also "ping 192.168.1.1"?

S°

[Heiko Schlichting]

Post by Alexander Burger
/usr/sbin/mtr --report -c 100 spiegel.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3

Paketverluste bereits zum Router --> Das Problem liegt aber in Deinem
lokalen Netzwerk (einschl. des Routers). Wie ich schon vermutet habe, ist
*nicht* der Backbone des Providers Schuld¹.

Schliess einen Rechner mit einem Kabel² direkt am Router an und probiere es
damit aus. Falls es besser wird, ist Dein WLAN Schuld. Falls nicht,
reboote³ den Router

Heiko

¹ Die Gründe nannte ich ja im vorherigen Posting

² Ja, wir kennen alle die Ausreden mit "habe mit WLAN direkt neben dem
Router probiert". Nur Kabel ist Kabel!

³ in der Reihenfolge, sonst bist Du hinterher so schlau wie vorher

[Alexander Burger]

Post by Juergen Ilse
Hallo,

Post by Alexander Burger
ah, danke. dass ich da nicht früher darauf gekommen bin.
/usr/sbin/traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *

Bis hierhin anscheinend nur Hops mit ICMP-Paketfiltern und/oder so
konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
Aussage machen (solange man das droüüen von ICMP nicht bereits als
"mangelnde Qualitaet des Netzes" wertet).

Post by Alexander Burger
6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms

Ob hier das gedropte Paket auf ein wirkliches Problem hinweist, ist
IMHO nicht wirklich klar. Dass hier die 2 beantworteten Pakete an
verschiedene Router gingen, muss kein Problem sein. Die Antwortzeiten
weisen hier auch noch nicht unbedingt auf ein Problem hin, auch wenn
der Unterschied (13,8 zu 30.5 ms) etwas auffaellig ist.

Post by Alexander Burger
7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *

Hier koennten die Paketverluste auch durch aggresives ICMP-Rate-Limiting
hervorgerufen worden sein. Die Paketverluste *koennten* ein Indiz fuer
ein Problem sein, das muss aber nicht der Fall sein. Hohe Antwortzeiten
waeren da schon eher ein Indiz ... 21 ms sind aber fuer die Verbindung
nach Frankfurt (vermutlich zum DE-CIX, wenn ich mir den Rest der Ausgabe
ansehe) nicht so schlecht).

Post by Alexander Burger
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *

Hier wieder droppen von ICMP (siehe oben), eine Aussage darueber, ob ein
Netzwerkproblem vorliegt, ist aufgrund dessen nicht moeglich.

Post by Alexander Burger
23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *

Das duerfte eine IP-Adresse des Loadbalancers von Heise zu sein,
die Paketverluste duerften auf ICMP-Rate-Limiting und abweisen
des traceroutes beruhen. Da die Antwortzeiten bis zum 8.Hop nicht
sonderlich hoch waren und der Heise-Server im Netz von Plusline
steht, duerften hier die etwas hoeheren Antwortzeiten kein Indiz
fuer ein Problem im Netz deines Providers sein.

Post by Alexander Burger
das sieht ziemlich übel aus, oder?

Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
deines Providers treffen.

Post by Alexander Burger
Der ping selbst liegt unter 30 ms.
Hat aber 53prozent paketverlust :-(

Die mehr als 50% Paketverluste beim ping auf www.heise.de sind schon
eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
(den anderen Informationen im Thread nach zu schliessen) bei deinem
Provider, evt. auch auf der "last mile".
[ ping-Ausgabe gesnippt ]

Post by Alexander Burger
kann man daraus etwas ablesen?

Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
fahrung mit "Internet ueber TV-Kabel".
Tschuess,

super, vielen Dank.
Das hilft mir sehr, diese Ergebnisse zu lesen.
Besten Dank.

Ich habe auch mtr probiert. Siehe anderes posting.
Und es scheint so, dass die Antwortzeiten fast immer sehr kurz sind,
aber es teilweise Verlustraten von über 95 Prozent gibt.

Danke nochmals

Gruß
Alex

[Sven Hartge]

Post by Alexander Burger

Post by Sven Hartge
Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
tracert www.heise.de
Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.

ah, danke. dass ich da nicht früher darauf gekommen bin.

Wenn du Linux hast, dann nimm mal mtr (Paket mtr-tiny in Debian z.B.)

Post by Alexander Burger
das sieht ziemlich übel aus, oder?

Nein, du hast nur eine kaputte Implementierung von traceroute erwischt.
Es gibt z.B. in Debian diverse Pakete, die traceroute bereitstellen.
Versuche mal inetutils-traceroute.

Ich persönlich mag mtr lieber, weil man es z.B. dauerhaft laufen lassen
kann oder mit

mtr -r 100 heise.de

einen Report über 100 Zyklen anzeigen lassen kann, welcher
Aufschlussreicher ist wie nur einen Momentaufnahme.

Sieht bei mir z.B. so aus:

***@ds9:~$ time mtr -4 -s 1476 -r -c 100 heise.de
Start: Mon Sep 8 02:39:22 2014
HOST: ds9 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.40.64.1 0.0% 100 6.8 7.5 5.6 12.8 1.1
2.|-- 7211a-mx960-01-ae10-1020. 0.0% 100 7.4 11.1 6.2 93.9 13.1
3.|-- 7211a-mx960-02-ae0.gie.un 0.0% 100 6.6 10.9 6.2 60.2 8.2
4.|-- 1211f-mx960-01-ae5.dtm.un 0.0% 100 10.0 10.6 8.5 25.9 2.3
5.|-- 1411g-mx960-01-ae8.nss.un 0.0% 100 12.7 12.3 10.3 35.6 2.5
6.|-- gi1-15.c1.d.de.plusline.n 0.0% 100 12.5 18.1 11.5 180.2 25.0
7.|-- 212.19.61.13 0.0% 100 13.5 12.9 11.0 22.0 1.5
8.|-- redirector.heise.de 0.0% 100 12.2 12.9 11.3 17.1 0.7

-s 1476 nutzt größere ICMP-Pakete anstelle der 64 Byte beim Default.
-r erstellt einen Report anstelle einer interaktiven Curses-Oberfläche.
-c 100 sorgt dafür, dass jeder Hop 100 Mal angelaufen wird.
-4 bewirkt die Nutzung von IPv4, da ich auch einen IPv6-Link habe.

S°

[Marc Haber]

Post by Alexander Burger
Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
Internet-backbones angeschlossen wird, oder?
Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
ausgelegt sein.

Ohne Überbuchung im Backbone wären auch im DSL-Bereich die Preise
nicht haltbar.

Grüße
Marc

[Alexander Burger]

Post by Ulrich F. Heidenreich

Post by Alexander Burger
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.

Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das Haus zur
Verfügung. Aber das gilt natürlich nur für die letzten Meter. Danach könnte
das dann mit den Nachbarhäusern geteilt werden. Aber KabelBW hat Glasfaser-
Kabel. Da sollten doch keine Engpässe auftreten, oder?

Ich vermute eher, dass der Anschluss von KabelBW dann ans Internet sehr
klein dimensioniert ist, was für KabelBW günstiger ist, als sich an eine
fette Leitung einzumieten. In Stoßzeiten wird das aber dann zum Nadelöhr.

Gerade in Zeiten mit geringem Internetverkehr z. B. nachts, sind die
Geschwindigkeiten dann auch wirklich hoch. Große downloads laufen dann
wirklich flott.

Gruß
Alex

[Sven Hartge]

Post by Alexander Burger

Post by Ulrich F. Heidenreich

KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40
Mieteinheiten. Gerade am Wochenende/Abend könnten da 50 MBit schon
knapp werden.

Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das
Haus zur Verfügung. Aber das gilt natürlich nur für die letzten Meter.
Danach könnte das dann mit den Nachbarhäusern geteilt werden. Aber
KabelBW hat Glasfaser- Kabel. Da sollten doch keine Engpässe
auftreten, oder?

Kabel ist ein Shared-Medium. Bei dir könnte der halbe Ort am gleichen
Kabelverzweiger hänngen und sich die x Mal 50 MBit/s teilen müssen, die
DOCSIS2 dem Medium erlaubt.

S°

[Juergen Ilse]

Hallo,

Post by Alexander Burger

Post by Ulrich F. Heidenreich

Post by Alexander Burger
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben.

Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.

Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das Haus zur
Verfügung. Aber das gilt natürlich nur für die letzten Meter. Danach könnte
das dann mit den Nachbarhäusern geteilt werden. Aber KabelBW hat Glasfaser-
Kabel. Da sollten doch keine Engpässe auftreten, oder?

Wieso sollte auf Glasfaserkabeln kein Kapazitaetsengpass moeglich sein?
Wie jemand anders erwaehnte, kann ein Kanal auf dem Kabel bis zu 50 MBit/s
uebertragen. Wie viele Kanaele werden fuer wie viele Kunden verwendet?
Es wuerde mich *sehr* wundern, wenn nicht bereits dort ueberbucht wird.
Alle Kunden, die an dem selben Kabelabschnitt bis zu dem Punkt, an dem
der "Internet-Traffic ausgeleitet und auf anderem Wege weitergeleitet"
wird, haengen, teilen sich die fuer Internet reservierten Kanaele im
Kabel (und damit die fuer Internet in diesem Abschnitt reservierte
Gesamtuebertragungskapazitaet). Das kann u.U. auch schon einmal ein
ganzer Strassenzug sein ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Juergen Ilse]

Post by Alexander Burger
KabelBW ist oft unerträglich langsam.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?

Das ist ein Problem dessen, was man als "shared medium" bezeichnet (egal,
ob es sich um ein Kabel handelt, mit dem ganze Strassenzuege mit Internet
versorgt werden sollen, oder um einen WLAN-Kanal, auf dem sich Dutzende
von Nachbarn mit ihrem "SOHO-Equipment" draengeln) ...

Post by Alexander Burger
Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.

Das Kabel har nur eine gewisse "Gesamtkapazitaet", die sich nun mal alle
daran angeschlossenen Kunden teilen (eine gewisse "Ueberbuchung" ist auch
kein Problem, solange nicht gerade alle auf einmal die Leistung nutzen
wollen, aber falls das doch passiert ...).

Post by Alexander Burger
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.

Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen stoeranfaellige)
dedizierte Kupferdoppelader, die du mit niemandem teilen musst ...

Post by Alexander Burger
KabelBW macht so groß Werbung mit 50 MBit/s usw.

Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen auch
ganz genau, warum ... Das machen andere Provider uebrigens auch, weil
kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen lassen
will, wenn es mal einen Engpass im Netz gibt.

Post by Alexander Burger
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben.

Bei Internet via Fernsehkabel duerfte der Engpass oefters schon weit
vor dem Uebergang in andere Providernetze liegen ... Es ist nicht un-
ueblich, die Kapazitaeten zu ueberbuchen.

Post by Alexander Burger
So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
nicht alle Provider haben.

Bei DSL kann so etwas auch passieren, wenn der Uplink vom DSLAM
"zu duenn" ist. Wie oft das vorkommt, weiss ich nicht, wenn es
vorkommt, hast du dann aber das selbe Problem. Bei Internet via
Mobilfunk kommen zu diesem Problem (dass da natuerlich wegen
"shared Medium" auch vorkommen kann: da teilt man sich die Frequenz
auch nicht nur mit anderen Internet-Teilnehmern sondern auch mit
Telefongespraechen und SMS) auch noch die eher "kundenunfreundlichen
Tarife" dazu. Eigentlich muesste man fast den Rarschlag geben "Nimm
den Provider, den kein anderer hat, dann hast du zumindest vermutlich
kein Problem mit Ueberbuchung ...".

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Jörg Tewes]

Juergen Ilse schrub

Post by Juergen Ilse

Post by Alexander Burger
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.

Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen
stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
teilen musst ...

Bis zur Vst oder zum Outdoor. Ab da gehts dann auch für alle auf einer
Glasfaser weiter. Das Märchen vom Shared Medium und der daraus
resultierenden geteilten Datenrate wird man auch nie wieder los scheint
mir. Ist wohl ähnlich wie mit dem angeblichen Spruch von Bill Gates von
wegen der 640 Kbyte.

Post by Juergen Ilse

Post by Alexander Burger
KabelBW macht so groß Werbung mit 50 MBit/s usw.

Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen
auch ganz genau, warum ... Das machen andere Provider uebrigens auch,
weil kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen
lassen will, wenn es mal einen Engpass im Netz gibt.

Nein, weil wenn sie es nicht reinschreiben würden, sich jemand
beschweren würde, sobald er von seinem Kumpel, der mit einem 16 Mbit/s
Anschluß ans Netz angeschlossen ist, nicht mit 16 MBit/s runter laden
kann. Obwohl dieser nur einen Upload von 1 MBit/s hat.


Bye Jörg

[Juergen Ilse]

Hallo,

Post by Jörg Tewes
Juergen Ilse schrub

Post by Juergen Ilse

Post by Alexander Burger
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.

Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen
stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
teilen musst ...

Bis zur Vst oder zum Outdoor. Ab da gehts dann auch für alle auf einer
Glasfaser weiter.

Das ist richtig. Das selbe gilt auch bei Kabel: ab dem Punkt, wo alles
"gebuendelt" wird, hat man ein "shared Medium", bei Kabel ist *zusaetzlich*
die "Last Mile" ein "sjared Medium". Das "shared Medium" kann immer dann
zu einem Problem bei hoher Auslastung werden, wenn der Provider es erheb-
lich ueberbucht, und zumindest bei Internet via Kabel wurde das wohl in
der Vergangenheit auf der "last mile" nur allzu gern getan. Ob immer noch
gnadenlos ueberbucht wird, weiss ich nicht, aber das waere eine moegliche
Erklaerung fuer "zu den Zeiten wo alle surfen wird es grausam langsam,
ansonsten geht es".

Post by Jörg Tewes
Das Märchen vom Shared Medium

Es ist kein Maerchen. Ob das ein Problem ist, haengt davon ab, ob und
wenn ja wie sehr der Provider ueberbucht (und das muss nicht an jedem
von diesem Provider versorgten Ort gleich sein) ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Alexander Burger]

Post by Alexander Burger
KabelBW ist oft unerträglich langsam.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?
Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.
Das sind fast schon Modem-Geschwindigkeiten.
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben. So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
nicht alle Provider haben.

hier gab es mal eine ähnliche Diskussion zum Thema:
http://www.computerbase.de/forum/showthread.php?t=1052288

Gruß
Alex