• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Netzwerkdurchsatz opensuse 11.2-64 ziemlich gering

drboe

Member
Ich habe auf einem Acer Aspire X3900 mit CPU i5-650 opensuse 11.2-64 Bit aufgespielt. Nach der Inbetriebnahme stellt sich heraus, dass die Netzwerk-Performance unter aller Sau ist. Die Gigabit-Netzwerkkarte ist onboard und vom Typ Intel 82578DC. Unter Windows 7, das auf einer anderen Partition installiert ist, beträgt der Durchsatz ca. 75 MB/s, gemessen mit einer 1,5 GB Datei. Unter Linux wurden zunächst nicht einmal 1 MB/s erreicht. 'ethtool eth0' zeigte dann, dass für den Parameter speed regelmäßig nur 10 Mbit/s und full duplex eingestellt wurden. Versuche mit ethtool manuell andere Geschwindigkeiten als 10 MBit/s einzustellen, führten zu "unknown" bei speed und Duplex-Betriebsart. speed=1000 führte dazu, das keine Verbindung mit dem Netz mehr zustande kam. Mit 'speed 100 duplex full autoneg on' wurden immerhin Transferraten von 7-8 MB/s gegen den Server erzielt. Zwar ein Faktor 7 bzw. 8, aber kein wirklich befriedigendes Ergebnis. Nach der Installation des Moduls intel-e1000e-kmp-desktop-1.1.2.1a_2.6.31.5_0.1-15.1.x86_64.rpm von http://download.opensuse.org/repositories/home:/weberho:/kernel-modules/openSUSE_11.2/ wurde es erstmals möglich speed=1000 einzustellen. Allerdings liegt derzeit der maximal erreichbare Durchsatz nur bei 15-20 MB/s, mithin immer noch um einen Faktor 4-5 unter dem Wert, der sich mit Windows 7 reproduzierbar erreichen lässt. Ich mag es gar nicht, wenn Windows faktisch eine unerreichbare Referenz darstellt, würde mich aber letzlich über einen weiteren Faktor 2 schon sehr freuen. :(

Frage: Was kann ich tun, um die Netzwerkperformance zu verbessern? Aktuelle tcp-Werte laut 'sysctl -a | fgrep tcp':

Code:
net.ipv4.tcp_timestamps = 1               
net.ipv4.tcp_window_scaling = 1           
net.ipv4.tcp_sack = 1                     
net.ipv4.tcp_retrans_collapse = 1         
net.ipv4.tcp_syn_retries = 5              
net.ipv4.tcp_synack_retries = 5           
net.ipv4.tcp_max_orphans = 65536          
net.ipv4.tcp_max_tw_buckets = 180000      
net.ipv4.tcp_keepalive_time = 7200        
net.ipv4.tcp_keepalive_probes = 9         
net.ipv4.tcp_keepalive_intvl = 75         
net.ipv4.tcp_retries1 = 3                 
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 366528       488704  733056
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.tcp_rmem = 4096        87380   4194304
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
NB: der Server, gegen den ich teste, läuft unter opensuse 11.1 und kommuniziert über einen GB-Realtek-Adapter, der sich bei der Installation direkt und problemlos auf Gigabit-Betrieb eingestellt hat. Die Tests führe ich im lokalen Netz durch. Zwischen Desktop und Server liegen 2 Kabel Cat 5.E je 3 Meter und ein Gigabit-Switch von Longshine. Da in der Kommunikation Windows <-> Server über die gleiche Strecke deutlich bessere Werte erreicht werden, ist die HW nicht das Problem, wenn man davon absieht, dass die Intel-NIC bzw. deren Treiber sich erkennbar problematisch verhalten. Leider lässt sich in dem kleinen PC (SFF) praktisch keine zweite Netzwerkarte einbauen, mit der man dieser Problematik ggf. ausweichen könnte.

M. Boettcher
 

spoensche

Moderator
Teammitglied
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304

Vergleich mal die Werte der letzten beiden Spalten von . Bei so einem geringen wmem Wert gehts nicht schneller.

http://forum.kernelnewbies.org/read.php?10,264,307,quote=1
 
OP
drboe

drboe

Member
spoensche schrieb:
Vergleich mal die Werte der letzten beiden Spalten von . Bei so einem geringen wmem Wert gehts nicht schneller.

