xDSL.at

von **setchi** » Mo 03 Okt, 2005 23:11

Hi Leute,

Details:
inode xDSL 2048/512 flatrate, interleaving
kd-nr: 151255
ort: 6060 Hall in Tirol
router: zyxel prestige 660R-61
packet loss bei pings z.b. auf co1.inode.at oder ping.inode.at
betriebssystem: linux 2.4.21
getestete protokolle: PPPoE, PPTP

Habe seit 01.10.05 inode laufen. wobei laufen relativ ist...
habe schon verschiedenste rechner / netzwerkkarten / kabel / modems versucht - ohne erfolg

Code: Alles auswählen: sr01:~ # host ping.inode.at ping.inode.at has address 195.58.160.103 sr01:~ # ping 195.58.160.103 -i0 -c100 PING 195.58.160.103 (195.58.160.103) 56(84) bytes of data. 64 bytes from 195.58.160.103: icmp_seq=2 ttl=60 time=31.3 ms 64 bytes from 195.58.160.103: icmp_seq=3 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=4 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=5 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=6 ttl=60 time=29.9 ms 64 bytes from 195.58.160.103: icmp_seq=7 ttl=60 time=31.4 ms 64 bytes from 195.58.160.103: icmp_seq=8 ttl=60 time=32.7 ms 64 bytes from 195.58.160.103: icmp_seq=9 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=10 ttl=60 time=32.2 ms 64 bytes from 195.58.160.103: icmp_seq=11 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=12 ttl=60 time=31.0 ms 64 bytes from 195.58.160.103: icmp_seq=13 ttl=60 time=30.1 ms 64 bytes from 195.58.160.103: icmp_seq=14 ttl=60 time=29.7 ms 64 bytes from 195.58.160.103: icmp_seq=15 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=16 ttl=60 time=30.1 ms 64 bytes from 195.58.160.103: icmp_seq=18 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=19 ttl=60 time=34.8 ms 64 bytes from 195.58.160.103: icmp_seq=20 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=21 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=22 ttl=60 time=30.7 ms 64 bytes from 195.58.160.103: icmp_seq=23 ttl=60 time=31.6 ms 64 bytes from 195.58.160.103: icmp_seq=27 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=28 ttl=60 time=31.7 ms 64 bytes from 195.58.160.103: icmp_seq=29 ttl=60 time=34.3 ms 64 bytes from 195.58.160.103: icmp_seq=30 ttl=60 time=32.8 ms 64 bytes from 195.58.160.103: icmp_seq=31 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=32 ttl=60 time=31.1 ms 64 bytes from 195.58.160.103: icmp_seq=33 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=34 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=35 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=36 ttl=60 time=31.3 ms 64 bytes from 195.58.160.103: icmp_seq=37 ttl=60 time=32.5 ms 64 bytes from 195.58.160.103: icmp_seq=38 ttl=60 time=32.3 ms 64 bytes from 195.58.160.103: icmp_seq=39 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=40 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=42 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=43 ttl=60 time=30.1 ms 64 bytes from 195.58.160.103: icmp_seq=44 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=45 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=46 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=47 ttl=60 time=30.8 ms 64 bytes from 195.58.160.103: icmp_seq=48 ttl=60 time=31.3 ms 64 bytes from 195.58.160.103: icmp_seq=49 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=50 ttl=60 time=30.2 ms 64 bytes from 195.58.160.103: icmp_seq=51 ttl=60 time=30.3 ms 64 bytes from 195.58.160.103: icmp_seq=52 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=53 ttl=60 time=32.6 ms 64 bytes from 195.58.160.103: icmp_seq=54 ttl=60 time=31.7 ms 64 bytes from 195.58.160.103: icmp_seq=55 ttl=60 time=32.4 ms 64 bytes from 195.58.160.103: icmp_seq=57 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=59 ttl=60 time=30.6 ms 64 bytes from 195.58.160.103: icmp_seq=60 ttl=60 time=31.6 ms 64 bytes from 195.58.160.103: icmp_seq=62 ttl=60 time=30.0 ms 64 bytes from 195.58.160.103: icmp_seq=63 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=64 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=65 ttl=60 time=29.7 ms 64 bytes from 195.58.160.103: icmp_seq=66 ttl=60 time=31.8 ms 64 bytes from 195.58.160.103: icmp_seq=67 ttl=60 time=30.4 ms 64 bytes from 195.58.160.103: icmp_seq=68 ttl=60 time=32.1 ms 64 bytes from 195.58.160.103: icmp_seq=69 ttl=60 time=31.2 ms 64 bytes from 195.58.160.103: icmp_seq=70 ttl=60 time=31.9 ms 64 bytes from 195.58.160.103: icmp_seq=72 ttl=60 time=32.6 ms 64 bytes from 195.58.160.103: icmp_seq=73 ttl=60 time=31.7 ms 64 bytes from 195.58.160.103: icmp_seq=74 ttl=60 time=29.9 ms 64 bytes from 195.58.160.103: icmp_seq=75 ttl=60 time=31.5 ms 64 bytes from 195.58.160.103: icmp_seq=76 ttl=60 time=32.9 ms 64 bytes from 195.58.160.103: icmp_seq=77 ttl=60 time=31.1 ms 64 bytes from 195.58.160.103: icmp_seq=78 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=79 ttl=60 time=31.4 ms 64 bytes from 195.58.160.103: icmp_seq=80 ttl=60 time=31.2 ms 64 bytes from 195.58.160.103: icmp_seq=81 ttl=60 time=29.1 ms 64 bytes from 195.58.160.103: icmp_seq=82 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=83 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=84 ttl=60 time=29.7 ms 64 bytes from 195.58.160.103: icmp_seq=85 ttl=60 time=31.4 ms 64 bytes from 195.58.160.103: icmp_seq=87 ttl=60 time=30.9 ms 64 bytes from 195.58.160.103: icmp_seq=89 ttl=60 time=31.2 ms 64 bytes from 195.58.160.103: icmp_seq=90 ttl=60 time=32.9 ms 64 bytes from 195.58.160.103: icmp_seq=91 ttl=60 time=31.8 ms 64 bytes from 195.58.160.103: icmp_seq=93 ttl=60 time=31.2 ms 64 bytes from 195.58.160.103: icmp_seq=94 ttl=60 time=31.2 ms 64 bytes from 195.58.160.103: icmp_seq=95 ttl=60 time=31.8 ms 64 bytes from 195.58.160.103: icmp_seq=96 ttl=60 time=31.8 ms 64 bytes from 195.58.160.103: icmp_seq=98 ttl=60 time=31.6 ms 64 bytes from 195.58.160.103: icmp_seq=99 ttl=60 time=32.1 ms --- 195.58.160.103 ping statistics --- 100 packets transmitted, 85 received, 15% packet loss, time 1384ms rtt min/avg/max/mdev = 29.170/31.327/34.892/0.992 ms, pipe 4, ipg/ewma 13.988/31.550 ms sr01:~ #

