Debian-Server: Transferraten im kB-Bereich

iYassin

iYassin

Well-known member
Themenstarter
Registriert
15 Mai 2009
Beiträge
10.197
Nach etwas Arbeit läuft nun endlich mein neuer Server (FSC Futro S400, AMD Geode NX-1500 @1GHz, 256 MB RAM, 16 GB CF (133x), Debian 6.0.4) - wirklich zufrieden bin ich damit allerdings noch nicht, denn man kann ihn nicht wirklich benutzen. Die Transferraten beim Lesen und Schreiben liegen zwischen 20 und 40 kB/s. :facepalm:
Was ich im Grunde genommen macht habe... Debian 6.0.4 ohne GUI von CD installiert, Samba installiert und die smb.conf vom alten Server übertragen. Die HDDs sind wie bisher per USB 2.0 angebunden, der Server hängt per 100 MBit/s-Ethernet am Router, meine Notebooks sind per 802.11n-WLAN angebunden.

Was kann denn die Ursache für derart langsame Transferraten sein? Klar, die CF-Karte ist als 133x-Modell nicht die schnellste, aber für ein Debian ohne GUI sollte es doch reichen, v.a. wenn nicht auf die CF selbst zugegriffen wird, oder? Und an der sonstigen Hardware sollte es ja auch nicht liegen - mein alter Server, eine Seagate Dockstar mit 1 GHZ-ARM-CPU und 128 MB RAM lief (mit Debian 6.0 testing) von einem normalen USB-Stick, da waren problemlos 25 MB/s möglich... kann es vielleicht doch irgendwas softwareseitiges sein?

Vielen Dank schonmal für Eure Hilfe!

Viele Grüße,

iYassin
 
Die CPU idlet.

Meine HDDs sind mit ext4 formatiert.

iostat habe ich noch nicht ausprobiert, installiere ich gleich mal.

Ping habe ich gerade mal getestet:
- Vom MBP zum Server (per 802.11n-WLAN, maximal 270 MBit/s-Link, aktuell 144 MBit/s-Link zum Router) schwankt es zwischen 4 ms und 56 ms, kein Paketverlust.
- Vom MBP zum Router zwischen 3 und 70 ms, kein Paketverlust.
- Vom Server zum MBP zwischen 1 ms und 672 ms, 4% Paketverlust.
- Vom Server zum Router zwischen 0,4 ms und 1 ms, kein Paketverlust.

Lange Ping-Zeiten und Paketverlust per WLAN habe ich in letzter Zeit mit allen Geräten, die 802.11n unterstützen. Ich befürchte daher, dass der Router defekt ist. Komisch ist aber, dass es mit dem alten Server dennoch auch nach dem Auftreten des Defekts vor etwa einem Vierteljahr einwandfrei funktioniert hat.

Ich habe übrigens gerade mal firmware-realtek installiert - jetzt ist der FTP-Traffic etwas stabiler bei 800 kB/s und geht ab und zu sogar auf 2 MB/s hoch. Jetzt probiere ich mal das hier: http://unixblogger.wordpress.com/2011/10/18/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/
 
OK also wenigstens ein kleines Licht am Tunnelende.
4% sind eigentlich schon zuviel Verluste wenn nur ein Router / Switch dazwischen ist.
Versuch auch mal die Autonegotiation auszuschalten. Wenn Switch und Karte sich nicht vertragen, wird ständig neuversucht die Geschwindigkeit einzustellen, was zu Verlusten als eben auch schlechter Performance führen kann. Hatte das auch schonmal mit einem defekten Port an einem Cisco.
ethtool ist dann Dein Freund dafür.
Ansonsten wirklich mal den Original Treiber nutzen, auch wenns compilieren und Co. heißt.
Sollte aber fix gehen.
 
"Fix" auf einem Geode NX-1500 ist Ansichtssache :D Er installiert gerade die build-essentials. :thumbsup:
Ich packe dann mal den Treiber drauf - wenn es dann nicht geht, mache ich mich an die Negotiation.
 
Kannst ja auch den compile auf einer anderen Maschine machen und baust Dir einfach das Debian Paket. x86er und gut ist, sollte doch auch das MBP in einer virtuellen Maschine können ?
 
Stimmt eigentlich... naja, jetzt ist er schon dabei ;)
 
Das wäre auch eine Erklärung warum ich unter Windows keine Probleme mit dem Realtek Chip hab...
Wenn das alles bei dir nichts nutzt hau ich auch mal Debian auf einen Stick (eine normale Version mit Desktop sollte es doch auch tun oder?) und probiere mal ob ich ähnlich schlechte Werte bekomme.
 
Mist ich hab nur 64 bit Isos von Debian ^^
Das kann ein bisschen dauern bis ich das runtergeladen habe...

Kann ich das auch mit Lubuntu o.Ä. testen oder geht dann die Vergleichsmöglichkeit flöten?
 