http://forum.kernelnewbies.org/read.php?10,264,307,quote=1
Danke für den Tipp. Aber bist Du sicher, dass es das bringt? Deinem Hinweis entnehme ich nämlich:
These tuning changes basically did nothing - still getting about 13 meg per second over GigE.
D. h, eine Änderung an der Stelle hat so (oder allein?) offenbar nichts gebracht. Serverseitig steht tcp_wmem derzeit übigens auf: 4096 16384 3543040. Wenn ich die 3 Werte richtig verstehe, so ist der mittlere Wert der Default-Wert. Der wäre demnach auf beiden Seiten gleich. Was ohne Änderung eine Symmetrie im Transfer erklären würde. Nun fördert eine Suche einen weiteren Vorschlag zur Erhöhung hervor: http://fasterdata.es.net/TCP-tuning/linux.html empfiehlt:
Like all operating systems, the default maximum Linux TCP buffer sizes are way too small. I suggest changing them to the following settings:

# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
D. h., tcp_wmen hat da den 4-fachen Wert. Ich werde das morgen einmal ausprobieren und melde mich.

M. Boettcher
 
OP
drboe

drboe

Member
So, nach einigen Experimenten erhalte ich derzeit die besten Werte mit

net.ipv4.tcp_mem = 366528 488704 733056
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.core.rmem_max=12582912
net.core.wmem_max=12582912
net.core.netdev_max_backlog=2500

Damit werden knapp 1,5 GB in 68 s durch das Netz transportiert. Windows 7 benötigt mit der gleichen HW für die gleiche Datei allerdings nur 22 s, ist also um den Faktor 3 schneller. Es bleibt also etwas unbefriedigend.

M. Boettcher
 

spoensche

Moderator
Teammitglied
hast du IPv6 ausgeschaltet? Hast du es mal mit einer MTU von 1496 versucht? Arbeitet dein Router mit 100Mbit/s oder kann er 1000MBit/s?
 
OP
drboe

drboe

Member
hast du IPv6 ausgeschaltet? Hast du es mal mit einer MTU von 1496 versucht? Arbeitet dein Router mit 100Mbit/s oder kann er 1000MBit/s?

ipv6 ist abgeschaltet. Beim Boot kommt die Meldung: ipv6: Loaded, but administratively disabled, reboot required to enable. M. E. ist damit keine Störung zu erwarten. MTU ist auf 1492 eingestellt (wg. DSL). Das wird so von opensuse (neben 576 und 1500) angeboten. Bei 1496 würde m. E. schon eine Fragmentierung der Pakete erfolgen. Leider erlaubt die Einstellung des Moduls keine Jumbo-Frames von 9 KB. Der Switch würde die passieren lassen. Der Router kann LAN-seitig nur 100 MBit/s. Das ist aber ausreichend, weil der Übergang zu DSL in jedem Fall der Flaschenhals ist. Die Kommunikation Client<->Server läuft direkt über einen Gigabit-Switch. An den ist natürlich auch der Router (als langsamster Teilnehmer) angeschlossen. Das stört aber nicht, wie man an den deutlich höheren Vergleichswerten für Windows7 <=> Server sehen kann. M. E. ist die HW-Konstellation insgesamt OK, weil sich Fehler darin auch auf die Kommunikation unter Windows 7 auswirken müssten. Demnach muss es am Linux-Driver bzw. dessen Konfiguration liegen.

M. Boettcher
 
Hallo zusammen,

ich habe mich registriert um mich mal hier einzuklinken. Ich habe interessanterweise genau das selbe Problem wie der TO, auch wenn es bei meinem Windows-Rechner um Vista geht und beim Server um ubuntu. ;-)

Kurz: 2 Windows-Rechner XP<->Vista über Cat5e und TP-Switch: nahe an 1GBit, Vista<->ubuntu: ca. 250MBit.

Ich habe schon so einiges herausgesucht und herumprobiert, m.E. liegt es am neuen TCP-Stack in Vista/Windows 7. Dort wird die TCP Window Size zwischen den Rechnern ausgehandelt, und genau da scheint Linux nicht korrekt mitzuspielen.