(falls wer meint -i0 ist zu viel verlangt - keine panik ich habs auch mit -i1 versucht... selbes ergebnis *heul*)

MEIN modem funktioniert bei einem kollegen einwandfrei (0% loss)
SEIN modem funzt bei mir genauso "schlecht" wie mein eigenes.

da ich nicht mehr weiß was ich noch tun könnte hab ich die hotline antelefoniert, morgen sollte mich ein techniker anrufen und einen termin ausmachen.

ich vermute es liegt an den URALTEN telefonleitungen hier im haus. welche möglichkeiten hab ich ?
sind die leitungen im haus eigentum der telekom ?
installiert die telekom neue leitungen ?
wer bezahlt das ganze ?

fragen über fragen.

ich hoffe dass mir jemand mit erfahrungsberichten aushelfen kann.
inzwischen hoffe ich dass die techniker von inode "wunderheiler" sind

der support ist bis jetzt EINZIGARTIG - obwohl mein internet ziemlich besch***** ist derzeit großes lob an inode für den guten support !!

von **tszr** » Di 04 Okt, 2005 05:16

sind die leitungen im haus eigentum der telekom ?
installiert die telekom neue leitungen ?
wer bezahlt das ganze

so viel ich weiß muss bei entbündelten leitungen, der jeweilige betreiber also in deinem fall inode die komplette wartung machen, also musst wohl dort mal ansetzten, ob die dann wirklich neune leitungen bei dir verlegen, kann ich zwar nicht glauben, aber du kannst es ja mal versuchen.

von **littlety** » Di 04 Okt, 2005 07:02

Ah da schau her - schöne Grüße aus Absam!
Die Leitung zu unserem Haus ist auch uralt (etwa 1959 verlegt) und somit nicht mehr die beste...
Als ich 2002 online ging, kam die Telekom und montierte Telefonsteckdose und Splitter
an einer neuen Leitung vom Haus-Anschluß zum Rechner.
Das Ganze hat damals glaube ich 216 Euro gekostet.

