• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Samba in einer Richtung extrem langsam

Status
Für weitere Antworten geschlossen.

strikegun

Newbie
Also mit der rtl 8169 (treiber: rt8169)
gibt es auch keinen erfolg.

Ich habe Knoppix 5.0 DVD probiert. Da läuft es noch schlechter. Aber will nicht ausschliessen das ich mich da verkonfiguriert habe. Da hatte ich nur max 800kb/s.
Naja nicht mal ethtool hat irgenwas andgezeigt bei knoppix.
Morgen teste ich mal Suse 10.1beta8
 
OP
Kurt M

Kurt M

Hacker
Frankie777 schrieb:
Es scheint insbesondere ein Problem bei Suse 10 und GBit Netzwerkkarten/Treiber (bestimmter Type?) zu sein.

BINGO, Problem bei mir ist gelöst.

Ja, es hatte was mit Suse 10.0 und GigaBit Netzwerkkarten zu tun !

Bei Untersuchungen mit Ethereal ist mir aufgefallen, dass oft Retries drin sind, meist gefolgt von 100 bis 200 ms langen Pausen. Das deutet auf ein Hardwareproblem hin.

Ich hatte aus persönlicher Schlampigkeit ein normales CAT-5 Kabel verwendet (... wird schon gehen, ist ja nicht so lang, bla,bla...) .
Heute habe ich mir ein CAT-7 gekauft, angeschlossen, und das Netzwerk war nicht wiederzuerkennen, rasend schnell, keine Retries mehr zu finden.

Trotzdem kann ich Suse nicht ganz unschuldig entlassen weil:
* mit Suse 9.3 trat das Problem nicht merkbar auf.
* mit NFS lief es viel schneller als mit Samba.

Offensichtlich wird das Netzwerkprotokoll unter Suse 10 nicht so gut mit Übertragungsfehlern fertig, wie das alte 9.3.
Was bei Suse 10 auffällt ist, dass nach Übertragungsfehlern oft (bzw eigentlich immer) eine viele 100ms bis 1 s lange Schnarchpause eingelegt wird. Diese Pausen sind bei 9.3 nicht vorhanden. Daher merkt man die Übertragungsfehler offensichtlich erst mit 10.0.
 

strikegun

Newbie
Ich nutze Cat5e Kabel. Aber nehme mir heute mal ein Cat6 aus der Firma mit. Ich berichte dann heute abend ob es bei mir auch half.
 

Dr. Glastonbury

Advanced Hacker
Hmmm,
das ganze erklärt aber keineswegs, das Phänomen, das bei mir auftrat/tritt - wie kann es sein, dass das Kopieren bei zwei gleichzeitigen Vorgängen mit voller Bandbreite, bei einem einzelnen Vorgang nur extrem langsam von statten geht.

Das kann irgendwie nicht an der Hardware alleine liegen - das ist IMHO ein Softwareproblem - und das seit SuSE10 ;)
 

strikegun

Newbie
Mit cat6 keine Änderung. immer noch lahm.

Ich entpacke 250MB über das Netzwerk und es dauert ca 1 minute.
Dann wenn ich es nochmal entpacke geht es ab und ist in 10 sekunden fertig.
Ziel war beides ein anderer Ort.
 

Frankie777

Advanced Hacker
Cat 5e und Cat6 sind für 1000 MBit Netzwerke geeignet.

Ohne mal in den Ethereal Log zu schauen wird sich das Problem nicht weiter analysieren lassen.
 

Yehudi

Guru
Kurt M nutzt ein cat-7, und hatte vorher ein cat-5, und strikegun ist nur auf cat-6 umgestiegen, ich würde ihn mal drum beten genau das gleich zu tun.
 

thomas

