# Netzwerk langsam - wie Diagnose?

## Caipi

Da ich in einem anderen Forum seit ner Woche keine Antwort bekomme, aber wirklich absolut ratlos bin, versuche ich es hier einmal:

hab hier auf einem Opteron-Server ein dickes Datenüberdragungsproblem. Das RAID5 schafft laut hdparm im Durchschnitt 70MB/s. Wenn ich per Samba/NFS/FTP auf den Rechner zugreife (getestet mit OnBoard- und Intel-Server-Netzwerkkarte) bekomme ich beim Downstream am Client (getestet mit versch. Macs und PCs über Gigabit) ca. 10MB/s und beim Upstream sogar nur 1,5MB/s. Ausserdem ist besonders beim Upstream zu erkennen das es Verbindungsabbrüche ohne ende gibt, d.h. z.B. in der Aktivitäts-Anzeige am Mac habe ich eine Sekunde 100% auslastung dann zwei Sekunden 0% ... manchmal mehr manchmal weniger. Wenn es zu sieben Sekunden Unterbrechungen kommt geben die Macs sogar mit einem timeout die Verbindung komplett auf. Virenscanner habe ich schon deinstalliert. Firewall ist auch nicht gestartet. Netzwerk als solches ist schnell, Verbindung zwischen zwei Clients geht ohne Probleme.

habe auch auf einem andern AMD64-System ein gentoo installiert und mal einen genkernel verwendet, sehr faszinierend ist das ich auch hier mit gbit beim upstream haenger ohne ende habe und es deshalb langsamer als mit 100mbit ist. drossle ich das ganze auf 100mbit bekomme ich 10MB/s (up und down) hin, also wirklich gut.

Taugt gentoo einfach nix was server und netzwerk angeht? weil auf 2 systemen die gleichen phänomene... da ist doch was faul.

----------

## think4urs11

Ich würde als allererstes mal auf sämtlichen beteiligten Geräten (Server/Client/Switches) die Einstellungen bzgl. Autonegotiation checken.

a) ob überhaupt jeweils beide Enden eines Kabels identisch konfiguriert sind (bei fixer Konfig)

b) ob (bei 'auto' Konfig) auf beiden Seiten jedes Kabels die Geräte jeweils der gleichen Meinung sind was ausgehandelt wurde für Speed/Duplex

Außerdem würde ich mal checken ob vielleicht das Raid und die Netzwerkkarte am gleichen PCI-Bus hängen und sich gegenseitig auf die Füße steigen.

----------

## Caipi

Alles steht auf Fullduplex und 1000Mbit der switch zeigt das auch an. Netzwerkkabel wurden schon getauscht, sind jetzt neue Cat6-Patchkabel. Da ich einmal mit der internen und einmal mit einer pci-x Netzwerkkarte getestet habe sollte sich das mit dem PCI-Bus auch erledigen, oder? Werde mir wohl man ne SUSE-CD schnappen muessen und das damit probieren, weiss naemlich nicht mehr weiter. Was ich noch nicht testen konnte ist eine Direktverbindung mit crossover-Kabel.

----------

## theche

GEthernet braucht imho kein crosskabel, sie schalten automatisch um. Kannst normale Patchkabel verwenden.

----------

## think4urs11

 *Caipi wrote:*   

> Da ich einmal mit der internen und einmal mit einer pci-x Netzwerkkarte getestet habe sollte sich das mit dem PCI-Bus auch erledigen, oder?

 

Nicht unbedingt; kommt darauf an wie das Board aufgebaut ist.

Festplatten-DMA ist aktiv?

Errors sind keine auf den Interfaces zu sehen?

Wie sind die Werte bei einem reinen Netzwerkbench, d.h. ohne jegliches Platten-IO (netperf und co)?

----------

## toskala