Zum Durchsatztest empfehle ich iperf (Server-Mode) auf dem Linux-Rechner und jperf (Client-Mode) auf dem Windows-Rechner. Dann kann man am Windowsrechner ein wenig mit den Werten spielen. Ich habe allerdings keine Möglichkeit gefunden auf den Windows-Rechnern die TCP-Window-Size fest voreinzustellen, das sieht der TCP-Stack wohl nicht (mehr) vor.
Ansatzpunkt: Linux muss kapieren, dass die Gegenseite ein Windows-Rechner ist, und sich (korrekt) anpassen! Ich vermute stark, dass die Verbindung Linux-Vista sich bzgl. der Parameter auf die kleinsten Nenner einigt. Aber wie kann man das ändern? Windowsrechner scheinen sich da untereinander besser aufeinander abzustimmen. Im Entwicklerblog von Microsoft steht genau darüber etwas drin:

http://blogs.msdn.com/wndp/archive/2006/05/05/Winhec-blog-tcpip-2.aspx

Vielleicht findet man so einen Ansatz zur Problemlösung. Ich habe allerdings momentan keine Idee mehr.
Wenn ich wieder Zeit habe und die Frau nicht schimpft, weil ich wieder so lange am Rechner sitze :roll: , probiere ich mal aus an meinem XP-Rechner die dynamische Anpassung abzuschalten (dort geht es nämlich noch) und dann mal den Durchsatz zum Ubuntu-Server zu messen. Wenn das dann schnell geht, ist das Problem eingekreist. Evtl. hast Du etwas Zeit, dasselbe auch mal zu testen.


Viele Grüße
Marcel

PS: Meine Hardware: Server: i3-540 mit GA-H57 Board (OnBoard GbE, Realtek 8111), Vista: Realtek 8169 GbE
 
OP
drboe

drboe

Member
Marcel-126 schrieb:
Ich habe interessanterweise genau das selbe Problem wie der TO, auch wenn es bei meinem Windows-Rechner um Vista geht und beim Server um ubuntu. ;-)
Der Windows-PC ist gar nicht mein Problem. Der ist nämlich, bezogen auf den Netzwerkdurchsatz, gegen den Linux-Server (sic!) 3 mal schneller als der Linux-Client auf der gleichen Hardware. NB: Die Windows-Installation ist für mich nur die Beigabe beim Kauf des PC. Ich brauche die nicht; löschen muss ich sie bei 1 TB auf der Platte aber auch nicht gleich.

Marcel-126 schrieb:
Zum Durchsatztest empfehle ich iperf (Server-Mode) auf dem Linux-Rechner und jperf (Client-Mode) auf dem Windows-Rechner.
Es ist schwierig von den Tool-Ergebnissen auf die Situation zu schliessen. Ein Test mit Windows7 gegen den (Linux-)Server zeigt nämlich nur 347 Mbit/s. Damit sind aber die beobachteten 75 MByte/s beim Transfer einer 1,5 GB Datei nicht machbar. Dazu braucht es 750 MBit/s und mehr. Die zeigt nun ausgerechnet der Test mit opensuse 11.2 ix_64: 780 Mbit/s, um genau zu sein. Was bedeuten würde, dass ca. 2/3 des Durchsatzes Client-seitig durch den Overhead des smbclient aufgefressen wird, weil beim Wechsel auf den Linux-Client gerade noch 20-23 MB/s erreicht werden. D. h., die Tests mit iperf legen ein anderes Bild nahe, als ein realer Transfervergleich HD-zu-HD ergibt.

Um die Tests abzurunden: ich haben noch die Transferleistung eines Celeron 1,7 GHz mit Windows XP Home mit einer 100-Mbit-Netzwerkkarte mit Realtek-Chip geprüft: 8,5 MB/s.

Während ich das ursprüngliche Verhalten des e1000e-Treibers als fehlerhaft bezeichne, es gibt dazu einen Bug unter https://bugzilla.novell.com/show_bug.cgi?id=576970, könnte ich mit den iperf-Ergebnissen dem Modul-Entwickler wohl kaum etwas vorwerfen. So bleibt eigentlich nur der Ärger, dass die Netz-Performance im Vergleich mit einem Windows7-Client so gering ist. Ich könnte damit besser leben, ginge es gegen einen Windows-Server. Leider punktet Windows7 aber im gemischten Betrieb, auch wenn dabei das Protokoll vom MS genutzt wird. Ob NFS mehr bringt, wäre ggf. zu prüfen. Ob ich mir das in nächster Zeit antue, weiß ich noch nicht. Immerhin war die Situation zu Beginn meiner Tests, als ich knapp 1 MBit/s erreichte, deutlich schlimmer.

