Re: AW: Fast Ethernet und Samba

[SPATZ1 t-online de (Frank Schneider)]

Hallo...

Kai Kohlmorgen wrote:
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Frank Schneider [mailto:SPATZ1 t-online de]
> > Gesendet: Mittwoch, 22. März 2000 18:27
> > An: redhat-list-de redhat de
> > Betreff: Re: [redhat-list-de] Fast Ethernet und Samba
> 
> >
> > Dabei kommen dann bei zwei Linux-Clients Werte zwischen 4 und 6
> > Megabyte/sec heraus.
> > (Je nach Platte, CPU, RAM, etc.)
> 
> Platte und RAM sind die beiden entscheidenen faktoren...

In Grenzen: Nen 486-er bringt einfach nicht das durchn Speicher wie nen
PII...
32 Bit mit 33MHz statt 64Bit mit 100MHz...:-))
 
> > Bei Verwendung eines 100MBit Switches kann man bei beiden Rechnern
> > 100MBit/FullDuplex
> > fahren, da sind dann nochmal 10-20% mehr drin, wenns der Switch abkann
> > und die Karten
> > auch schön Vollduplex fahren.
> 
> Vollduplex heisst bei linux mit 0815 karten (pci) wie dec21040 und rtl8139,
> einbruch der maxtranferrate... waehrend die karten unter win (beide clients)
> super-performance bringen, bricht der transfer zusammen wenn einer der
> beiden rechner mit den karten unter linux laeuft.

Au, Vorsicht!
Ist das auch mal gecheckt worden, also über den Status "hab ich gehört"
rausgekommen ?
Meist ist das Problem nämlich, das man die Win-Kiste per Klicki-Bunti
auf FullDuplex stellen kann, die Linux-Kiste aber nicht!
Folge: Man fährt mit einer Seite Halbduplex und mit der anderen
Vollduplex!
(Egal ob über Switch oder per Crossover)
Und *die* Kombination (Halb auf VollDuplex) bringt erdenmiese
Performance,
das stimmt.

Ich hab neulich genau zu diesem Problem Tests gefahren 
(ich hab arbeitgeberseitig die Möglichkeit, "mal schnell" nen 100MBit 
Workgroup-Switch (Cisco Catalyst 2924XML) mit heim zu nehmen), und dabei
kam sehr
deutlich heraus, das ein korrekt konfiguriertes Linux mit Vollduplex auf
einem 
korrekt konfigurierten Switch mit Vollduplex ziemlich abgeht und etwa
10-20% mehr 
Performance aufs Tapet bringt wie auf einem Halbduplex-Hub.
(Hardware: Dual PIII/450, Intel Etherexpress PCI, 
Client PPro200, 3Com905B Vortex, Win95, CAT 5 Verkabelung)

Damit das klappt, muß folgendes erfüllt sein:
Der Switch muß auf "Autonegotiating" stehen, und muß sich nach Anschluß
des
Linux-Servers auf 100MBit/FullDuplex einstellen. (Auf Switch-Seite
checken!)

Zweite Lösung ist, den Switch fest auf 100MBit/FullDuplex zu stellen, 
*und* die Linuxkiste auch!
Wie das geht: http://cesdis.gsfc.nasa.gov/linux/drivers.

Bei Crossover sollte man die Win-Kiste auf "Auto" stellen, und dann
zusammen-
stöpseln. Manche Win-Treiber sagen einem dann, was anliegt, ansonsten
bleibt bloß
probieren. Netzwerk stressen, wenn die Linux-Kiste danach Kollisionen
sieht,
ists wohl kein FullDuplex...

Die Masche "Ich stell den Switch (die Win-Kiste) auf 100/Full und
stöpsel den Server dran,
der wird sich dann schon auch auf 100/Full einstellen", funktioniert
definitiv
nicht!
Das Ergebnis ist dann Switch (Win) auf 100/Full und Server auf 100/Half,
die Performance
ist am Boden, weil sich Switch und Server ständig die Kollisionen um die
Ohren hauen.

Man sieht das u.U., sogar mit "ifconfig", wenn die Linuxkiste nämlich
massiv "Rahmenfehler" oder "Kollisionen" hochzählt.
Bei FullDuplex gibt es keine Kollisionen, treten trotzdem angeblich
welche auf, dann
stimmt was nicht...

Der Fehler ist übrigens schon gestandenen Netzwerkern passiert,
es muß sich also keiner schämen...:-))

> > Das Problem bei Samba ist meist nicht der Server, sondern der Client:
> > Während Linux als Server noch nahezu perfekt cached und daher bei
> > Filegröße<<Hauptspeicher
> > praktisch aus einer RAM-Disk arbeitet, macht Win95/98/NT das definitiv
> > nicht, d.h. das empfangene/gesendete File wird immer von der Platte
> > geholt, und das verfälscht die Ergebnisse.
> > Speziell bei 100MBit mißt man in 80% aller Fälle den Speed der
> > Windows-Festplatte (meist zwischen
> > 3 und 5 Megabyte/sec) bzw. die Effizienz des Plattencontrollers...
> 
> oder man stellt fest, dass alles, was windows cached, nicht das ist, was es
> cachen sollte, was man daran merken kann, das windows das cached, was
> zuletzt nicht benutzt wurde, und wenn das gerade etwas war, was das kernel
> ploetzlich selber brauch, killt sich windows selbst, auch noch bei 128MB
> ram...
> 
> > Wenn nicht explizit Samba getestet werden soll, so empfiehlt sich als
> > Übertragung
> > ftp. Erstens rechnet der den Speed gleich selber aus :-), zweitens ist
> > das ftp-Protokoll
> > bedeutend effizienter als das LANManager-Gelumpe aus Redmond...
> 
> stimmt

Solong..
mfg Frank.

-- 
Frank Schneider, <spatz1 t-online de>
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
...-.-