ich hatte so ein problem mal an einem hp procurve switch weil da die ganzen traffic analyzer auf den ports angeschaltet waren. als ich das ganze port/traffic monitoring auf dem switch abgestellt hatte gings dann auch wirklich schnell.

zudem hatte ich so einen ähnlichen ärger mal mit einem bestimmten 3com chipsatz auf diversen 100mbit karten. die funktionierten nie wirklich unter linux, als ich die karte dann tauschte gegen eine andere war alles super, was ich damit sagen will: kannst du testweise irgendwo kurzfristig eine gbit ethernet karte herkriegen und mit der testen?

dann kommt die frage nach den kabeln. sind die strapaziert worden? knicke, brüche, ähnliches?

hmm, anderes was mir einfiele wurde schon gesagt.

edit: ups, vergiss das mit den kabeln, das hattest du schon  :Smile: 

----------

## think4urs11

 *toskala wrote:*   

> kannst du testweise irgendwo kurzfristig eine gbit ethernet karte herkriegen und mit der testen?

 

Hat er doch schon probiert, und Intelkarten sind nun wirklich nicht schlecht.

----------

## toskala

huch, das hab ich überlesen... is schon irgendwie spät. schuldigung

----------

## Caipi

 *Think4UrS11 wrote:*   

> 
> 
> Nicht unbedingt; kommt darauf an wie das Board aufgebaut ist.
> 
> 

 

Das kann ich erst in den Weihnachtsferien testen, da sind gerade noch Daten drauf und einfach so den 3Ware umstecken ist mir zu riskant. Mal schauen ob ich dazu was im Handbuch finde dann kann ich mir das ggf. sparen.

 *Think4UrS11 wrote:*   

> 
> 
> Festplatten-DMA ist aktiv?
> 
> 

 

jep

 *Think4UrS11 wrote:*   

> 
> 
> Errors sind keine auf den Interfaces zu sehen?
> 
> 

 

Nein, gar nix der Server läuft eigentlich super, bis auf das NW.

 *Think4UrS11 wrote:*   

> 
> 
> Wie sind die Werte bei einem reinen Netzwerkbench, d.h. ohne jegliches Platten-IO (netperf und co)?
> 
> 

 

Werde ich am Donnerstag testen, vorher leider keine Zeit. Wobei die Platten beim Serverinternen kopieren schnell sind.

 *toskala wrote:*   

> 
> 
> ich hatte so ein problem mal an einem hp procurve switch weil da die ganzen traffic analyzer auf den ports angeschaltet waren. als ich das ganze port/traffic monitoring auf dem switch abgestellt hatte gings dann auch wirklich schnell. 
> 
> 

 

habe hier leider keine managed switches, sollte es also nicht sein.

 *teche wrote:*   

> 
> 
> GEthernet braucht imho kein crosskabel, sie schalten automatisch um. Kannst normale Patchkabel verwenden.
> 
> 

 

werde ich dann auch mal am Donnerstag probieren.

Was ich schon sagen kann, ist dass es doch nicht am gentoo liegt (hab ich auch nicht wirklich geglaubt  :Wink: ) ich habe auf nem anderen rechner kurz ein kubuntu geschoben welches die gleichen probleme bereitet, wenn ich es mir recht überlege kann es dann ja auch nicht am pci-bus liegen, denn das ist sicher ein anderer  :Wink:  Wobei auf dem kubuntu-System noch ein Windows ist welches bei Freigaben nicht so mucken macht, und das spricht wiederum gegen fehlerhafte Switches oder NW-kabel/-stecker. Ist schon ganz schön komisch die Sache.

Vielen Dank schon mal für die Tipps!

----------

## dakjo

Mal ganz einfach angefangen.

Was sagt dir ein "Auf einem Client" ping -c100 <dein server>?

Gibt es da verzögerungen bzw. paket lose?

----------

## petter_r