M. Boettcher
 

spoensche

Moderator
Teammitglied
Meine TCP Einstellungen:
Code:
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
fs.inotify.max_user_watches = 65536
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1

Nicht nur wmem und rmem kann man optimieren. Mit den Einstellungen läuft es bei mir wie am Schnürchen.
 
OP
drboe

drboe

Member
@spoensche

Vielen Dank für Deine Einstellungen, mit denen ich meine eben verglichen habe. Lediglich net.ipv4.tcp_no_metrics_save stand bei mir abweichend auf 0. Die Änderung auf 1 hat aber leider nichts gebracht.

M. Boettcher
 

spoensche

Moderator
Teammitglied
Wie sehen deine Einstellungen den jetzt aus? Welchen Wert hat die MTU? Poste mal die Konfiguration der Netzwerkkarte.

Der 100 MBit Router bremst dich übrigens doch aus, da deine Netzwerkkarte sich dem Router anpasst und so mit auch nur mit 100MBit/s arbeitet.

PS:

Je nach Füllstand der 1 TB Platte geht wegen der hohen Dichte die IO- Performance in den Keller.
 
OP
drboe

drboe

Member
spoensche schrieb:
Wie sehen deine Einstellungen den jetzt aus? Welchen Wert hat die MTU? Poste mal die Konfiguration der Netzwerkkarte.
Die MTU ist 1492. Und das bei Windows und Linux.

Code:
Link encap:Ethernet  Hardware Adresse 90:FB:A6:48:41:10
          inet Adresse:192.168.5.50  Bcast:192.168.5.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:76613 errors:0 dropped:0 overruns:0 frame:0
          TX packets:60688 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000
          RX bytes:93317765 (88.9 Mb)  TX bytes:8383778 (7.9 Mb)

spoensche schrieb:
Der 100 MBit Router bremst dich übrigens doch aus, da deine Netzwerkkarte sich dem Router anpasst und so mit auch nur mit 100MBit/s arbeitet.
Tut sie nicht. Würde die Netzwerkkarte durch den Router auf 100 MBit/s begrenzt, so wäre ein Datendurchsatz von 20 MB/s sensationell hoch, weil das mind. 160 MBit/s (=16o%) entspräche. Auch würde dann gelten müssen, dass der Betrieb im (geswitchten) LAN vom langsamsten Teilnehmer des Gesamtnetztes abhängt. Das wäre dann die DSL-Schnittstelle des Routers, die typisch nur 1-6 MBit/s erreicht. Zudem sendet der Switch die Pakete nach der Lernphase direkt in die einzelnen Segmente, die hier nur je einen Teilnehmer haben; es gibt nicht einen einzigen Kollisionsbereich. Der relativ langsame Router bekommt also vom Verkehr Client <> Server nichts mit. Zudem "wissen" weder der Router noch der Switch, welches OS auf dem Client gefahren wird. Wenn denn abgebremst würde, so wäre ein negativer Einfluß OS-unabhängig. Ich würde mich natürlich nicht ärgern, käme Windows7 auch nur auf 20-25 MB/s.

spoensche schrieb:
Je nach Füllstand der 1 TB Platte geht wegen der hohen Dichte die IO- Performance in den Keller.
Das kann sein; wenn es viele Trackwechsel gibt, wird die Maximal-Performance der Platte und damit des Gesamtsystems sicher nicht erreicht. Der PC ist aber noch sehr frisch. Die Windows-Partition ist daher erst zu 6,8%, die Linux-Partition zu 8,3% ausgenutzt. Ich kann mir nicht vorstellen, dass 4-5 GB mehr oder weniger so einen Einfluß haben.

M. Boettcher
 
Hallo!

Ich habe auch mal weiter getestet, auch wenn ich eingestehen muss, dass ich die grundsätzliche Fragestellung des TO falsch verstanden habe. Da ich allerdings auch mangelnden Datendurchsatz beklagen muss, und auch glaube, dass die Ursache zumindest ähnlich ist, bleibe ich mal dabei. ;-)

