Server mit Debian gebastelt, kaum Schreiberformance mit SMB

[maxpayne80]

Hi

Also ich versuchs kurz zu machen:

Hab nen Homeserver gebaut, der hat als Board ein Asrock ALiveN7FG-GLAN
mit einer GBit-Schnitstelle.
Darauf läuft die aktuelle Stable von Debian, zunächst mit nem Samba-Server für Dateifreigaben.

Nun das Problem:
Beim Lesen vom Server erreiche ich 90MB/sec, also was die HD hergibt.
Will ich aber was schreiben, dann schwankt das extrem stark und bricht letztlich auf 10-50MBit ein.
Client ist ein Windows - Rechner.

Folgende Beobachttungen habe ich gemacht:
- stelle ich Windows 7 auf Jumbo-Frames (9K mtu) dann steigt die Transferrate auf ~400Mbit an, was erträglich wäre. Aber es muss doch auch normal gehen, zumal beim Lesen der Durchsatz ja stimmt!

Hier nochmal ein ifconfig, bei dem doch einige Fehler auffallen, beim RX:

sparta:~# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 00:19:66:ec:8f:9e  
          inet Adresse:192.168.0.10  Bcast:192.168.0.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:26194184 errors:23654 dropped:0 overruns:0 frame:23654
          TX packets:7376949 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:88757367 (84.6 MiB)  TX bytes:1460951890 (1.3 GiB)
          Interrupt:216 Basisadresse:0x8000

Wie man sieht ist beim TX alles in Ordnung in der Hinsicht.
Wenn ich beim Windows-Client die MTU auf Jumbo-Frame stelle kommen übrigens weit weniger Fehler beim Schreiben hinzu als mit Standard-mtu.

Leider lässt sich bei der NIC auf dem Server die mtu nicht höher stellen:

sparta:~# ifconfig eth0 mtu 3000
SIOCSIFMTU: Das Argument ist ungültig

Noch eine Beobachtung:
Stelle ich am Windows-Client auf 100MBit Full Duplex, dann habe ich vollen Durchsatz in beide Richtungen (100MBit),
kein Paketverlust! Das macht es sehr merkwürdig, zumal die NIC im Server weiter auf 1GBit sein sollte, da Client und Server an nem GBit-Switch hängen.

Hat jemand vielleicht einen Tipp? Oder muss ich mir nun ne PCI-NIC zulegen?

max

 

[Gast07032022]

Hast du vll. schon andere Protokolle als SMB ausprobiert? NFS, ftp o.Ä.?

 

[ThePsycho]

Hmm da wäre der Netzwerkchip (vermutlich Realtek) und der verwendete Treiber interessant.

Ersteres kann man vermutlich mit "lspci" und letzteres mit "lsmod" herausfinden.

Stehen im Syslog (var/log/messages) oder im Samba-Log irgendwelche auffälligen Einträge?

edit: Das hier hab ich noch gefunden und passt wie die Faust aufs Auge: http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2007-10/msg01524.html
Wahrscheinlich mißverstehen sich Switch und Rechner bei auto-negotiation.
Btw: Ich hab nach "linux nic rx erros" gegoogelt.

 

[maxpayne80]

Andere Protokolle habe ich noch nicht versucht, nein. Hab aber noch vor, ftp zu testen.