Du sagst, du hast keinen managed Switch, aber das kann ich nicht ganz glauben. Ich denke mal jeder Switch hat ein management interface. Vor allem wenn es ein Gbit Switch ist. Kannst du also mal da rein schauen, ob du auf den Leitungen Collisions hast? Sonst würde ich mal mit Ethereal schauen, was da läuft.

Grüße

Ralf

----------

## twam

 *petter_r wrote:*   

> Du sagst, du hast keinen managed Switch, aber das kann ich nicht ganz glauben. Ich denke mal jeder Switch hat ein management interface. Vor allem wenn es ein Gbit Switch ist. Kannst du also mal da rein schauen, ob du auf den Leitungen Collisions hast? Sonst würde ich mal mit Ethereal schauen, was da läuft.
> 
> Grüße
> 
> Ralf

 

Ich hab auch mehrere GBit-Switche ohne Management. Die bekommst du ja schon bei jedem Media Markt & Co für fast nix und da is sicher kein Management drin (wenn überhaupt ne gescheite Backplane)

----------

## gerry

Was sagen die Logs auf dem Server?

Sind da irgendwelche Fehler / Warnungen drin, insbesondere in den Samba Logs?

Kernel schon mal selber gebaut?

Hab ganz am Anfang von genkernel das mal probiert, seither bau ich wieder selber.

----------

## sevo

Bitte erst einmal die Direktverbindung testen, um ein Switch-Problem auszuschließen! Und wenn es an letzterem hängt, mal den Switch einige Minuten stromlos schalten - solche billigen Teile vergessen mitunter alte Verkabelungen nicht durch bloßes umstecken.

Gruß Sevo

----------

## Caipi

Leider nix, auch mit direkter Verbindung das absolut gleiche Bild. Download von gentoo-server schnell (4GB in knapp 1,40min), upload langsam (4GB in 10,20min) ich schnall es nicht.

netperf konnte ich leider noch nicht machen, weil es das unter osx nicht gibt. muss mal schauen das auf den kubunt-rechner drauf zu hauen.

----------

## new_nOOb

hmm.. und ich dachte schon ich wäre der einzige mit dem problem. habe auch ein raid5 mit aes verschlüsselung auf einem amd64system mit einem onboard realtek gb netzwerkkarte. datentransfer innerhalb des servers geht mit ca 20-30mb sobald ich aber vom windows client per samba was auf den gentoo rechner schieben möchte freue ich mich über 3-4mb beim lesen sind es dann aber ca 17mb

----------

## Caipi

AES-Verschlüsselung... hab ich nicht, oder nicht das ich wüsste.

----------

## m.b.j.

Bei mir siehts ähnlich aus, auf von einem hardened amd64 (32-bit mode) hab ich auf einer 100mbit karte ~5MB download und max 400K!!!!! uplaod, hab schon viel Probert hat aber nix geholfen  :Sad: 

(Lösungsansätze wie oben beschrieben sind alle durchgeführt)

----------

## Caipi

wenn ich auf 100Mbit fullduplex drossle, komme ich hoch und runter fast immer auf 10,5MB/s das rockt also nur das gigbit nicht.

----------

## new_nOOb

@Caipi hab das mal auch ausprobiert auf 100mbit fullduplex und kann deine beobachtungen leider auch nachvollziehen. aber kann doch wohl nicht sein das linux nicht mit ner gigabit netzwerkkarte klar kommt also das darfst ja dann echt niemand erzählen? da wir ja verschiedene modelle haben kann man es ja nicht auf die karte schiebe.

----------

## Caipi

Ja! Vorallem hab ich hier nen Server mit ner 100Euro PCI-X Intel-NW-Karte und nem 3Ware 9500s-12, damit das mit den Daten auch schön flutscht, aber so wie das jetzt aussieht haette ich auch nen 600 Euro Dell-Rechner mit nen paar HDs ausruesten koennen und WinXp-Pro  :Sad: 

Aber ich bin immer noch zuversichtlich, dass es bald funktioniert.

----------

## new_nOOb