Auch bei der Umstellung auf xDSL waren die Herrschaften von der Post ganz kurz da,
aber mit der neuen Leitung war alles i.O., es ging, soweit ich das mitbekommen habe,
nur um einen bestimmten Widerstand in der Telefonsteckdose.

von **jutta** » Di 04 Okt, 2005 07:27

was genau funktioniert denn nicht? laut cisco sind bis zu 20% packetloss unproblematisch. http://www.cisco.com/en/US/products/sw/ ... #wp1018913

da die leitung erst 4 tage alt ist, wuerde ich zunaechst abwarten. sie wird von inode ohnehin laufend ueberprueft und angepasst. wenn du in 1-2 wochen noch probleme/wuensche hast, schreib an den support.

von **setchi** » Di 04 Okt, 2005 22:56

was nicht funktioniert?

* dass die nameserver-requests zeitenweise ins nirvana gehen und die namensauflösung oftmals einige sekunden dauert zum beispiel...
* dass ich inzwischen einen caching-nameserver eingerichtet hab um das problem zumindest teilweise in den griff zu kriegen...
* dass im browser manche seiten einfach nicht laden wollen verstehe ich auch nicht (mit hard-/software-neustarts und verschiedenen PCs probiert...)

vielleicht bin ich zu egoistisch oder zu optimistisch wenn ich gerne einen packet loss von 0% hätte...

wie alt die leitung hier im haus ist hab ich keine ahnung - aber sicher schon etwas älter...

ich hoffe nur das wird noch was

[EDIT] ist es möglich dass fastpath bei einem neuanschluss aktiviert ist !? glaub ich zwar kaum aber möglich ist alles...

[EDIT2] der download-speed stimmt zwar (242KB/sec laut wget) aber emule ähnelt einer e-snail und der seitenaufbau im browser war an meiner zweifellos überlasteten ex-chello-leitung noch schneller :cry:

lg aus hall in tirol
flo

von **jutta** » Mi 05 Okt, 2005 08:11

trag die nameserver fix ein, das beschleunigt die abfragen meistens enorm.

per default ist bei inode immer interleave eingestellt.

du schreibst, dass du schon verschiedene modems usw getestet hast ...
welchen anschluss hast du genau? einzelplatz? mehrplatz? privat? business?
wie hast du das zeug installiert?
verwendest du einen router oder haengt der pc direkt am modem?

wenn du emule laufen hast, darfst du dich nicht wundern, dass alles andere daneben langsam geht! ein wesentlicher unterschied zwischen chello und adsl ist, dass bei adsl die bandbreite definitionsgemaess asymmetrisch ist. das muss man bei den einstellungen von emule beruecksichtigen. (upload reduzieren. die max connections auch reduzieren)

von **setchi** » Mi 05 Okt, 2005 17:02

asymmetrisch bedeutet doch nur dass upload im vergleich zu download weniger bandbreite hat - oder ?
und diese eigenschaft hatte mein chello auch (1024/128)

ich hab einzelplatz pivat;
ich habs mit dem (linux-) PC direkt am modem versucht und auch mit (windows-) PCs dahinter (NAT per iptables/kernel-firewall)

download vom inode FTP bringt zwar die erwünschte bandbreite aber packet loss beim pingen ist nach wie vor bei mindestens 8%
upload muss ich heute erst noch testen...

[EDIT] hatte die nameserver ja fix eingetragen, allerdings funktioniert die namensauflösung für den linux-pc und die windows-pcs dahinter mit einem caching nameserver sehr viel schneller...!?

vielen dank jedenfalls für die antworten...

lg flo

von **jutta** » Mi 05 Okt, 2005 18:47

> asymmetrisch bedeutet doch nur dass upload im vergleich zu download weniger bandbreite hat - oder ?

stimmt.

> und diese eigenschaft hatte mein chello auch (1024/128)

allerdings war sie bei chello nur so *eingestellt*, da waere symmetrisch genauso moeglich. bei adsl ist die asymmetrie systemimmanent. leider kenne ich chello zu wenig, um zu beurteilen, ob der unterschied wesentlich ist.

> [EDIT] hatte die nameserver ja fix eingetragen, allerdings funktioniert die namensauflösung für den linux-pc und die windows-pcs dahinter mit einem caching nameserver sehr viel schneller...!?

