Server mit Debian gebastelt, kaum Schreiberformance mit SMB

[maxpayne80]

Was sagt "ethtool -S ethX"

lg
__tom

Ah sorry

sparta:/home/marcelk# ethtool -S eth0
NIC statistics:
     tx_bytes: 1358292004
     tx_zero_rexmt: 2717689
     tx_one_rexmt: 0
     tx_many_rexmt: 0
     tx_late_collision: 0
     tx_fifo_errors: 0
     tx_carrier_errors: 0
     tx_excess_deferral: 0
     tx_retry_error: 0
     rx_frame_error: 0
     rx_extra_byte: 0
     rx_late_collision: 0
     rx_runt: 0
     rx_frame_too_long: 0
     rx_over_errors: 12967
     rx_crc_errors: 245
     rx_frame_align_error: 0
     rx_length_error: 0
     rx_unicast: 11016483
     rx_multicast: 9773
     rx_broadcast: 5093
     rx_packets: 11031349
     rx_errors_total: 13212
     tx_errors_total: 0
     tx_deferral: 0
     tx_packets: 2717689
     rx_bytes: 16473403338
     tx_pause: 31394
     rx_pause: 694
     rx_drop_frame: 709
     tx_unicast: 113824
     tx_multicast: 41376
     tx_broadcast: 310742229246

 

[tomturbo]

CRC Errors sind Checksummenfehler und deuten auf Kabel oä. hin.

RX_OVER_ERRORS kommen von Pufferüberläufen dh. Deine Maschine kann die Pakete nicht rechtzeitig von der Karte entgegen nehmen.

Stelle mal folgende Werte in der sysctl ein (/etc/sysctl.conf)

net.ipv4.tcp_tw_reuse = 1
net.core.wmem_max = 8738140
net.core.rmem_max = 8738140
net.ipv4.tcp_rmem = 10240 873814 8738140
net.ipv4.tcp_wmem = 10240 873814 8738140
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 32768 64000
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_low_latency = 1
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.netfilter.nf_conntrack_acct = 1
net.ipv4.tcp_synack_retries = 2

Um auszuschließen dass es am Netzwerkstack liegt.
Es kann nämlich durchaus sein, dass der NIC gar nicht in der Lage ist den Verkehr zu bewältigen.

lg
__tom

 

[maxpayne80]

CRC Errors sind Checksummenfehler und deuten auf Kabel oä. hin.

RX_OVER_ERRORS kommen von Pufferüberläufen dh. Deine Maschine kann die Pakete nicht rechtzeitig von der Karte entgegen nehmen.

Stelle mal folgende Werte in der sysctl ein (/etc/sysctl.conf)


Um auszuschließen dass es am Netzwerkstack liegt.
Es kann nämlich durchaus sein, dass der NIC gar nicht in der Lage ist den Verkehr zu bewältigen.

lg
__tom

Oh das sieht doch etwas "weitgehender" aus
Habs mal reinkopiert in die Datei und den Rechner neu gestartet,
geändert hat sich leider nichts

 

[tomturbo]

Dann sieht es für mich so aus als ob die Netzwerkkarte die Last nicht packt.
Bzw. dass der Bus an dem die Karte hängt den traffic nicht los wird und dadurch overrun errors produziert werden.
Die overrun errors resultieren dann in retransmit's welche den Durchsatz dann total einbrechen lassen.

Um eine andere Karte wirst Du wohl nicht herum kommen.

lg
__tom

 

[maxpayne80]

Hm, danke auf jeden Fall für die Idee.

Ich werde demnächst mal mit einem Windows-System auf der Hardware testen, wie es da aussieht.
Nach dem was du sagst dürfte es ja dort ähnlich aussehen.

Muss wohl - zum Preis eines höheren Strombedarfs - eine Intel GBit NIC rein.

Dauerhaft Windows draufhaben will ich nicht, soll schon ein Debian Server sein

 

[PuckPoltergeist]

Noch eine Idee zum Treiber. Du hattest ja den Kernel nun selber gebaut. Hast du den forcedeth-Treiber mit oder ohne NAPI konfiguriert?

 

[maxpayne80]

Noch eine Idee zum Treiber. Du hattest ja den Kernel nun selber gebaut. Hast du den forcedeth-Treiber mit oder ohne NAPI konfiguriert?

Hmmm an so eine Option kann ich mich nun garnicht erinnert.
Finde ich das in der .config-Datei im Kernel-Sourceverzeichnis?

 

[SnakePlisken]

geh in menuconfig mach 'umschalt+7' gib napi ein, dann weiter unten siehst Du das, und dann probier mal:

 

[Radditz]

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

Den Treiber suchen, herunterladen und entpacken. Dort dann die Readme-Datei lesen, die in 98% der Fälle schlicht und ergreifend von dir verlangen wird, ein "make" mit anschließendem "make install" auszuführen. Evtl. stehen in der Datei noch Sonderanmerkungen zu einzelnen Distributionen oder zum Einbinden der Treiber.

Edit: Oh lol, wir sind ja schon auf Seite 4. Ich dachte bei Seite 1 sei Schluss. Pardon, bin schon ruhig. xD

 

[maxpayne80]

Den Treiber suchen, herunterladen und entpacken. Dort dann die Readme-Datei lesen, die in 98% der Fälle schlicht und ergreifend von dir verlangen wird, ein "make" mit anschließendem "make install" auszuführen. Evtl. stehen in der Datei noch Sonderanmerkungen zu einzelnen Distributionen oder zum Einbinden der Treiber.

Edit: Oh lol, wir sind ja schon auf Seite 4. Ich dachte bei Seite 1 sei Schluss. Pardon, bin schon ruhig. xD

Najo ich bin für jede Hilfe dankbar,
denn bisher hat nichts was gebracht,
weder ein ganz aktueller Vanilla Kernel noch das ändern diverser Parameter wie send/receive buffer size etc.

Hast du nen Link wo man vllt für den gannten Realtek Chip Linux Treiber bekommt?
Habe bisher nix gefunden ...

 

[PuckPoltergeist]

Hast du nen Link wo man vllt für den gannten Realtek Chip Linux Treiber bekommt?
Habe bisher nix gefunden ...

Der ist in den Kernel-Sourcen enthalten. Es gibt keinen 3rd-party Treiber.

 

[Dalai]

@maxpayne80: Hast du denn mal die Karte getauscht? Viele Fehlerquellen bleiben ja nicht mehr übrig und IMO ist diese am schnellsten ausgeschlossen (oder eben verifiziert).

MfG Dalai

 

[maxpayne80]

@maxpayne80: Hast du denn mal die Karte getauscht? Viele Fehlerquellen bleiben ja nicht mehr übrig und IMO ist diese am schnellsten ausgeschlossen (oder eben verifiziert).

MfG Dalai

Nein bisher nicht, habe wenig Zeit (Diplomarbeit vor Weihnachten noch abgeben ).

Ich werde dann wohl ne Intel 1GBit PCIe - Karte einbauen. Braucht dann etwas mehr Strom, aber dafür sollte das denke ich dann laufen.
Gedachte habe ich - oh Wunder - an die hier:


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