Zum Test: 2751441476Bytes vom Ubuntu-Server zum Vista-Rechner:
Dauer 82s, daher: 31,2 MiB/s. Das entspricht ca. dem Durchsatz, den auch iperf/jperf gemssen hat. Das wundert mich übrigens auch nicht, da iperf im Grunde auch nur eine große Datei sendet/empfängt. Da allerdings dabei die Festplatte nicht gebraucht wird, fällt diese als Einflussfaktor auch weg.

Test mit der Kombination ubuntu/XP haben ebenso Durchsätze von ca. 32-35MiB/s ergeben. Wenn ich allerdings am XP-Rechner die TCP Windows Size auf 256kiB erhöht habe, erzielte ich Raten von 95MiB/s! Und das, obwohl zwischen Switch und XP-Rechner ein altes 10m langes Cat5-UTP-Kabel liegt... :schockiert: Leider merkt sich XP die erhöhte Window Size nicht, sondern schaltet immer wieder auf die automatische Anpassung um. Die schnellste Rate, die ich zwischen ubuntu und Vista gemessen habe lag übrigens bei nur ca. 80-85MiB/s (trotz durchgehender und deutlich kürzerer Cat5e-Leitungen).

Mir scheint es so, als ob alles von dieser Windows Size abhängt. Ich bin mir allerdings nicht sicher, ob diese unter Linux "rmem" als Entsprechung hat. Logisch erscheint mir der erhebliche Einfluss der Windows Size allerdings, da eben das Übertragungsfenster deutlich größer wird und nicht ständig auf eine Bestätigung der Gegenseite gewartet werden muss. Bei einer einigermaßen guten Verkabelung im LAN kann man die im (seltenen) Fehlerfall neu zu übertragenden Fenster wohl verschmerzen.

@spoensche: Ich verstehe nicht wirklich, weshalb der Router einen Einfluss haben sollte. So wie ich es verstanden habe hängt der Router an einem Gigabit-Switch. Dem ist es völlig egal, wie schnell die einzelnen Verbindungspartner sind. Zwischen zwei GBit-Geräten wird auch GBit-schnell vermittelt.

Viele Grüße
Marcel
 

spoensche

Moderator
Teammitglied
Marcel-126 schrieb:
Wenn ich allerdings am XP-Rechner die TCP Windows Size auf 256kiB erhöht habe, erzielte ich Raten von 95MiB/s! Und das, obwohl zwischen Switch und XP-Rechner ein altes 10m langes Cat5-UTP-Kabel liegt...

UTP = Unshielde Twisted Pair. D.h. Das kabel hat keine Abschirmung und ist anfällig fürr externe Störfaktoren, wie z.B. Magnetfelder.

Cat. 5 = Kabel der Kategorie 5. D.h. Das Kabel kann mit Frequenzen bis zu einem bestimmten Wert (Frequenzbänder sind nichts anderes als ein Frequenzbereich, z.B. von 1 KHz - 2 KHz)

Cat 5 Kabel können für 1000Base-T (Gigabit Ethernet) verwendet werden.

Die 10m Länge des Kabels wirkt sich nicht merkbar auf die Geschwindigkeit aus, es sei den, das Kabel ist länger als 100m. (max. 100m zwischen Switch und Enddgerät oder Switch zu Switch). Ab einer Länge von mehr als 100m wird die Signaldämpfung zu hoch und beeinflusst die Übertragunsgeschwindigkeit. Wenn die Signaldämpfung zu groß ist, wird das Signal schwächer, bis es ganz verschwunden ist.


Marcel-126 schrieb:
Die schnellste Rate, die ich zwischen ubuntu und Vista gemessen habe lag übrigens bei nur ca. 80-85MiB/s (trotz durchgehender und deutlich kürzerer Cat5e-Leitungen).

Cat5e ist eine Erweiterung von Cat.5.

Marcel-126 schrieb:
Mir scheint es so, als ob alles von dieser Windows Size abhängt. Ich bin mir allerdings nicht sicher, ob diese unter Linux "rmem" als Entsprechung hat.
Logisch erscheint mir der erhebliche Einfluss der Windows Size allerdings, da eben das Übertragungsfenster deutlich größer wird und nicht ständig auf eine Bestätigung der Gegenseite gewartet werden muss. Bei einer einigermaßen guten Verkabelung im LAN kann man die im (seltenen) Fehlerfall neu zu übertragenden Fenster wohl verschmerzen.