wenn du ne lösung findest bitte hier posten  :Wink: 

----------

## Hibbelharry

Ich habe dasselbe Problem mit einer Gentoo Kiste bei der Arbeit. Dort habe ich aber eine kuriose Beobachtung beim Transfer bei Samba gemacht. Kopier ich Daten normal über den Windoze Explorer auf die Kiste ist der Upload langsam. Teste ich das mit Total Copy ist der Upload um ein vielfaches schneller. Total Copy ist ein kleines Helferlein bei Smb Dateikopien. Wer die Zeit und Mittel und das Problem hat möge das bei sich mal ausprobieren. Das löst zwar das generelle Problem noch nicht aber das Ergebnis würde mich wirklich mal interessieren. 

Grüz

Hibbelharry

----------

## Caipi

Da ich das Problem weiter eingrenzen muss und ausserdem unbedingt eine Lösung benötige, werde ich meine Tests fortsetzen. Als nächstes werde ich auf dem Testrechner mit dem ich überprüft habe ob es ggf. an der Hardware im Server hängt, ein 32bit gentoo installieren, da es ja jetzt schon ein paar Aussagen gab, dass es bei 64bit-Systemen auch bei anderen auftritt.

werde mich wieder melden...

----------

## Hibbelharry

*bump*

neue erkenntnisse ?

----------

## Caipi

So brannt aktuell (vor 20min getestet) Habe jetzt ein 32bit-gentoo auf dem Athlon64 Testrechner. Connect via smb, mit gleichem Ergebnis -> 1Gbit - Downstream gut - Upstream schlecht -- 100Mbit - Downstream und Upstream gut.

Kann das an den Treibern liegen? Aber eigentlich sollten sich die 32bit doch von den 64bit-Treibern unterscheiden auch wenn der selbe Prozi verwendung findet!?

----------

## manuels

hast du eingentlich mal net-analyzer/netio ausprobiert...

nur so ein gedanke...

----------

## Haldir

Da Caipis Posts etwas wirr sind:

1.) Du hast zwei unterschiedliche Systeme, unterschiedliche Motherboards, die beide das gleiche Problem zeigen?

2.) Dein Testsystem hast du ohne weitere PCI-X Karten getestet (effektiv komplett leer) (also nur mit deinem GBit Controller)?

Teste das ganze mal mit netio, damit misst du dann den eigentlich Packetdurchsatz.

Die Standardfehler sind:

1.) Onboard Netzwerkkarte shared sich Interrupt mit HDD Controller (steht in der Anleitung, welche Slots mit welchen Onboard Komponenten geshared sind)

2.) HW Checksum Offloading bzw. NAPI 

Wegen HW Checksum Offloading:

emerge ethtool

---------------------------------------------------------

ethtool -k eth0:

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp segmentation offload: on

---------------------------------------------------------

ethtool -S eth0

Da sollten insb. bei den Errors nix stehen

---------------------------------------------------------

ethtool -a eth0

Pause parameters for eth0:

Autonegotiate:  on

RX:             off

TX:             off

---------------------------------------------------------

ethtool -d eth0

insb.  Receive buffer size:  schauen.

----------

## Caipi

Sorry für die wirren Kommentar, habe mir aber eigentlich mühe gegeben so viel Infos wie möglich zu geben.

Erst mal was ich auf die schnelle sagen kann:

Zu 1:

Einmal ist es der Server  -> mit einem Opteron auf einem Tyan K8S Pro (Onboard und PCI-X Netzwerkkarte)

das andere ist eigentlich ein Client den ich nur zu testzwecken zum Testserver  gemacht habe -> Athlon64 auf nforce4 (Onboard Netzwerkkarte)

Zu 2:

Im Server befindet sich neben der PCI-X Netzwerkkarte noch eine 3ware 9500-12 SATA-Raid-Karte

Im Testserver befindet sich ein AGP-Grafikkarte und eine PCI Fire-Wire-Karte