Newbie
Ich hab hier mal mitgelesen.
Ich habe zwei PC: 1. linvdr, Sambaserver, rtl8169
2. Knoppix 04`05, Sambaclient, Marvell wasweisich auf Asus Sockel 939-Board.
Beide mit Billig-Cat5 verbunden und feste IP-Adressen.
In beide Richtungen ca 17-23 MB/s, was sich mit den internen Kopiervorgängen von Platte zu Platte deckt. Kopiert wurden nur grosse Video-files ab 2GB, oder der gesammte Video-ordner.
So meine Erfahrung, also alles sehr fix.
 

strikegun

Newbie
nebenbei mal erfäht:
Ich habe mir die changelog vom neuen KernelPatch angeschaut.
Dort sind ja einige Änderungen für sk98lin Treiber.
Kann sonst noch jemand was sehen was unser Problem entgegen kommt?

@Yehudi
Meinst ich soll auch noch CAT7 Kabel probieren? Wäre doch etwas sehr hoch gegriffen oder? (CAT7 -> 10gibabit Netze)
 

Yehudi

Guru
Versuch das irgendwie so, das Du es umtauschen kannst. Es klingt vielleicht sehr merkwürdig, es gibt manchmal Dinge die man nicht ganz logisch erklären kann.
 

strikegun

Newbie
@jengelh
genau das war ja meine frage in meinem eigenem Threat
Es kann dann nur auf linux seite gecacht sein. und dann kann es auch nix mit dem Kabel sein und es wäre ein Linux/samba problem.
Nun die frage wie cacht ein System z.b 700MB? und was wird gecacht? die daten selbst sicher nicht. also eher die Datenblöcke wo sie liegen?
 
OP
Kurt M

Kurt M

Hacker
nachdem ich jetzt einige Zeit lang mit dem CAT 7 gearbeitet habe, kann ich wieder neue eigenartige Dinge berichten. Leider macht es das noch undurchsichtiger:

Das Gigabit Netzwerk geht mit dem Cat7 deutlich besser als mit meinem alten CAT5 (15m länge), was ja auch kein Wunder ist.
Das Problem, dass Samba in einer Richtung so langsam ist, hat sich erst gelöst, um nach einiger Zeit wieder von neuem aufzutreten. Es geht deutlich besser als vorher, aber leider nicht immer.

Das neue ist, dass ich jetzt auch die identischen Probleme (Transfer in der Richtung Server->Client extrem langsam) auch unter NFS habe, aber lustigerweise Applikationsabhängig:

* Filetransfer mit Konqui geht in beiden Richtungen jetzt extrem gut mit 25 bis 30 MB/s.
* Das Programm digikam kann plötzlich seine Fotos vom Server nur mehr in Zeitlupe laden (ca. 50 kB/s)
* Schalte ich auf normales 100MBit Netzwerk um, so läuft digikam wieder ganz normal schnell (und Samba auch).

Eine Untersuchung mit Ethereal hat gezeigt, dass ich fast keine Retransmissions mehr habe (so wie früher mit Cat5). Allerdings stoppt der Datentransfer Server->Client immer wieder für genau 1 Sekunde. Und zwar nur bei Benutzung von Samba, oder bei Benutzung von digikam (welches seine Daten über einen NFS mount holt).

Das Problem scheint durch alle möglichen Ursachen beeinflußt zu werden, das Kabel ist nur eine davon.

Ich hab auch wieder mal eine Stunde danach gegoogelt, es gibt auch andere die das Problem haben, Lösung hatte ich jedoch keine gefunden.
 
strikegun schrieb:
@jengelh
genau das war ja meine frage in meinem eigenem Threat
Es kann dann nur auf linux seite gecacht sein. und dann kann es auch nix mit dem Kabel sein und es wäre ein Linux/samba problem.
Nun die frage wie cacht ein System z.b 700MB? und was wird gecacht? die daten selbst sicher nicht. also eher die Datenblöcke wo sie liegen?
Es wird auf beiden Seiten gecacht, NFS-Server und NFS-Client.
 

strikegun

Newbie
also ich bin jetzt weiter gekommen.

Ich habe meine alte platte abgeklemmt und eine neue 80GB platte angeschlossen.
Ich habe dann SuSE 10.1 beta8 installiert. Ohne Oberfläche und dannach nur noch Samba eingerichtet.
Mit dem neuen System habe ich 37MB/s *freu*
Komisch ist noch: Ich habe dann meine alte Platte mit dem Suse10 dazugehängt (also nicht als bootdisk) und mal die daten von dort kopiert. Es war auch bei ~20-37 MB/s aber es gab zusammen b rüche wieder runter auf 5 MB/s aber nur sehr kurz. Dann ging es wieder rauf. Aber war nie so konstant und stabil auf 37MB/s wie bei den neuinstallierten Partitionen. Die Festplatten sind beide Maxtor und eigentlich des selben Alters. Ca. 1,5 Jahre alt.

Nun was ist der unterschied?

Altes System:
SuSE 10
Kernel 2.6.13
ReiserFS Tools 3.6.18
diverse netzwerktreiber probiert

Neues System:
SuSE 10.1 beta8
Kernel 2.6.16 rc6
ReiserFS Tools 3.6.19
Standart Treiber für sk98lin (skge)

Ich werde wenn ich wieder aus meinem WE-Urlaub bin, einfach Suse10 neuinstallieren ohne jeden Krams. Mal sehen wie es dann läuft.


PS. wenn ich auf dem alten System auf 100base schalte dann hab ich konstant 5-6 MB/s. Auf 1000base nur noch 0,5-1,2Mb/s
 

koala313

Newbie
strikegun schrieb:
also ich bin jetzt weiter gekommen.
.
.
.
Nun was ist der unterschied?

Altes System:
SuSE 10
Kernel 2.6.13
ReiserFS Tools 3.6.18
diverse netzwerktreiber probiert

Neues System:
SuSE 10.1 beta8
Kernel 2.6.16 rc6
ReiserFS Tools 3.6.19
Standart Treiber für sk98lin (skge)

Ich werde wenn ich wieder aus meinem WE-Urlaub bin, einfach Suse10 neuinstallieren ohne jeden Krams. Mal sehen wie es dann läuft.


PS. wenn ich auf dem alten System auf 100base schalte dann hab ich konstant 5-6 MB/s. Auf 1000base nur noch 0,5-1,2Mb/s




morgens.
hab aus verzweiflung meine alte rtl-8139 mal ausprobiert und suse 9.3 rennt über samba. mit meinem gigabit-onboard schläft samba fast ein oder wie soll ich 25kb/s sonst nennen?
hatte zuvor auch mal knoppix 3.4 mit den kerneln 2.4 und 2.6 ausprobiert, selbiges einschlafen über gigabit.. scheint so als ob es keinen vernünftigen treiber für gigabit geben würde und/oder ich als newbie nicht wissend genug bin, den treiber von realtek zu installieren.

koala313
 
OP
Kurt M

Kurt M

Hacker
wenigstens haben wir den Trost, dass man nicht alleine mit dem Problem dasteht. Es scheint also nicht an der eigenen Dummheit sondern eher an einem Fehler in irgendeinem Treiber, Samba, Kernel oder sonst wo zu liegen.

Dabei zeigt der Fehler eine ganz lästige Eigenschaft. Wenn man am System was ändert, ändert sich auch oft das Verhalten der Geschwindigkeit, sodass man sich erstmal freut, um kurz darauf wieder in die gleichen Probleme zu laufen.

Ich hab zB mal die Syskonnekt Ethernetkarte entfernt und die Asus Onboard benutzt (beides Gigabit). Mit der Onboard gings plötzlich fast 5x so schnell. Bis ich auf die irrwitzige Idee kam einmal digikam zu starten. Dann schlief die Kiste wieder ein.

Ich hab jetzt mal vorübergehend auf 100MB/s umgestellt, bis die Probleme behoben werden. Damit läuft es wie es bei 100MB/s laufen sollte.
 

strikegun

Newbie
genau, ich lass es jetzt auch mit 100mbit/s laufen.
Werde dann wohl meinen server auf Suse10.1 umstellen sobald das gold ist. Eine beta werde ich sicherlich nicht auf produktionsbetrieb laufen lassen.
Laut opensuse.org ist es für 25.4.06 geplant.
 

Yehudi

Guru
Es gibt wohl mehre Geschwindigkeitsbugs in SuSE 10.0, die es vorher nicht gab. Bei USB Festplatten gibt es gegenüber der 9.3 ein Problem mit dem Tempo.
Da bleibt dann wohl nur abzuwarten, bis am 25 .4 bei der Postbote klingelt.
Es ist denoch sehr gut, dass hier jeder mit dem Problem seine Erkenntnisse mitteilt.
 

koala313

Newbie
kleiner nachtrag zur gigabit-problematik:

hab mal die hardware-datenbank von suse durchstöbert und da sieht
es nicht gut für gigabit-realtek oder darauf basierende onboard-lösungen
wie auch mein gigabyte-board aus.
genauer gesagt: beides keine unterstützung!
:cry:
 
Status
Für weitere Antworten geschlossen.
Oben