Die TCP Window Size hat nichts mit Windows zu tun, sondern arbeitet auf Protokollebene. Trotz größerem Übertragungsfenster wird der Empfang der TCP Pakete bestätigt. (Wenn nicht empfangen, wird das jeweilige Paket neu angefordert, weil TCP ein verbinddungsorientiertes Protokoll ist, im Gegensatz zu UDP)

Marcel-126 schrieb:
Bei einer einigermaßen guten Verkabelung im LAN kann man die im (seltenen) Fehlerfall neu zu übertragenden Fenster wohl verschmerzen.

Falsch. Es entstehen ständig Übertragungsfehler im LAN, weil jeder senden kann, wann er Lust und Laune hat. Damit dies aber nicht die Übertragung bockiert bzw. verzögert gibt es CSMA/CD (Carrier Sense Multiple Acccess with Collision Detection), was Kollisionen (gleichzeitiger Paketversand von unterschiedlichen Absendern) entdeckt und die Neuübermittlung des Pakets einleitet. Früher, also bei token Ring konnte nur einer nach dem anderen Pakete verschicken, wobei das Paket von Station zu Station wanderte, um nachzufragen, ob es dort richtig ist, was eine langsame Übertragung zur Folge hat.

Marcel-126 schrieb:
@spoensche: Ich verstehe nicht wirklich, weshalb der Router einen Einfluss haben sollte. So wie ich es verstanden habe hängt der Router an einem Gigabit-Switch. Dem ist es völlig egal, wie schnell die einzelnen Verbindungspartner sind. Zwischen zwei GBit-Geräten wird auch GBit-schnell vermittelt.

Ein Switch macht nichts anderes als die Pakete weiterzuleiten und merkt, zwecks Optimierung, was von wo nach woanders geht. Ein Gigabit Switch kann also Übertragungsraten von 1000Mbit/s weiterleiten, aber auch nur, wenn die angeschlossenen Gegenstellen (Rechner 1 an Port 1 und Rechner 2 an Port 2) beide Gigabit fähige LAN Karten haben. Wenn einer von beiden nur max. 100 MBit/s kann, dann wird auch nur mit max. 100 MBit/s gesendet, egal ob der Switch Gigabit LAN hat oder nicht. Und das ist bei dir der Fall, da dein Router nicht mehr als 100 MBit/s kann.


PS:

Den IO Durchsatz kann man mit
Code:
iostat
messen. Mehr dazu unter: http://www.thomas-krenn.com/de/wiki/Kategorie:Linux_Performance
 
Hallo spoensche,

nett, dass Du mir so sorgfältig und umfangreich antwortest, allerdings verstehe ich Deine Aufklärungsarbeit nicht, da ich im Grunde doch genau dasselbe sage. :???:

Zu den Leitungen: Ich wollte mit dem Hinweis nur andeuten, dass trotz insgesamt dürftigerer Verbindung der Durchsatz besser ist.

Dass die TCP Window-Size nichts mit Windows als Betriebssystem tun hat ist auch klar, das habe ich auch an keiner Stelle geschrieben. Aber klar ist doch: Es wird ein "Window" übertragen und erst dann eine Rückmeldung der Gegenstelle erwartet. Ist dabei ein Fehler aufgetreten muss doch das ganze Window neu übertragen werden, oder? Also bedeuten größere Windows im Fehlerfall höheres Datenaufkommen zwischen den Verbindungspartnern. Ist nun die Hardware schlecht (z.B. lange Cat5-Leitungen), treten potenziell auch mehr Fehler auf.

Zum Router: Auch völlig klar, dass nicht schneller übertragen werden kann, als der jeweils langsamste Verbindungspartner. Dem Switch ist es allerdings herzlich egal, ob z.B. an Port 8 an 100MBit-Gerät hängt. Die Gigabit-Geräte an Port 1 und 2 beispielsweise kommunizieren dennoch untereinander mit 1GB. Daher möchte ich hier drboe zustimmen.

Schade nur, dass diese Diskussion nicht zur Lösung des Problems des miserablen Durchsatzes beiträgt, unabhängig davon, ob es nun den Durchsatz zwischen bei Linux-Systemen oder einem Windows und einem Linuxsystem betrifft.

Viele Grüße
Marcel
 

spoensche

Moderator
Teammitglied
Marcel-126 schrieb:
nett, dass Du mir so sorgfältig und umfangreich antwortest, allerdings verstehe ich Deine Aufklärungsarbeit nicht, da ich im Grunde doch genau dasselbe sage. :???:

Ich hatte deine Ausage, mit dem XP- Rechner und dem direkt folgenden Windows so interpretiert, dass du die Windows Size als Windows only Eigenschaft verstehst. Also falsche Interpretation meinerseits.

Marcel-126 schrieb:
Aber klar ist doch: Es wird ein "Window" übertragen und erst dann eine Rückmeldung der Gegenstelle erwartet. Ist dabei ein Fehler aufgetreten muss doch das ganze Window neu übertragen werden, oder? [/code]

Das stimmt so nicht. Die Windows Size gibt an, wann eine Empfangsbestätigung gesendet werden soll bzw. muss. D.h. wenn die zu sendenden Daten größer als die Window Size sind und die übertragenen Daten gleich der Window Size ist, muss eine Empfangsbestätigung gesendet werden. Die Window Size gibt also die maximale Größe der Datenmenge an, die in einem Rutsch gesendet werden kann.

Bei einem Fehler wird nicht das ganze Window neu übertragen, sondern nur die fehlerhaften Pakete.

Marcel-126 schrieb:
Also bedeuten größere Windows im Fehlerfall höheres Datenaufkommen zwischen den Verbindungspartnern.

Auch im "normal Fall" bedeutet dies ein höheres Datenaufkommen. Die Window Size wird vom Empänger bestimmt bzw. vorgeschlagen.

Marcel-126 schrieb:
Schade nur, dass diese Diskussion nicht zur Lösung des Problems des miserablen Durchsatzes beiträgt, unabhängig davon, ob es nun den Durchsatz zwischen bei Linux-Systemen oder einem Windows und einem Linuxsystem betrifft.

Ich habe dir doch einen Link, bezüglich Linux Performance Tuning an die Hand gegeben. Warum liest du dir das dann nicht mal durch?

Das Tool mtr gibt sehr viele Informationen über gesendete und verlorene Pakete und man kann die Ursache des Problems eingrenzen. Vor allem der Link zu http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf gibt, nicht nur zur Netzwerkperformance ausführliche Informationen.
 
Hallo spoensche,

zunächst mal: Herzlichen Dank. Mein persönliches config sieht jetzt erstmal so aus:

missverstaendnis_mode = off
read_links = on

;)

Vielen Dank für Deine Antwort. Ich habe diesen einen Links am Ende Deines Beitrages einfach übersehen. Ich werde mir die Seite durchlesen und hoffe, dass der Durchsatz durch die richtigen Einstellungen besser wird.

Ich melde mich dann wieder.

Viele Grüße
Marcel
 
OP
drboe

drboe

Member
Indem ich Client-seitig

net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0

gesetzt habe (in /etc/sysctl.conf), konnte ich den Durchsatz von 22,5 MB/s auf 34,8 MB/s steigern. D. h., der Durchsatz liegt jetzt "nur noch " um den Faktor 2 unter dem mit Windows 7 erzielbaren Wert. Bzw. ist um 50% höher als vorher. Freu!

M. Boettcher
 
Hallo!

Diese Änderungen habe ich auch vorgenommen und konnte den Durchsatz dadurch auch etwas erhöhen.
Eine weitere kleine Verbesserung hat die Vergrößerung der txqueuelen gebracht. Dort habe ich 20000 eingetragen. Ob das ein sinnvoller Wert ist, weiß ich allerdings nicht.
Durch die Summe der Optimierungen beträgt die Übertragungsgeschwindigkeit zwischen Windows und Ubuntu per Samba-Verbindung zwischen 40 und 45MB/s. Das ist ein für Samba schon echt guter Wert. Vielleicht kann man jetzt Samba noch auf Geschwindigkeit trimmen. Ich denke, dass hier auch noch Potenzial schlummert.

Jetzt frage ich mich nur nach einem sinnvollen Wert für die "Packet Queue", netdev_max_backlog. Den wollte ich auch noch ausprobieren.

Viele Grüße
Marcel
 
OP
drboe

drboe

Member
Marcel-126 schrieb:
Jetzt frage ich mich nur nach einem sinnvollen Wert für die "Packet Queue", netdev_max_backlog. Den wollte ich auch noch ausprobieren.
Habe ich auf 2500 gesetzt.

M. Boettcher
 
Oben