Zu den Standardfehlern (alles Server)

1.) Um Konflikte zu verhindern habe ich alles Onboard was nicht benötigt wird über das Bios Disabled (SATA, Sound, Serial-/Parellel-Port). Der 3ware ist auf PCI-X Bridge B, die Netzwerkkarte ist auf PCI-X Bridge A, leider kann ich dem Handbuch nicht definitiv entnehmen auf was die Onboard Netzwerkkarten liegen, jedoch steht hier bei einem Jumper:

 *Quote:*   

> 
> 
> Sets PCI-X Bridge A (PCI 3 & PCI 4 & BCM5704) to operate at a maximum 66MHz
> 
> 

 

-> das sollte ja heissen, dass der BCM5704 mit an der A liegt, also nicht auf der selben Bridge wie der 3ware

2.) Auf dem Server

 *Quote:*   

> 
> 
> server user_installer # ethtool -k eth0
> 
> Offload parameters for eth0:
> ...

 

Bei "ethtool -d eth0" kommen bei mir rund 33000 Zeilen in der Art von:

 *Quote:*   

> 
> 
> 00      0xe4
> 
> 01      0x14
> ...

 

Ein paar sachen von ethtool sind anders.

----------

## Haldir

Hmm, insb. die Sachen wie rx_64_or_less_octet_packets: 11176744 

irritieren mich:

rx_xon_pause_rcvd: 5581272 

rx_xoff_pause_rcvd: 5581272 

dürfte nie kommen afaik:

probier mal

ethtool -A eth0 rx off

ethtool -A eth0 tx off

Pause Frames sind eigentlich nur dafür da damit man Flow Control, also Bandbreiten management betreiben kann, normalerweise sollte das Aus sein, wenn ich mir dann anschaue wieviel Pause Frames du kriegst, sieht es für mich so aus als würde ein Gerät bei dir im Netzwerk Bandbreite drosseln  :Wink: 

obs dann besser geht

rx_threshold_hit: 18630677  ist auch sehr komisch

Was ich so sehe: deine Karte kriegt sehr viele extrem kurze Pakete (MTU size falsch oder fragmented) ?

Was ich so sehe: Xon/Xoff pause sollte afaik für tx/rx immer off sein

Meine beste Idee ist wohl in einem der Linux Network mailinglisten mit der -S eth0 ausgabe mal nachfragen.

(btw mein output sieht so aus)

NIC statistics:

     rx_packets: 4006670

     tx_packets: 4776684

     rx_bytes: 2198841964

     tx_bytes: 207182075

     rx_errors: 0

     tx_errors: 0

     rx_dropped: 0

     tx_dropped: 0

     multicast: 0

     collisions: 0

     rx_length_errors: 0

     rx_over_errors: 0

     rx_crc_errors: 0

     rx_frame_errors: 0

     rx_fifo_errors: 0

     rx_no_buffer_count: 0

     rx_missed_errors: 0

     tx_aborted_errors: 0

     tx_carrier_errors: 0

     tx_fifo_errors: 0

     tx_heartbeat_errors: 0

     tx_window_errors: 0

     tx_abort_late_coll: 0

     tx_deferred_ok: 0

     tx_single_coll_ok: 0

     tx_multi_coll_ok: 0

     rx_long_length_errors: 0

     rx_short_length_errors: 0

     rx_align_errors: 0

     tx_tcp_seg_good: 885291

     tx_tcp_seg_failed: 0

     rx_flow_control_xon: 0

     rx_flow_control_xoff: 0

     tx_flow_control_xon: 0

     tx_flow_control_xoff: 0

     rx_long_byte_count: 2198841964

     rx_csum_offload_good: 3985853

     rx_csum_offload_errors: 0

----------

