# Fehlender Speed bei Gbit-Server

## xRubberDucky

Hallo zusammen

da in unserer Firma der "Linuxmensch" gekündigt hat bin ich da nun zur Serverbetreuung abkommandiert worden.

Meine Kenntnisse würd ich aber eher als dürftig beschreiben. Deshalb nicht böse sein wenn die Fragen vielleicht etwas doof sind  :Smile: 

Unser Server war bis jetzt mit 100 Mbit ans Inet angeschlossen. Nun wurd der aber auf 1 Gbit umgestellt.

Das Problem ist nun das er die Geschwindigkeit nicht erreicht. Wir liegen so bei 30-40 Mb/s.

Sollten aber bei 70+ Mb/s liegen. Die Hardware ist auf jeden Fall schnell genug und der Hoster hat auch schon alles geprüft.

Nu stellt der Hoster die Frage ob wir viele kleine IP-Pakete verschicken ?

Bei Windows gibts sowas wie MTU, MSS und TCP Receive Window. Gibts sowas bei Gentoo auch und wenn ja welche Werte sollte man

dort einstellen für Gbit ?

Benutzt wird Gentoo mit Kernel 2.6.19

Hoffe auf Antwort

xRubberDucky

----------

## schachti

Ein paar Dinge, die man erstmal bedenken muß: Wie testet Ihr den Durchsatz? Wenn Ihr Daten von Festplatte lest und diese über das Netzwerk verschickt, ist evtl. nicht das Netzwerk, sondern die Festplatte der Flaschenhals. Wenn der Server als Router fungiert, muß natürlich die zur Verfügung stehende Bandbreite der Netzwerkkarte halbiert werden (da Pakete erst rein und dann wieder raus müssen). Kommt der Traffic auf einer Netzwerkkarte rein und geht zur anderen wieder raus, muß die Kapazität des verwendeten Busses berücksichtigt werden (habt Ihr zwei PCI-Karten, teilen die sich die ca. 120 MB/s des PCI-Bus).

Ansonsten: Wie sieht die CPU-Auslastung während der Übertragung aus? Läuft eine Firewall und/oder QoS? Kommt es evtl. massiv zu Übertragungsfehlern (siehe Ausgabe von ifconfig, errors/dropped/overruns)?

Die eingestellte MTU findest Du in der Ausgabe von ifconfig.

----------

## Anarcho

Also Gigabit sollte generell FullDuplex sein, daher sollten schon beide Richtungen simultan möglich sein.

Noch entscheidend neben den von schachti bereits genannten ist auch der Kommunikationspartner. Wenn dieser nicht mehr verkraftet kommt auch nicht mehr durch, selbst wenn euer Knoten mehr leisten kann.

----------

## SvenFischer

Manchmal sind aber auch die Treiber oder die Hardware der Flaschenhals.

Bitte zeige mal mit dem Befehl "lspci", was Du so hast.

----------

## xRubberDucky

Erstmal Danke für die Antworten

Hardware:

Supermicro server 

Intel Xeon X3210 2,13 Ghz 

4 x 750 GB SATA300-HDD 

4 Gigabyte Ram

lspci  

00:00.0 Host bridge: Intel Corporation Server DRAM Controller (rev 01) ·

00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev 02) ·

00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev 02) ·

00:1a.2 USB Controller: Intel Corporation USB UHCI Controller #6 (rev 02) ·

00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev 02) ·

00:1c.0 PCI bridge: Intel Corporation PCI Express Port 1 (rev 02) ·

00:1c.4 PCI bridge: Intel Corporation PCI Express Port 5 (rev 02) ·

00:1c.5 PCI bridge: Intel Corporation PCI Express Port 6 (rev 02) ·

00:1d.0 USB Controller: Intel Corporation USB UHCI Controller #1 (rev 02) ·

00:1d.1 USB Controller: Intel Corporation USB UHCI Controller #2 (rev 02) ·

00:1d.2 USB Controller: Intel Corporation USB UHCI Controller #3 (rev 02) ·

00:1d.7 USB Controller: Intel Corporation USB2 EHCI Controller #1 (rev 02) ·

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) ·

00:1f.0 ISA bridge: Intel Corporation LPC Interface Controller (rev 02) ·

00:1f.2 SATA controller: Intel Corporation 6 port SATA AHCI Controller (rev 02) ·

00:1f.3 SMBus: Intel Corporation SMBus Controller (rev 02) ·

00:1f.6 Signal processing controller: Intel Corporation Thermal Subsystem (rev 02) ·

0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) ·

0f:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller ·

11:04.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 ·

CPU lag bei max  40%

FullDuplex: Ja

Firewall: Nein

QoS: Nein

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:CC  

inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.x  Mask:255.255.255.248

inet6 addr: xxx::xxx:xxx:xxx:xxx/64 Scope:Link 

UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 

RX packets:23337506 errors:0 dropped:0 overruns:0 frame:0 

TX packets:15698334 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000  

RX bytes:183202499 (174.7 Mb)  TX bytes:690228435 (658.2 Mb) 

Base address:0x2000 Memory:de100000-de120000  

Getestet haben wie den Speed mit FTP von 2 anderen Gbit-Servern die 70-90 Mb/s schaffen.

Die Daten kommen hauptsächlich per FTP von verschieden schnellen Servern.

Von den langsameren Servern ist das auch kein Problem aber wir haben auch einige Kunden mit Gbitanbindung 

und da wollen wir halt den vollen Speed zur verfügung stellen. Das Routing ist auch absolut 1A in ordnung.

Ich bastle da jetzt schon eine Woche dran rum und finde den Fehler nicht.

XRubberDucky

----------

## bbgermany

Hi,

ich habe mit GBit die gleichen Erfahrungen gemacht. In einer der Special-Edition vom Linuxmagazin war eine nette Erklärung drin. Meist erhält man nicht einmal annähernd den maximal theoretischen Datendurchsatz. Man kann diesen nur dann erreichen, wenn man mehrere Verbindungen gleichzeitig laufen hat. Logischerweise müssen bei Sender und Empfänger, wie meine Vorredner schon gesagt haben, die Komponenten auch mitspielen. 

Am besten ist es, wenn du mit netio mal den theoretischen Durchsatz testest. Dort sollte bei GBit in etwa 60-70MB/s bei Windows zu Linux und ca 70-90MB/s bei Linux zu Linux rauskommen  :Wink: 

MfG. Stefan

----------

## dertobi123

 *xRubberDucky wrote:*   

> da in unserer Firma der "Linuxmensch" gekündigt hat bin ich da nun zur Serverbetreuung abkommandiert worden.
> 
> Meine Kenntnisse würd ich aber eher als dürftig beschreiben. Deshalb nicht böse sein wenn die Fragen vielleicht etwas doof sind 
> 
> Unser Server war bis jetzt mit 100 Mbit ans Inet angeschlossen. Nun wurd der aber auf 1 Gbit umgestellt.
> ...

 

Von wo nach wo und wie wird das gemessen? Nicht das der Uplink(bzw. das Routing) des Providers hier das "Problem" ist ...

Davon ab: Linux 2.6.19, kein Paketfilter/Firewall, 1Gbit Uplink ... das schreit nach jemandem, der sich damit auskennt.

----------

## Baer69

Hallo,

ein schönes Tool um die Performance zu testen ist iperf. Es läuft im Client/Server Modus und gibt einen guten Überblick.

MfG

BM

----------

## gimpel

Bei der Ausgabe von lspci vermisse ich irgendwie einen ordentlichen SCSI oder zumindest nen fetten SATA RAID controller.

Wenn ihr das mit FTP testet, müssen die Daten vom Server ja erstmal von der Festplatte gelesen werden, und auf dem client geschrieben werden.

```
00:1f.2 SATA controller: Intel Corporation 6 port SATA AHCI Controller (rev 02) · 
```

^^ die Krücke schafft garantiert keine 90MB/s (effektiv) beim Lesen. ~70MB/s cached reads vermutlich, dazu die üblichen Verdächtigen wenns um echte Zugriffe geht ((pseudo-)Soft-RAID usw), da klingen 50MB/s passend.

Die Kiste hat ja genug RAM, von daher kannst du mal ein 1-2GB file in /dev/shm/ mit dd anlegen, und das über's Netzwerk jagen, zum Vergleich, wobei der client das dann auch in den RAM schreiben sollte. Oder wie bereits erwähnt das Netzwerk mit tools wie iperf testen.

50MB/s für FTP sind richtig gut, nur so nebenbei, das sind fast 3GB/min  :Smile: 

----------

## think4urs11

 *xRubberDucky wrote:*   

> Getestet haben wie den Speed mit FTP von 2 anderen Gbit-Servern die 70-90 Mb/s schaffen.
> 
> Die Daten kommen hauptsächlich per FTP von verschieden schnellen Servern.

 

Wie sehen den die Latenzzeiten zwischen den Servern aus (ping)?

Und wie Tobi schon sagte: ein alter Kernel, keine Firewall und eine 'fette Pipe' klingen irgendwie nach Einladung an $Spammer/$Blackhat - wie war doch gleich die IP?  :Wink: 

----------

## Anarcho

 *gimpel wrote:*   