ok, ein korrekt installierter nameserver kann schon was bringen. ich bin von einer anderen situation ausgegangen: die meisten soho-router und manche linux-distris neigen dazu, per default den gateway als name-server einzutragen und wenn der dann der aufgabe nicht gewachsen ist, wird schon ping auf einen externen host zum geduldspiel.

ansonsten wuerde ich sagen: warte mal 1-2 wochen ab, bis die leitung fertig getuned ist. wenn du dann noch immer stoerend hohen packet loss hast, schreib an den support.

von **setchi** » Do 06 Okt, 2005 12:53

den gateway als nameserver ?
komisch - ist mir noch NIE passiert *g*

und nochmal zu chello: die maximalkapazität der kabelmodems (AFAIK: 48MBit/sec down, 12MBit/sec up) ist an sich auch asymmetrisch und chello wird auch asymmetrisch "eingestellt" - allerdings ist die ganze thematik sowieso überflüssig, da ich vorher "asymmetrisches chello" hatte (1024/128 kbit/sec) und jetzt "asymmetrisches xdsl" habe (2048/512 kbit/sec) das allein den datenraten nach "weniger asymmetrisch" ist als chello war (krass deutsch...)

dass mein seitenaufbau im browser (egal ob am linux-router oder am windows-client) lahmer ist als meine chello-leitung bei hoher emule-auslastung zur rush-hour macht mich doch etwas stutzig...

grundsätzlich vertraue ich cisco bezüglich "laut cisco sind bis zu 20% packetloss unproblematisch." (hab ja auch mal den CCNA gemacht

) aber ich weiß nicht was mit meiner leitung los ist, ich vermute mal es liegt an der leitung selber und der packet loss ist ein anzeichen dafür dass da mehr nicht stimmt...

beim chellomodem sah ich die übertragungsfehler im ifconfig, beim zyxel-teil sieht man das nicht mehr

Code: Alles auswählen: chello-router:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:04:76:96:3B:81 inet addr:80.109.132.xxx Bcast:80.109.132.255 Mask:255.255.255.0 inet6 addr: fe80::204:76ff:fe96:3b81/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:423848681 errors:81181 dropped:0 overruns:1 frame:121902 TX packets:63401395 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1327926849 (1266.4 Mb) TX bytes:360506049 (343.8 Mb) Interrupt:12 Base address:0xa800

ob die übertragungsfehler zwischen linux-router und chello-modem auf der ethernet-leitung passieren oder wirklich im kabelnetz weiß ich nicht...

ftp-download läuft mit 240KByte/sec (=1920 von 2048Mbit/sec) SUPER !!
ftp-upload funktioniert weder auf speedtest.inode.at/incoming noch auf meinem account auf ftp.inode.at, der transfer bleibt jedesmal nach 32KByte stehen - ich weiß nicht warum...

Code: Alles auswählen: router:/ # ftp -u ftp://[email protected]/speedtest-20mb ./speedtest-20mb Connected to members.inode.at. 220- 220- 220------------------------------------------------ 220- 220- WILLKOMMEN AM FTP-SERVER VON INODE 220- 220-E-Mail: [email protected] - Tel.: +43 59 999 220- 220------------------------------------------------ 220- 220- 220 Inode.Internet FTP service 331 Password required for 347363. Password: 230 Zugangsberechtigung für User <347363> erfolgreich! Remote system type is UNIX. Using binary mode to transfer files. 200 Type set to I local: ./speedtest-20mb remote: speedtest-20mb 229 Entering Extended Passive Mode (|||41351|) 150 Opening BINARY mode data connection for speedtest-20mb 0% | | 32768 0.25 KB/s - stalled - send aborted. Waiting for remote to finish abort. 421 Service not available, user interrupt. Connection closed. 32768 bytes sent in 02:09 (0.24 KB/s) router:/ #

heut hab ich nochmal bei der hotline angerufen und denen gesagt dass der upload nicht funktioniert, da hat der gemeint ich soll mal versuchen ein kürzeres kabel zwischen telefondose & modem anzustecken. ansonsten einfach warten bis der anschluss fertig getuned ist...
da ich vor 2 wochen übersiedelt und momentan auf arbeitssuche bin brauch ich das internet so schnell als möglich...
der hotliner hat mich damit vertröstet dass mein fall sowieso in bearbeitung sei - das hilft mir auch wenig *heul*

danke inzwischen...
lg flo

xDSL.at

packet loss bei inode xDSL 2048/512

packet loss bei inode xDSL 2048/512

Wer ist online?