## Caipi

 :Mr. Green:  Es funktioniert, jetzt soweit. Ich habe bei einem 7Gig-File Upload und Download etwas über 4min. Nicht super schnell (29MB/s) aber schon mal ein Anfang, dadurch das es in beide Richtungen gleich schnell funktioniert.

Die Lösung kam von Haldir -> VIELEN DANK!!

 *Quote:*   

> 
> 
> ethtool -A eth0 rx off
> 
> ethtool -A eth0 tx off
> ...

 

Werde es jetzt noch mal ne Woche testen und beobachten und dann noch mal schreiben ob es auch dauerhaft läuft.

----------

## Haldir

Du kannst noch probieren:

ethtool -K tso on

und mit den Ring settings spielen (ethtool -g eth0).

Man kann da noch viel optimieren denk ich.

----------

## Caipi

Vielen Dank! Werde ich machen. Eine kleine Frage haette ich noch. Was ist denn genau TX und RX? Also was hab ich da jetzt abgeschalten?

----------

## new_nOOb

schade nur das meine billig realtek diese optionen nicht unterstützt ;(

----------

## Haldir

TX ist Transceive (Senden), RX ist Receive (Empfangen).

Ich würde dir raten einen Kernel bug zu filen, kann gut sein dass es ein Bug im Treiber ist.

Ja die Realtek Karten unterstützen sowas alles nicht, fehlendes Offloading ist z.b. auch ein Grund warum sich diese Karten nicht für FPS und ähnliches eignen.

----------

## new_nOOb

fps ? und overloading? 

ach du meinst das hier  :Wink: 

http://en.wikipedia.org/wiki/Floating_Production_Storage_and_Offloading

sorry konnte mir das nicht verkneifen  :Wink: 

----------

## Caipi

Tja die freude hat nur kurz angehalten, wollte heute noch mal ausführlich testen und an der performance arbeiten, doch leider habe ich jetzt wieder das alte Problem. Was habe ich geändert? Zum einen einen neustart gemacht, dann mal ein emerge -Du world wobei er nur glibc und die tcsh upgedatet hat. Dann ncoh Bind nen neuen Eintrag für den Samba gegeben.

Habe es auch nochmal mit ethtool -A eth0 rx/tx off versucht aber keine Veränderung. Das gibt es doch nicht...?

Die ersten 500MB gehen übrigens immer schnell.

----------

## new_nOOb

@Caipi teste doch mal deine reine netzwerkgeschwindigkeit super eignet sich dafür iperf was auch im portage dabei ist

damit kannst du dann mal schaun ob das netzwerk überhaupt der flaschenhals ist oder doch eher die festplatte (klingt ja bei dir so wenn die ersten 500mb schnell gehn gehn die evtl ja in den schreibcache des rechners?)

----------

## Caipi

Netperf Ergebnisse haette ich schon:

 *Quote:*   

> TCP REQUEST/RESPONSE TEST to 192.168.1.123
> 
> Local /Remote
> 
> Socket Size   Request  Resp.   Elapsed  Trans.
> ...

 

 *Quote:*   

> TCP STREAM TEST to 192.168.1.123
> 
> Recv   Send    Send                          
> 
> Socket Socket  Message  Elapsed              
> ...

 

----------

## Caipi

Und hier iperf:

 *Quote:*   

> 
> 
> iperf -c 192.168.1.123 -f m -r
> 
> [  4] local 192.168.1.123 port 45704 connected with 192.168.1.13 port 5001
> ...

 

Jetzt glaub ich aber auch das es an was anderem liegt, das sieht doch alles sehr fein aus.

----------

## Caipi

Oh shit, ich habe es. Auf meinem Server sind 2 Raids auf einem Raidcontroller, und das eine scheint einen Hänger zu haben, oh man. Vielen Dank allen die mir bisher geholfen haben, wäre alleine nie auf die Idee gekommen! Jetzt muss ich nur noch schauen was an dem Test-Server falsch ist da tritt das Problem ja auch auf, ohne RAID.

----------