> Bei der Ausgabe von lspci vermisse ich irgendwie einen ordentlichen SCSI oder zumindest nen fetten SATA RAID controller.
> 
> Wenn ihr das mit FTP testet, müssen die Daten vom Server ja erstmal von der Festplatte gelesen werden, und auf dem client geschrieben werden.
> 
> ```
> ...

 

Also das würde ich so nicht unterschreiben. Mein Server hat eine ähnliche Ausstatung, ebenfalls Intel ICH AHCI SATA Anschlüsse. Die 3 Platten im RAID5 schaffen dabei eine Leseleistung von ca. 130 MB/s. Leider bleibt nach Verschlüsselung nicht mehr soviel von übrig...

Aber dennoch, um es auszuschliessen würde ich für solche tests auch eher netio nehmen.

----------

## NightDragon

Eine der wichtigsten Komponenten bei Netzwerken ist und bleibt die Leitung selbst.

Ein Knick, eine Biegung, ein Drucker irgendwo in der Nähe der Leitung, kein STP bei der Horizontalverkabelung und zuviel Patch, schlechte Kontakte usw... 

sind da ganz problematisch.

War's bei 100Mbit noch eher egal ist's bei 1Gbit schon wesentlich schlimmer wenn die Leitungen nicht das entsprechende Dämpfungsmaß haben. Zusätzlich gibt's dann noch FEXT, NEXT, etc...

Zusätzlich zur Verkabelung und den von den anderen Usern genannten Daten und bgzl. MTU (zu finden unter /sys/class/net/ethX/mtu

), etc...:

gibt es noch die "TCP advanced congestion control".

u.U. kann die auch noch mitspielen.

Infos dazu und welche für Deinen Anwendungsfall die beste ist, findest du sicher wenn Du googlst.

----------

## Anarcho

 *NightDragon wrote:*   

> Eine der wichtigsten Komponenten bei Netzwerken ist und bleibt die Leitung selbst.
> 
> Ein Knick, eine Biegung, ein Drucker irgendwo in der Nähe der Leitung, kein STP bei der Horizontalverkabelung und zuviel Patch, schlechte Kontakte usw... 
> 
> sind da ganz problematisch.

 

Stimmt. Hauptsache du hast die Knicke als Steilkurve ausgelegt. Dann fliegen die Elektronen nicht so leicht aus der Bahn, denn bei Gigabit hat man schon recht hohe Kurvengeschwindigkeiten.   :Twisted Evil: 

----------

## SvenFischer

Gibt es GBit Kabel auch als optischen Leiter, dazu pasene Router und Netzwerkkarten? Werden die auch in Rechenzentren verwendet oder ist das eine zu teure Spielerei und nur ab 10 GBit sinnvoll?

----------

## papahuhn

Ja, es gibt sogar LWL-Standards für 100Mbit/s Verbindungen.

----------

## flash49

 *SvenFischer wrote:*   

> Gibt es GBit Kabel auch als optischen Leiter, dazu pasene Router und Netzwerkkarten? Werden die auch in Rechenzentren verwendet oder ist das eine zu teure Spielerei und nur ab 10 GBit sinnvoll?

 

Ja die gibt es, allerdings sind die, wie du vermutet hast erheblich teurer. Meistens haben bessere Server- und Workgroupswitches 1-2 GBIC/Mini-GBIc Module in die man je einen LWL Transciever stecken kann. Glasfaser lohnt sich allerdings nur, wenn man große Strecken überbrücken muss, starke Störquellen in der Nähe hat (z.B. bei den Steuerleitungen für Hochspannungsnetze) oder höchste Kapazitäten benötigt(10GBit, Seekabel,Multikanal...)

Aber zurück zum Thema: Teste doch mal den Rohdurchsatz mit iperf dabei sind eventuelle Nebeneffekte durch Festplatte oder Protokolloverhead ausgeschlossen.

Bei Hochgeschwindigkeitsverbindungen kann es auch sein, daß die Puffer etwas zu klein sind, besonders wenn die Latenzzeiten der Verbindung groß sind (mehrere Kilometer und/oder mehre Router, Switches dazwischen). siehe auch: http://gentoo-wiki.com/HOWTO_TCP_Tuning

Ich habe die bei mir etwas erhöht (sysctl -p /etc/sysctl.conf):

```
#/etc/sysctl.conf

# increase TCP maximum buffer size

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

# increase Linux autotuning TCP buffer limits

# min, default, and maximum number of bytes to use

net.ipv4.tcp_rmem = 4096 87380 16777216

net.ipv4.tcp_wmem = 4096 65536 16777216

```

----------

## NightDragon

 *Anarcho wrote:*   

> Stimmt. Hauptsache du hast die Knicke als Steilkurve ausgelegt. Dann fliegen die Elektronen nicht so leicht aus der Bahn, denn bei Gigabit hat man schon recht hohe Kurvengeschwindigkeiten.

 

*g* Naja... das wird kaum passieren, der Skin-Effekt spielt bei der Datenübertragung dennoch eine Rolle   :Wink: 

----------