Vergleich geht flöten, da Ubuntu einen anderen Kernel hat und die Firmware auch dabei ist. Debian Regeln sind da recht steif, dafür aber auch stable.
Aber die Netinstall sollte doch schnell gehen, sind nur ein paar MB und Du musst ja nur starten können, eine Debian ohne GUI ist auch nur knapp 300-400MB groß, ok kaum Services und so aber dafür schnell installiert und geladen, sehr viel mehr habe ich selten bei Servern gebraucht, bis auf die gewünschten Dienste eben :rolleyes:
Um das Problem von iYassin zu lokalisieren sollte aber dann wirklich das gleiche Debian genutzt werden.
 
So, bootet wieder - geht aber nicht ins Netzwerk. Ich logge mich dann mal mit angeschlossenem Monitor ein und prüfe, woran das liegt...
 
KLingt nach fehlerhaften laden vom Realtek modul, oder beide Module werden geladen und streiten sich um die Kontrolle der Karte.
Blacklist vom Debian Modul hast Du ja nach Anleitung gemacht, dann könnten noch die installierten Firmware Dateien für Probleme sorgen. Da ich das neue Modul nicht kenne, kann es sein das es die auch laden will und damit Probleme hat.
Mit dmesg kannst Du die Boot Nachrichten einlesen bzw. unter /var/log/dmesg falls schon zuviele Nachrichten durch sind, wird mit dem Befehl dmesg nicht mehr alle angezeigt.
 
So, hier schon mal Screenshots vom test Windows7 auf Windows7

einmal upload (schreiben auf den ThinClient)
Unbenan2nt.JPG
und einmal download (laden vom ThinClient)
Unbe222nannt.JPG
 
Alles klar, hab die Firmware mal deinstalliert, er rebootet jetzt. Im dmesg-Output steht leider überhaupt nichts zum Thema Netzwerkkarte...
@Thomebau: WANT! :D

EDIT: So, das Realtek-Modul ist offenbar schonmal nicht korrupt - ich kann es mit modprobe entladen und auch wieder laden... allerdings funktioniert es nicht. :D Im ifconfig ist eth0 nun auch verschwunden. Überall steht auch, dass jetzt nach der Installation im Output von lspci -v ein Hinweis auf r8168 stehen müsste - das ist aber nicht der Fall...
 
Zuletzt bearbeitet:
Ich würde jederzeit tauschen gegen schnelleres Internet ^^
Das kleinste Live Iso (~800MB) brauch zur Zeit laut uTorrent ~11,5h :crying:

Und beim Thinclient limitiert momentan die eingebaute HDD, die ist da absolut der Flaschenhals.
 
Jupp kann sein, Debian merkt sich die MAC Adresse und das Modul dazu.
Beim Laden / Entladen sollten schon Meldungen bei dmesg auftauchen. Sollte sowas stehen wie modul xxx geladen und die Parameter mit den geladen wird.
Versuch mit: ifup eth0 bzw ifup eth1 mal Debian dazuzubringen die Karte mit IP zustarten. Notfalls auch mit ifconfig direkt und alle notwendigen Parameter.

@thomebau: Ja ja das hochgelobte Breitband für alle
 
Okay, dann wird es doch nicht geladen ;) Dementsprechende Meldungen sind nicht vorhanden - und ifup geht nicht, solange r8168 geladen ist. Erst wenn ich r8169 lade, kann ich die Karte einschalten.

Kann ich das Teil falsch installiert haben? Eigentlich hab ich genau die Anleitung befolgt...
 
Die Anleitung ist recht deutlich, die Frage ist nur welche Karte hast Du ?
Ausgabe lspci wäre hilfreich. Denn auf der Download Seite von Realtek, steht nichts von 8169, kann also sein das der Treiber einfach nicht Deine Karte ansprechen will.
Du kannst ja auch mal via backports einen 3.x Kernel installieren, nutze zwar auf meinem Server auch Debian und eine Realtek, nur habe ich die Probleme nicht, kopieren mit ca 70-80MB/s. Ist aber auch ein Debian/testing mit 3.1.0 Kernel.
 
lspci:
Code: 
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
    Subsystem: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet
    Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 15
    I/O ports at e400 [size=256]
    Memory at ec122000 (32-bit, non-prefetchable) [size=256]
    [virtual] Expansion ROM at 10000000 [disabled] [size=128K]
    Capabilities: [dc] Power Management version 2
    Kernel driver in use: r8169

Jetzt taucht r8169 komischerweise als "Kernel driver in use" auf... wenn da nur r8168 stünde :D Der Treiber soll laut Google-Ergebnissen auch für die RTL8110SC/8169SC passen.
 
dann entlade doch mal den treiber und lade den r8168
zwei treiber eine karte kann nur schief gehen.
modprobe -r r8169 && modprobe r8168

Danach sollte etwas via dmesg auftauchen
Ach j geht aber nicht via ssh :facepalm:
 
Hatte gerade manuell den r8169 geladen (der ist ja eigentlich blacklisted), um per SSH lspci kopieren zu können und Pakete zu laden ;) Ich versuche gerade mal ein Kernel-Update über backports. Ich schätze mal, den Treiber muss ich dann auch neu installieren, da ich ihn ja in den drivers-Ordner des 2.6er-Kernels geladen habe, oder?

Ich habe auch schon versucht, manuell den r8168 zu laden - es tritt zwar kein Fehler auf, aber im dmesg-Output taucht leider auch nichts auf.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben