Re: Fast Ethernet und Samba

[SPATZ1 t-online de (Frank Schneider)]

Hallo...

robert_wilhelm_land wrote:
> 
> Frank, vielen Dank für Dein Kommentar.
> 
> > ....Also ich meß sowas immer so:
> > Zwei Rechner, 100MBit-Karten auf Halbduplex (wie das bei der 3Com905
> > geht:
> > http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html), ein 100MBit-Hub.
> >
> > Dann ftp-Übertragungen von verschiedenen Filegrößen "von links nach
> > rechts" (nicht gleichzeitig!)
> >
> > Dabei kommen dann bei zwei Linux-Clients Werte zwischen 4 und 6
> > Megabyte/sec heraus.
> > (Je nach Platte, CPU, RAM, etc.)
> >
> > Bei Win und Linux (Samba) sind die Werte etwas niedriger, aber ähnlich.
> 
> Frank, das war eine festeingestellte vollduplex crossover Konfiguration, so
> hatte ich das auch eingangs geschrieben und getan. Wieso hast Du per halfduplex
> getestet?

Weil ich über einen Hub gearbeitet habe. 
Und FullDuplex aufm Hub ist nicht gut....ein Hub kann nur Halbduplex.
Ein Switch könnte FullDuplex....
 
> > Noch ein Problem von BING:
> > Es ignoriert völlig, das der "angebingte" Host ja auch Zeit braucht, um
> > die Pakete zu reflektieren.
> > (Speziell Netzwerkkomponenten tendieren dazu, ein eintreffendes
> > Ping-Paket erstmal 100ms "abtropfen" zu lassen, bevor sie es
> > reflektieren...)
> > Daraus resultieren dann sehr miese Werte (3-5MBit/sec, selbst bei
> > vollgeswitchtem 10MBit-Netz).
> > Bei Modem-Verbindungen stimmen die Werte halbwegs.
> > Bei 100MBit-Netzen würde ich von dem Tool abraten....
> 
> Finde ich interessant, werde mal bei Beowulf nachschauen.
> 
> > ..
> > 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.
> 
> Wie genau funktioniert dieses 'cachen'?(das war ja auch vorher meine Frage).
> Wenn die Dateien auf dem Linux Server auf der HDD liegen dann sind sie ja nicht
> im RAM
> oder swap, höchstens wenn kurz zuvor (wie bei meinem Test) darauf kopiert worden
> sind.

Das Cachen funktioniert so, das die Daten von Platte in den
Hauptspeicher gelesen werden,
und dann von dort "weiterverarbeitet" werden, entweder macht eine
Applikation was damit,
oder ein cp-Befehl schreibt die Daten wieder auf eine Platte.
Nach der Aktion wird aber der Bereich, der von den Daten im RAM belegt
war, *nicht* sofort
wieder gelöscht oder als "frei" markiert, sondern Linux läßt die Daten
einfach stehen.
(Solange, bis eine andere Applikation mehr Speicher anfordert, und
dieser Cachebereich
dazu angenagt werden muß. Applikation geht vor Caching)
Durch dieses "Stehenlassen" merkt Linux beim nächsten Copy-Befehl
(Öffnen desselben Files,
starten derselben Applikation), das die angeforderten Daten schon da
sind und spart sich
das erneute Einlesen. 
Daher der Geschwindigkeitsvorteil.
Der Effekt ist übrigens sogar schon unter DOS bekannt, Programme wie
"smartdrive" machen das da,
wenn auch nicht so effektiv.

> > Also um nen 100MBit-Segment mit nem Pentium PRO zu fluten, dazu hat es
> > bei mir immer gereicht.
> > Natürlich ist der Stack des Kernel 2.2 besser...
> 
> Was genau ist dieses100MBit-Segment ? Ist das der Puffer vom TCP stack der alles
> für IP auseinandernimmt?

Nein, ein "Segment" oder "Netzwerksegment" ist ein Teil eines
Netzwerkes, und zwar der, auf
dem alle Stationen sich jeweils gegenseitig hören und dessen Bandbreite
sie sich teilen.
Man spricht auch von "Kollisionsdomäne".

z.B. ist ein Hub mit 5 Rechnern dran ein Segment.
Ein Switch mit 5 Rechnern ist aber kein Segment, beim Switch hat jeder
Rechner
sein eigenes Segment.

Da sich auf einem Segment alle Stationen die Bandbreite teilen, kann
eine Station dieses
Segment "zumachen", dann benutzt diese Station die komplette Bandbreite,
und der Rest
schaut etwas dumm drein, er bekommt nämlich nur noch einen sehr kleinen
Teil oder gar keinen 
Teil mehr von der Bandbreite ab.
 
> > > > Das sind meine Werte:
> > > > ------------
> > > > W95c                             <---crossover---->  2.0.35,samba-1.9.18p8
> > > > (ohne TCP patch oder TCP tuning)
> > > > K6-2 400, 3com905B TX, UDMA2                     M2 233, 3com905B TX,UDMA2
> > > >
> > > >
> > > > Messhilfsmittel: eine analoge Junghans Funkuhr, Ablesefehler ~0,5sec
> > > >
> > > > -------------------28.8MB (netscape cache folder, 3727 files) kopieren:
> > > > 1a)w95 -> linux 2.0.35   [min:sec]  4:55 - ^= 295sec  -> 28,8/295=0,0977MB/s
> > > > 1b)linux 2.0.35 -> w95              3:25 - ^= 205sec  -> 28,8/205=0,1405MB/s
> >
> > Hier kommen Track-Effekte dazu, die das Ergebnis verfälschen:
> > Jedes winzige File muß geöffnet, geschrieben und wieder geschlossen
> > werden.
> 
> Aber genau das wollte ich ja erfahren. 295s/205s ergibt 1,439. 2,5s/1,5s ergibt
> 1,666 bei prozentualen großen Messfehler - jedoch beide Quotienten liegen nicht
> so weit auseinander.

Ja, das ist dann ein Effekt des verwendeten Dateisystems.
Es kann z.b. sein, das wenn du dasselbe Directory zwischen zwei
UNIX-Maschinen
kopierst und diese nicht per Samba/SMB verbunden hast, sondern per NFS,
das dann völlig
andere Werte herauskommen.
Linux cached in diesem Fall auch die Daten der einzelnen Files, nur
verbraucht der
Overhead von File öffnen/schließen einfach um Faktoren mehr Zeit, als
durch das Caching
gewonnen wird...
 
> > > > -------------------17183KByte  tiff Bild kopieren:
> > > > 2a)w95 -> linux 2.0.35              0:~2,5 -          -> 17183/2,5=6873,2KB/s
> > > > 2b)linux 2.0.35 -> w95              0:~1,5 -          -> 17183/1,5= 11455,3KB/s
> > > > -------------
> >
> > Der letzte Wert dünkt mir etwas hoch, wegen der Meßgenauigkeit (0,5sec)
> > könnte auch eine Meßunsicherheit vorliegen.
> > Sonst sind die Werte aber i.o., Linux ist schneller, klar, er cached das
> > File natürlich,Win95 cached weniger/gar nicht und ist zusätzlich durch einen miesen
> > TCP/IP-Stack im Nachteil.
> 
> Da kann man noch hervoragend tunen, irgendwo in den Samba pages gelesen.

Ist möglich. Viel schlucken auch schlechte Netzwerkkartentreiber.
 
> > Bei einem Crossover-Kabel könnten beide Stationen mit FullDuplex
> > arbeiten, dann wäre evtl. noch mehr drin...
> > Wenn beide LAN-Karten auf "Autosensing" eingestellt waren, könnten sie
> > sich sogar auf 100/Full geeinigt haben...
> 
> Wie gesagt, 100baseTX fest eingestellt.

100BaseTX sagt über das Duplex-Verhalten nichts aus.
100BaseTX heißt 100MBit über Kupferkabel, es gibt auch 100BaseFX, das
wäre 100MBit über Glasfaser,
beide Standards sagen aber nichts über Halb- oder Vollduplex aus...
 
> > Schau mal, ob bei "ifconfig" Kollisionen angezeigt werden: Wenn nicht,
> > arbeiten beide Stationen ziemlich sicher mit FullDuplex.
> > Einen Hinweis kann auch der Kartentreiber auf Windows-Seite geben.
> 
> ifconfig bei 0% Netzlast?

Nein, erstmal einiges drüberjagen, dann ifconfig machen....
Die aktuelle Netzlast ist egal, da ifconfig eh nur Zähler ausgibt, die
der Kartentreiber
aufsummiert...
 
> > > > Schon ziemlich interessant, besonders wenn man das umgekehrte Zeitverhältnis bei
> > > > Bild und Folder beachtet. Samba würde angeblich cachen, vielleicht deshalb -
> > > > aber nach welchen Regeln arbeitet der Algorithmus?
> > > >
> > > > 2b kommt relativ nah an die 100Mbit/s  (^=12800KB/s), die C'T kommt in 16/99 bei
> > > > derselben Karte auf 4111KB/s - aber welche Daten und welcher Richtung?
> >
> > Richtig. Und mit welchem OS und mit welcher Platte ?
> 
> Win: 250 Celeron A (gibts sowas?)  , 64 MB, Platte unbekannt
> Lin: Dual PIII 500 (Dickschiff) , 512MB  (sowas hätte ich gerne), Platte
> unbekannt

Hmm, also die 4MByte/sec dünken mir sehr der Plattenspeed des Win95 zu
sein...
 
> > Die 100Mbit/s  mit 12800KB/s gleichzusetzen, halte ich für sehr gewagt.
> > Das geht bei Netzen mit geregeltem Zugriffsverfahren (FDDI, z.b.), aber
> > nicht bei Ethernet.
> 
> 100MBit/s ^= 12,5MByte/s -> 12,5MByte/s ^= 12800KB/s (weil 1K = 2^10)

Brutto ja, Netto nicht:
Die obige Rechnung vergißt, das ja ein Teil der übertragenen Bytes zu
Fehlerkorrekturzwecken
dient, hinzu kommen die Addressen (min. 18 Byte pro Paket, bei TCP/IP
sogar noch mehr), die ja 
auch Übertragungszeit und Platz benötigen, plus schlußendlich
Re-Transmissions, also erneutes
Senden desselben Paketes weil das erste durch eine Kollision oder sonst
einen Fehler
verlorenging.

Solong..
mfg Frank.

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