Re: Fast Ethernet und Samba

[SPATZ1 t-online de (Frank Schneider)]

robert_wilhelm_land wrote:
> 
> Frank Schneider schrieb:
> 
> > .....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 was cachen allgemein gesehen ist verstehe ich schon, es ging mir nur darum zu wissen ob
> sich Samba wie ein normales Programm verhält und einmal bereits gesehene Daten in einem
> schnellen Speicher bereithält und nicht Daten, die es durch irgendwelche schlaue Algorithmen
> (Voraussage, Abschätzung) in den RAM einbaut.

Also was Samba auf alle Fälle macht, ist, das es den normalen
Linux-Cache nutzt, d.h. es (genauer: Der Kernel) speichert die Files
zwischen.
Ob es darüberhinaus noch mehr macht, weiß ich nicht, nehme ich aber
nicht an.
Der Aufwand wäre sehr hoch, gekoppelt mit der Möglichkeit, sich zu
ver-cachen und dann effektiv
langsamer zu sein als ohne Caching...

> > > > 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.
> 
> Aua! :-)
> Nein hatte ich falsch verstanden, mir sind nur die 'Netzwerkerausdrücke' nicht geläufig. Was
> ein NetzSegment ist war mir schon klar, was mir nicht klar war ist das 486er ein
> FastEthernet Netz nicht schnell genug füttern kann.

Das hab ich nicht gesagt, :-)
Ich meinte nur, das ein PII prinzipiell schneller auf dem Netz ist als
ein 486-er, was mit der unterschiedlichen Speicherbusbreite und Taktrate
zusammenhängt. Ob ein 486-er ein 100Mbit-Segment fluten kann, weiß ich
nicht,
das müßte mal jemand probieren...
 
> > ..> > 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...
> 
> Das vollduplex hatte ich hier verschluckt, war aber bei meinem Report mit den Werten
> aufgeführt.
> 
> > > 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...
> 
> Keine Kollisionen in meinem Fall. Solltest Du Zeit haben wäre ich dankbar für eine Erklärung
> was es sich mit diesen Zählern auf sich hat.

Das spricht für Vollduplex.
Die Zähler selbst sind auch etwas VooDoo für mich, was ich weiß ist:

Frame/Rahmen: 
Es wurden soviele Ethernetpakete gesichtet, die sich nicht an die 
Ethernet-Frame-Regeln (maximal 1520 Byte, minimal 64 Byte, Checksume(n)
richtig)
gehalten haben.

Dropped/Weggeworfen:
Soviele Pakete konnten nicht korrekt vom Netz gelesen oder geschrieben
werden, weil es
Probleme mit dem OS gab, z.b. keine Puffer mehr frei, z.b.
Treiberfehler, etc.
Hat mit dem Netz selbst praktisch nichts zu tun, deutet mehr auf ein
Treiberproblem/CPU/RAM-Problem

Overrun/Überlauf:
Diese Pakete konnten ebenfalls nicht korrekt gelesen/geschrieben werden,
ähnliche Gründe wie oben
(Oder weiß jemand näheres ?)

Collisions/Kollisionen:
Soviele Pakete wurden zerstört, weil gleichzeitig zwei Pakete aufs Netz
gelegt wurden.

> > > 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..
> 
> Frank, das ist doch alles Klar - was mich nur ein wenig wundert ist das ich hier in der
> Liste keine Prügel für meinen eigentlichen Messvorgang bekommen habe  ...   :-)
> Überlege doch mal :  1,5s bei einem von mir angegebenen Fehler von 0.5s. Weißt Du was das
> heißt?  Der Robert ist doch nicht ganz dicht!!!

Hab ich nicht direkt gesagt, ist aber ein Argument...deshalb auch der
Tip mit dem "time cp....",
der mißt nämlich genauer....

> Was interessiert die Fehlerkorrekturen etc bei so einem Error! Ich wollte doch nur grob
> abschätzen, wenn man Messungen durchführt dann baut man sich eine Messreihe auf, man
> wiederholt das Ganze - und wie Du schon gesagt hast - natürlich mit einer größeren Datei,
> dann ist der Messfehler prozentural per Datei nicht so groß.

Richtig. Meßfehler erkennen, minimieren, Reihen messen, Mittelwert
bilden...
 
> Ich muß Dir ein wirklich großen Dankeschön geben da Du schon seit Jahren immer wieder eine
> Wahnsinnig große Mühe bei den Hilfestellungen machst - bei Jedem hier in der Liste. Das
> sollte doch mal gesagt werden.

Danke, Danke...nicht das ich noch rot werde...:-))

Solong..
mfg Frank.

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