Verbindungsschwankungen unter Suse 9.3 und NetCologne-DSL

Erstmal Grüße an alle Linux-Club-Mitglieder,

bevor ich über den Titel dieses Themas schreibe, wollte ich nur vorschieben, dass ich Newbie bin, gegoogelt und schon hier im Forum gesucht habe. Ich habe sogar nützlich Beiträge gefunden, die aber (so glaube ich) nicht auf mein Problem zu treffen. Also bitte nicht schlagen.

Mein Schwierigkeiten:

Ich benutze Suse Linux 9.3 und mein Provider ist NetCologne. Ich habe eine 1Mbit-Flatrate. Von anfang an habe ich bemerkt, dass die Download-Raten sehr stark springen (von 115 Kb/s auf 56...auf 96 und wieder auf 115 usw.). Zunächst habe ich mir nichts dabei gedacht, bis am letzten Wochenende über 48 h nur noch 2KB/s gingen.
An meiner Konfiguration hatte ich nichts verändert und NetCologne hat nach Durchmessung der Leitung gesagt, dass auch diese ok sei.
Der technische Support von NetCologne sagte mir, dass evtl. ein paar Einstellungen meines Betriebssystems falsch sind. Aber die haben keine Ahnung von Linux. Auf jeden Fall sagte man mir, dass eine Übertragung um die 100 Kb/s ohne springen möglich sein muss.
Ich habe schon hier im Forum schon u.a. den Beitrag zur MTU gelesen, bin mir aber nicht sicher, ob es daran liegen könnte.

Vielleicht hatte ja jemand bei NetCologne die gleichen Probleme oder es leigt vielleicht sofort auf der Hand, was falsch ist. Nur ich als Anfänger sehe es nicht.

Bin für jede Hilfe sehr dankbar, Gruß Aldaron

Zu meinem System:

-Suse Linux 9.3
- NetCologne DSL (1Mbit)
- eingeschaltete Suse-2-Firewall mit Standard-Konfiguration
- AntiVIr für Linux-Workstation
- Rechner ist ohne Router oder sonstiges direkt über das Modem mit dem Splitter verbunden.

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
erx-sto1-lo0.ne * 255.255.255.255 UH 0 0 0 dsl0
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default erx-sto1-lo0.ne 0.0.0.0 UG 0 0 0 dsl0



PING linux-club.de (80.237.130.32) 56(84) bytes of data.
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=1 ttl=55 time=57.6 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=2 ttl=55 time=55.9 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=3 ttl=55 time=57.0 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=4 ttl=55 time=58.4 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=5 ttl=55 time=57.1 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=6 ttl=55 time=55.6 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=7 ttl=55 time=57.4 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=8 ttl=55 time=58.7 ms
64 bytes from server024.webpack.hosteurope.de (80.237.130.32): icmp_seq=9 ttl=55 time=55.2 ms

--- linux-club.de ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8006ms
rtt min/avg/max/mdev = 55.281/57.032/58.710/1.175 ms



ifconfig
dsl0 Protokollunkt-zu-Punkt Verbindung
inet Adresse:84.44.128.8 P-z-P:213.196.239.104 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:13590 errors:0 dropped:0 overruns:0 frame:0
TX packets:10201 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:3
RX bytes:16616958 (15.8 Mb) TX bytes:798357 (779.6 Kb)

eth0 Protokoll:Ethernet Hardware Adresse 00:40:95:30:B47
inet Adresse:192.168.10.1 Bcast:192.168.10.255 Maske:255.255.255.0
inet6 Adresse: fe80::240:95ff:fe30:b4d7/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13753 errors:180 dropped:0 overruns:0 frame:0
TX packets:10381 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:16925782 (16.1 Mb) TX bytes:1034240 (1010.0 Kb)
Interrupt:11

lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:4664 (4.5 Kb) TX bytes:4664 (4.5 Kb)

Hi!
Ich hab selber die 4MBit Flat von NC und in letzter Zeit auch ab und zu Probs mit dem CastleNet Modem gehabt,dabei aber weniger Transferspeedprobs sondern eher das PADO-Pakete nicht ankamen und daher die Wiedereinwahl quasi unmöglich wurde. Welches Release von dem CastleNet Modem hast du? Das mit oder das ohne den Kippschalter zur Stromversorgungsabschaltung? Ich hab meines letztes Wochenende getauscht da ich zum wiederholten Male nicht ins Netz kam und davon echt die Faxen dicke hatte. Wenn du irgendwo noch ein anderes DSL-Modem haben solltest, dann check mal ob es damit besser geht. Vielleicht beisst es sich auch mit deiner Netzwerkkarte. Hast du eine Onboard-Netzwerkschnittstelle aktiv oder eine separate Karte (vor allem:welches Modell/welcher hersteller seitens Netzwerkkarte)? Da könnte es nämlich auch dran liegen...

Bis denne,
Tom
P.S.:Gute Infos bzw. Support dazu sind auch auf dem NetCologne Newsserver zu finden...

Hallo,

zunächst danke für deine schnelle Antwort. Ich habe das Modem mit Kipp-Schalter für die Stromversorgung. Die Netzwerkkarte ist schon was älter. Es ist eine 100/10 Mbit-Steckkarte, die noch aus der Zeit stammt als ich DSL bei t-online hatte (älter als drei Jahre). Den Hersteller kann ich so nicht sagen, da die Karte im Paket dabei war.

Unter t-online hat sie mit Windows 2000 immer gute Dienste geleistet.

Werde vielleicht auch mal das Modem umtauschen.

Bin aber weiterhin für alle Tips dankbar!

Hi!
Naja,das mit dem Kippschalter war genau das was bei mir den Terz gemacht hatte...offenbar ist das Prob hier nun aber erledigt da ich nun die Version ohne den Kippschalter habe....vielleicht solltest du mal einen Dauerdownload zum Test anwerfen und dabei die Transferraten beobachten, z.B. mal ein ISO-Image vom GWDG-Server runterziehen,der hat wenigstens sinnvolle Performance mit der man sowas testen kann, denn Transferspeedsprünge können ja auch durchaus schlichtweg am Server der Gegenseite und dessen Auslastung liegen (also wenn man nun definitv kein P2P laufen hat was einem ja die Leitung meist recht vollbombt und damit sinnvolle Transferraten ebenso verhindert)...ggf. könnten wir ja ebenso mal einen Test selbst durchziehen,immerhin hab ich hier nen Upstream von 576 KBit der ja dann ebenso konstant sein müsste im Falle eines Dateitransfers größerer Dateien (es sei den die 12h Zwangstrennung schlägtr gerade zu)..

Bis denne,
Tom vun dr' Schäl Sick
P.S.ie Netzwerkkarte müsste dann wohl eine von Allied telesyn sein mit RTL 8139er Chipsatz,die sind normal recht robust...