Im Samba-Log hatte ich gestern / heute morgen einige komische Meldungen.
Die kommen aktuelle aber NICHT mehr, scheinen damit also nichts zu tun zu haben ;(

Spoiler

sparta:/var/log/samba# tail log.__ffff_192.168.0.190
  getpeername failed. Error was Der Socket ist nicht verbunden
  read_socket_with_timeout: client 0.0.0.0 read error = Die Verbindung wurde vom Kommunikationspartner zurückgesetzt.
[2009/11/22 00:29:35,  0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/11/22 00:29:35,  0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Der Socket ist nicht verbunden
  read_socket_with_timeout: client 0.0.0.0 read error = Die Verbindung wurde vom Kommunikationspartner zurückgesetzt.
[2009/11/22 00:29:35,  0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/11/22 00:29:35,  0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Der Socket ist nicht verbunden
  read_socket_with_timeout: client 0.0.0.0 read error = Die Verbindung wurde vom Kommunikationspartner zurückgesetzt.

/var/log/messages zeigt das hier (ich habe das Netzwerkkabel mehrmals gewechselt, daher kommt das imho)

Spoiler

sparta:/var/log/samba# tail /var/log/messages 
Nov 22 10:08:04 sparta kernel: [32928.531402] eth0: link down.
Nov 22 10:08:05 sparta kernel: [32930.107754] eth0: link up.
Nov 22 10:09:35 sparta kernel: [33019.989647] eth0: link down.
Nov 22 10:09:37 sparta kernel: [33021.733857] eth0: link up.
Nov 22 10:11:00 sparta kernel: [33104.540573] eth0: link down.
Nov 22 10:11:02 sparta kernel: [33106.636867] eth0: link up.
Nov 22 10:12:11 sparta kernel: [33175.805149] eth0: link down.
Nov 22 10:12:13 sparta kernel: [33177.754384] eth0: link up.
Nov 22 10:17:58 sparta kernel: [33522.525370] eth0: link down.
Nov 22 10:19:33 sparta kernel: [33617.832559] eth0: link up.

.
EDIT :
.

edit: Das hier hab ich noch gefunden und passt wie die Faust aufs Auge: http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2007-10/msg01524.html
Wahrscheinlich mißverstehen sich Switch und Rechner bei auto-negotiation.
Btw: Ich hab nach "linux nic rx erros" gegoogelt.

Hm ok hört sich interessant an.
Ich kann nur am Switch nix ändern, ist non-managed.

Hmpf
Mal sehen wie weit ich auf Server-Seite komme.

 

[rhHeini]

SMB und Schreiben ist immer langsamer als Lesen. Bei 100 Duplex begrenzt zufälligerweise das Netzwerk, bei 1GB fällt es auf.

Mfg rh

 

[maxpayne80]

Ja gut. Aber warum habe ich bei 100MBit 99% Auslastung, wenn ich dann auf 1GBit stelle aber nur 2-3% (20-30MBit) ?

So einfach ist es - leider - nicht @ rhHeini

 

[Dalai]

IMO sind die Fehler beim RX nicht normal! Prüfe bitte, ob die Karte in Ordnung ist und welcher Treiber verwendet wird.

MfG Dalai

 

[maxpayne80]

Oh man

Scp bring 2600KByte/sec. ... und die CPU dürfte es nicht sein, die bremst. Die ist zwar auf 2x1000MHz runtergetaktet (4850e), aber nur zu 15% Last beim Transfer.

Hier mal "lspci"

00:0a.0 Ethernet controller: nVidia Corporation MCP67 Ethernet (rev a2)

Aus lsmod werde ich nicht schlau, ich poste mal die ganze Ausgabe:

Spoiler

sparta:~# lsmod
Module                  Size  Used by
appletalk              25984  20 
nfsd                  186928  13 
lockd                  54568  1 nfsd
nfs_acl                 2912  1 nfsd
auth_rpcgss            33952  1 nfsd
sunrpc                162528  11 nfsd,lockd,nfs_acl,auth_rpcgss
exportfs                3936  1 nfsd
ipv6                  235396  16 
w83627ehf              17000  0 
hwmon_vid               2720  1 w83627ehf
loop                   12748  0 
sd_mod                 22200  2 
parport_pc             22500  0 
snd_pcm                62660  0 
snd_timer              17800  1 snd_pcm
snd                    45636  2 snd_pcm,snd_timer
soundcore               6368  1 snd
evdev                   8000  0 
parport                30988  1 parport_pc
snd_page_alloc          7816  1 snd_pcm
serio_raw               4740  0 
psmouse                32336  0 
pcspkr                  2432  0 
k8temp                  4064  0 
forcedeth              45072  0 
ahci                   23596  2 
wmi                     6440  0 
ehci_hcd               28428  0 
ohci_hcd               18532  0 
button                  6096  0 
usbcore               118192  3 ehci_hcd,ohci_hcd
ext3                  105576  3 
jbd                    39476  1 ext3
mbcache                 7108  1 ext3
thermal                15228  0 
processor              32576  1 thermal
fan                     4196  0 
thermal_sys            10856  3 thermal,processor,fan
ide_disk               10496  4 
ata_generic             4676  0 
libata                140448  2 ahci,ata_generic
scsi_mod              129548  2 sd_mod,libata
dock                    8304  1 libata
ide_pci_generic         3908  0 [permanent]
amd74xx                 7752  0 [permanent]
ide_core               96168  3 ide_disk,ide_pci_generic,amd74xx

Danke übrigens für die Hilfe bisher

IMO sind die Fehler beim RX nicht normal! Prüfe bitte, ob die Karte in Ordnung ist und welcher Treiber verwendet wird.

MfG Dalai

Wie prüfe ich denn, ob die Karte in Ordnung ist?
Dass beim RX irgendwas faul ist hatte ich ja oben gepostet

 

[hoschi_tux]

Forcedeth sollte hier der NIC Treiber sein.

 

[maxpayne80]

Hm. ok... gibt es da noch andere Treiber, mit denen man das versuchen könnte?

Im luxx meinte jemand, dass diese Realtek-Chips (hier RTL8211CL) unter Linux generell Probleme machen würden.
Aber das kanns ja irgendwie nicht sein... ich meine in Senderichtung habe ich vollen Durchsatz -.-

 

[SnakePlisken]

Mit ethtool kannst Du dem NIC ein bisschen mehr Infos entlocken, und auch einstellen.

 

[maxpayne80]

Ja... ich hab versucht autonegotiation auszuschalten wie weiter oben unter dem einen link da empfohlen wird.
Nur leider passiert da nichts...

Settings for eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 3
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Tja und obwohl es in der help-page so steht funktioniert z.B. dieser Befehl nicht:

sparta:~# ethtool eth0 -s autoneg off
ethtool: bad command line argument(s)
For more information run ethtool -h

 

[SnakePlisken]

ethtool -s eth0 autoneg off

Mit z.B. nttcp kannst Du Netzwerkdurchsatz messen.

 

[maxpayne80]

ok fail -.-

nun kommt das:

sparta:~# ethtool -s eth0 autoneg off
Cannot set new settings: Invalid argument
  not setting autoneg

 

[hoschi_tux]

Versuch es mal mit 0 oder 1 anstatt off.

 

[maxpayne80]

Versuch es mal mit 0 oder 1 anstatt off.

sparta:~# ethtool -s eth0 autoneg 0
ethtool: bad command line argument(s)
For more information run ethtool -h

Bringt auch nichts

Au Mensch echt doof.

Mit fällt ein: das Problem hatte ich auch, als ich die Rechner direkt gekoppelt habe, also ohne Switch. Ist nicht nur eine Fehlkommunikation mit dem Switch, auch mit anderen Rechnern ist das genau so.

 

[Dalai]

Mmh, probier mal die System Rescue CD, um zu prüfen, ob auch dort RX Fehler auftreten.

MfG Dalai

 

[maxpayne80]

Ok das auch noch eine idee. Muss gleich erstmal weg.
Hoffe das ist nicht ein Hardwaredefekt, kein Bock die Kiste wieder zu zerlegen

 

[Ragas]

Vielleicht kommen auch einfach deine Netzwerkkabel nicht ganz mit der hohen Übertragungsrate klar Ich hatte das schonmal bei der Verlegung durch mein Haus, dass das kabel nicht mehr als 10MBit drauf hatte und dann mit 100MBit keinen Connect mehr hergestellt hat und wenn dann mit Exorbitanten Fehlerraten.
Wenn dein Kabel gerade an seine Grenzen stößt, dann könnte es genau so eine Verlangsamung verursachen,denke ich.

 

[maxpayne80]

Vielleicht kommen auch einfach deine Netzwerkkabel nicht ganz mit der hohen Übertragungsrate klar Ich hatte das schonmal bei der Verlegung durch mein Haus, dass das kabel nicht mehr als 10MBit drauf hatte und dann mit 100MBit keinen Connect mehr hergestellt hat und wenn dann mit Exorbitanten Fehlerraten.
Wenn dein Kabel gerade an seine Grenzen stößt, dann könnte es genau so eine Verlangsamung verursachen,denke ich.

Dann ist nur die Frage, warum Senden (Server -> Client) mit über 800MBit funktioniert,
die andere Richtung aber nicht über 70MBit hinauskommt.

Ich hab 2 verschiedene Cat 5e Kabel versucht. Ich kann auch noch ein 3. nehmen, aber irgendwie glaube ich nicht, dass das hilft

Achso:
Ich habs heute morgen - bei nicht geänderter Konfiguration - erlebt, dass eine einzelne große Datei, die ich auf den Server kopierte (~7GB) mit 450MBit rübergeschoben wurden.

Erst DANACH dann wurde es lahm, also ab der 2. Datei...

 

[boidsen]

Das is GENAU das bekannte Linux-Treiber-Problem mancher aktuellen Realtek-NICs - manchmal geht garnix, meistens jedoch treten eben solche "merkwürdigen Erscheinungen" mit Performanceeinbrüchen oder/und Übertragungsfehlern auf.
Abhilfe schafft der Austausch der freien, aber eben reverseengineerten Treiber, gegen die proprietären von Realtek.

 

[ThePsycho]

Ähm - aber wenn ich das jetzt richtig verstanden habe geht es nicht um Realtek, sondern um eine Nvidia.
Leider hab ich selber kein solches Board mehr (ok, eigentlich bin ich froh, aber andere Geschichte) - gibt es noch die Möglichkeite, proprietäre Treiber für seinen Kernel zu kompilieren (Name: nvnet)? Falls ja, kannst du ja mal prüfen, ob das Besserung bringt.

edit: Falls du den Switch dazwischen weglässt, wäre es wichtig, das Verhalten zu prüfen, nachdem bei _beiden_ Rechner autoneg ausgeschalten und die Bandbreite auf 1 GB gesetzt wurde (falls es denn mal klappt).

 

[maxpayne80]

Danke ich werde beide Rechner nun noch einmal ohne switch verbinden.
Zuletzt als ich das tat und den Windows Client fest auf 1Gbit einstellte änderte sich nichts.
Leider lässt sich irgendwie die Autoneg auf dem Server nicht deaktivieren, siehe Post #14 und #16

Ansonsten bleibt mir wohl nichts als die realtek Treiber zu nehmen (wo finde ich die? Bisher nicht erfolgreich gewesen).

Das Board ist übrigens das hier :

http://geizhals.at/deutschland/a431844.html

Und das deutet - anders als die Ausgabe von "lspci" sagt, auf Realtek hin.

Ich finde einfach keinen anderen Treiber für den Netzwerkchip, auch nicht bei Realtek
Hat jemand ne Idee wo man den finden kann?

//Edit laut diesem Thread (letzter Post) scheint für 1000BaseT Autoneg obligatorisch zu sein.
Woher der Autor die Info hat weiß ich aber nicht.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1258928865301+28353475&threadId=979491

 

[boidsen]

Stimmt - für die 82er gibts da noch nix. Mal den für die 81er probieren - ansonsten halt doch ne Karte einbauen...

 

[maxpayne80]

Hm wie binde ich unter linux nen anderen Treiber ein? Hab das ewig nicht mehr gemacht