Danke :) !

Sollte irgendjemand mit irgendwem aus dem englischsprachigen Raum über dieses Thema diskutieren wollen - ich hab' das Dokument auch auf Englisch geschrieben.

MfG
Quintus

Nachtrag: tja, also ich muss jetzt zugeben, ich bin durch die neuen Erkenntnisse tief erschüttert - sollte Callas nichts Positiveres berichten können oder sich in den nächsten Tagen keine Lösung finden, wie man Samba auf die Performance einer stinknormalen Windows-Netzwerkfreigabe bringt, stell' ich die Sinnhaftigkeit von Linux für mich in Frage - wer verschenkt schon gerne 30-50% Datenperformance bzw -durchsatz?

Geistig arbeite ich schon am "worst case" bzw. "Plan B" - mein derzeitiger Debian-Server könnte zur Firewall degradiert werden und die zentrale Datenhaltung ein Windows-Rechner übernehmen.

Naja, warten wir mal, was die nächsten Erkenntnisse so bringen....

MfG, Quintus
(staying tuned)

also:

Windows-Kiste: Athlon64-3000 mit S-ATA Platte, Windows XP64 Beta

Linux-Kiste: Dual P3-1000, U160 SCSI-Platte an Mylex U160 Controller ( kein Raid, nur 1 Platte ), CentOS 3.3 fully updated.
Neustes Samba rpm ( 3.0.9.E. ...)

Netzwerk verwende ich nicht alleine, daher ist volle Auslastung kaum möglich.

Win to Linux war am langsamsten, Linux to Win und Win to Win ~gleich schnell, aber Linux to Win etwas instabiler.

Pics anbei.

nextes

letztes

ajo: samba in standard config, nix getunt.

Hm......Du kriegst bei win_to_linux ja auch nur um die 50% rüber....auch nicht berühmt. Die Frage ist, warum pulsiert Samba bzw. lässt sich dagegen was tun.?

----

Ich hab' gestern meine neue Storage-HDD gekriegt (eine 300 GB Maxtor) und hab' damit noch unter FC3 getestet - dieselben Ergebnisse. Unter Windows waren die Tests noch ein bißchen besser, weil ich für die ersten Windows-Tests nur mit der allerältesten HDD (40GB) testen konnte.

Aufgrund der großen HDD kann ich endlich mein Video-Projekt mit mehreren Stunden DV-Material sichern - hab' gestern nach den Tests die 300 GB noch auf NTFS umformatiert und z.Z. laufen 99 GB unter Windows drauf - damit mir beim Videoschnittprojekt nichts mehr passiert (ich hab' da jede Menge Arbeit drauf) - der Datentransfer läuft mit 90% Netzauslastung, aalglatt - siehe GIF.

Wie oben schon erwähnt - ich denke über Plan B nach, wenn sich nicht noch was tunen lässt.

MfG
Quintus

Und bei Windows zu Windows auch. Vielleicht liegt es an "Netzwerk verwende ich nicht alleine, daher ist volle Auslastung kaum möglich." ;)

ich werde heute nachmittag die beiden Rechner mit einem ausgekreuzten Kabel direkt zusammenhängen, für aussagekräftigere Vergleiche.

Ich zitier das hier mal stellvertretend.

Linux wegen dieses Threads als Serverbetriebssystem in Mißkredit zu bringen, ist aufgrund falscher Schlußfolgerungen gelinde gesagt Unsinn.

SMB ist ein Protokoll das von MS entwickelt wurde und nicht offen ist, sondern vom Samba-Team in mühevoller Kleinarbeit reverse engineered wurde. Mir erscheint es daher wenig überraschend dass die Performance mit der nativen Implementierung u.U. nicht ganz mithalten kann. Deswegen aber Rückschlüsse auf GNU/Linux als Ganzes ziehen zu wollen, ist relativ sinnlos.

Falls GNU/Linux deine Anforderungen nicht erfüllt, verwende doch einfach Windows. Das aber als "Drohung" in den Raum zu stellen ist IMHO unnötig, denn auf Leute die für eine Community vermutlich noch nie aktiv etwas getan haben, dafür aber oft raunzen kann diese normalerweise recht gut verzichten.

Sorry falls das böse klingt, ist aber nunmal meine Meinung.

Was sind da falsche Schlussfolgerungen?

Wenn man diverse Linux-Artikel in Zeitungen liest, so heißt es meistens als Konklusio, dass Linux für Serverzwecke hervorragend geeignet sei und für Workstations noch Nachholbedarf besteht.

Wenn ich mir nun einen Linux-Datenserver aufsetze und feststelle, dass die Hauptaufgabe Nr. 1 - also die zentrale Datenhaltung - mit 1/3 weniger Perfomance gegenüber einer Win-Netzfreigabe läuft, dann ist die Frage nach der Sinnhaftigkeit IMHO berechtigt.

Hurtige Datenübertragung sollte ja die Hauptaufgabe von Servern sein - und wenn das SMB-Protokoll dafür nix taugt, dann wundert es mich eigentlich, warum die Community da nichts Vernünftigeres entwickelt hat - aber vermutlich hat das wieder rechtliche Gründe.

Sorry - aber ich hab' - mit kräftiger Unterstützung aus dem WCM-Forum - seinerzeit einen Debian-Server aufgesetzt. Es hat mich viele Wochen Forschungsarbeit gekostet und den Kollegen viele Stunden Forums-Support - es hat Spass gemacht und der Server läuft ohne Mucken - aber nach all' der Mühe komm' ich nach 2 Jahren dahinter, dass ein Windows-Fileserver für diese (meine) Aufgabe besser performen würde. Wundert Dich da meine Enttäuschung?

Ich will damit Linux nicht "in Bausch & Bogen" in Misskredit bringen (und kann auch keine "Drohung" nachvollziehen) - aber bei der "Aufwärmübung" zu patzen, tut weh.


MfG
Quintus

Hi citizen!

Ich weiß nicht wie genau du den Thread gelesen hast, aber ich finde es gibt ein paar interessante Dinge nachzuforschen.

Genau aus dem Grund, daß smb nicht offenliegt, hab ich auch mit ftp getestet.

Bei Quintus ist die Performance teilweise wirklich nicht besonders, bei meinen Tests sind die Unterschiede zwar nicht so gewaltig, aber dennoch erkennbar.

Die Tests der anderen bestätigen dies ebenfalls.

Vom Linuxrechner down geht's super und up "pulsiert's" etwas.

Mich würd halt interessieren, wo man beginnt zu debuggen.

bei Windows? z.B
http://www.microsoft.com/technet/pro...g/tcpip03.mspx

bei Linux 2.4?
/etc/sysctl.conf bzw.
/proc/sys/net/ipv4/

Grüße

Manx

*vollunterschreib*.

Ich halt' jetzt nix davon, herum zu polemisieren oder irgend was zu verdammen. Ich wär' an einer Lösung interessiert, die smb performancemäßig in die Gegend eines Windows-Fileservices bringt - wenn das gelingt, ist's keine Frage, dass mein neuer Server wieder unter Linux laufen darf.

MfG, Quintus

so, neuer Test im eigenen Netz, ohen Störgeräusche:

Linux to Windows: geht einwandfrei, stabil mit 88% Netzauslastung.

Windows to Linux,

mit knapp unter 70% Netzwerkauslastung, etwas flackernd.

Problem dürfte hierbei der verwendete Mylex Controller am Linux-Sys sein, dessen Fahnestange bei ~8mbit/s schreibend erreicht ist, was in etwas den etwas unter 70% der 100mbit Leitung entspricht.

falsches Bild, sry

...flackert aber lang nicht so wie bei mir...

MfG, Quintus

Stabilität, Sicherheit und Wartbarkeit sind völlig überbewertet, stimmt. ;)
In diesem Fall wohl eher technische. Im Linux Magazin war vor nicht allzu langer Zeit ein Artikel zum Thema Samba, wo einer der Entwickler meinte dass man davon ausgehen muss das selbst die MS-interne Doku zu SMB ziemlich unvollständig ist. War interessant, bei Bedarf kann ich nachschauen in welcher Ausgabe das genau war.
"Drohung" war schlecht formuliert, aber es klang so als müssten wir traurig sein solltest du jetzt doch wieder Windows einsetzen.
Anstatt zu meckern solltest du dir vielleicht eher überlegen wie du der Community mal was zurückgeben kannst, nein? Hast du dich mal mit den Samba-Entwicklern in Verbindung gesetzt? Deren Bugzilla (oder das Äquivalent) durchsucht? Eine Samba-Mailingliste nach Tipps oder ähnlichem befragt?

Nein? Dann solltest du das vielleicht tun.

CentOS4 Beta ist gestern rausgekommen:

http://lists.caosity.org/pipermail/c...ry/001762.html

:)

Dagegen hab ich nie was gesagt. :)

Nur aus Interesse: hast du vergleichend zu 2.4 auch einen 2.6er getestet?

eigentlich sollte das vorauszusetzen sein, aber seit MS den ewigen Betatest salonfähig gemacht hat, wird das eh nicht mehr so eng gesehen.
01/05

Ich begrüsse es, wenn Windows User versuchen zu Linux wechseln. Wenn du Quintus' Posts über die Monate mitverfolgt hast, weisst du das er umfassend Quellen angezapft hat um das zu vollbringen. Mir ist das vor Jahren auch nur gelungen weil sich in meinem Freundeskreis 2 Linux 'gurus' befinden.

Frustattacken ab und zu sind leider auch bei Linux nicht auzuschliessen, hab ich selbst erfahren müssen. :)

Mit Postings a'la : 'ich will Linux installieren, was muss ich tun', kann ich auch nix anfangen, wenn sich jemand aber bemüht, versuche ich gerne zu helfen und lasse die Belehrungen aussen vor.

Nein. Ja. Jein.

Aber ich möcht' die Unterhaltung nicht auf diese Weise fortsetzen.

------

Würd' ich gerne testen - hält aber meine ISDN-Leitung nicht aus :( :( :(. Und nur wegen Tests will ich auch nicht anderen Leuten auf den Geist gehen ...

Irgendwo war Suse 9.2 auf einer Heft-CD, die ich hier irgendwo herum liegen haben müsste....

MfG
Quintus

Nanana, es ist ja nicht so als hätte ich Quintus noch nie geholfen (z.B. mit seinem spatial Nautilus Problem). Trotzdem hab ich das Gefühl dass die einzige Quelle die er regelmässig anzapft dieses Forum ist, denn bei aller Freundschaft, viele seiner Fragen beantwortet Google recht adäquat und schnell. ;)

BTW: jede Form von Kritik sofort als Belehrung oder Arroganz abzutun, ist unter Umständen auch nicht unbedingt der beste Weg etwas zu lernen. Gerade in Foren kommt sowas oft schlecht rüber, wobei ich die etwas schroffe Art wohl auch IRL hab, wie dir einige hier sicherlich bestätigen können.

Ah wos. Viel zu freunlich Du bist. :ms:

Hallo!

Ich möcht wieder ein paar Erkenntnisse einbringen.

Ich hab die Hardware gewechselt und zwar hab ich die Festplatte des Servers (Wechselrahmen ;) ) (Hitachi Deskstar 7200 rpm 80GB) einfach in den AMD XP 2400+ Rechner gesteckt. (der Default-Debian-Kernel bootet anstandslos).

Die Platte lief im alten Pentium III nur auf UDMA-4 und da lag die maximale Schreibperformance bei ca 8,6 MB/s (lokales Kopieren). Hat mich doch etwas verwundert.
Das ist auch meine Erklärung für den "pulsierenden" Upload.

Ich hab auch den Client getauscht, vom betagten 600er Duron auf einen Centrino Laptop.

Ergebnisse (FTP):

ftp_down:
ftp> get testfile
200 PORT command successful
150 Opening BINARY mode data connection for testfile (1024000000 bytes)
226 Transfer complete.
FTP: 64d Bytes empfangen in 87,67Sekunden 11679,90KB/s

CPU-Auslastung am Client bis zu 85%

ftp_up
ftp> put testfile
200 PORT command successful
150 Opening BINARY mode data connection for testfile
226 Transfer complete.
FTP: 64d Bytes gesendet in 103,36Sekunden 9907,12KB/s
(=> mehr wird die Platte unter UDMA-5 wahrscheinlich nicht bringen!)

SMB:

smb_down ~ 82% Netzauslastung
http://members.aon.at/~dfidesse/lap_smb_down.png

smb_up ~ 72% Netzauslastung
http://members.aon.at/~dfidesse/lap_smb_up.png

Grüße

Manx

PS: @callas
Deine Bilderl hab'n mich motiviert ;)

... und noch Win nach Win:
Laptop auf Duron 600

http://members.aon.at/~dfidesse/win_win.png

.. da schlägt sich Samba ja nicht so schlecht ;)

Manx

CentOS 4 Beta ist identisch mit RHEL4 Beta 2 und deshalb auch nahezu identisch mit Fedora Core 3. Nur ein paar wenige Pakete (wie Kernel) sind anderes.

Ich glaube CentOS 3.3/3.4 x86_64 (für AMD64) wäre derzeit die sinnvollere Installation.

Auch bei Dir "pulst" kaum etwas. Das klingt ja so, als sollte ich das alte Debian 3.0 testweise auf die neue HW tun .... leider geht das nicht so einfach & schnell wie Fedora.

Ich muss allerdings zuerst unseren Urlaubsfilm fertig machen - sonst krieg' ich von meiner besseren Hälfte eine auf die Mutz' (selbige bastelt schon an den Einladungen für die Premiere!).
Danke für den Hinweis - könnte sein, dass ich es auftreiben kann.

MfG, Quintus

Hi Quintus!

Ich tippe bei die eher auf die Hardware (eventuell) ein Chipsatz Problem.

Wenn Du z.B über FTP testest, solltest Du ähnliche Ergebnisse bekommen.

Welche Festplatte verwendest Du zur Zeit?
An welchem Controller P-ATA / S-ATA?

Grüße

Manx

PS: Default Debian Kernel aus SARGE!
(2.4.27-1-386)

Vielleicht eine Auswirkung, weil ich die vorrätige i386-Version anstatt einer x86_64 auf den A64 drauf getan gab'? Wenn dem so ist und Philipp meint...... müsste es dann eigentich mit CentOS 4 Beta x86_64 besser funzen....

FTP hab' ich noch nicht probiert - da müsst' ich mich erst einlesen, vermutlich geht das mit Apache, das ich unter Debian nicht zum Laufen gekriegt hab' (kein Zugriff) -> Forschungsarbeit, geht erst nach Fertigstellung des Urlaubsvideos.

FC3 ist auf einer 80 GB Seagate Barracuda installiert, hängt am P-ATA. Nachdem aber ein Kopieren HDD -> HDD rechnerintern mit > 23 MB funzt, sollte der HDD-Controller kein Thenma sein.

-------------

Ich hab' jetzt eine Quelle in D angezapft (webloader) - Michael tut für ein paar Euros die Versionen auf eine DVD und schickts kurzerhand rüber.

• CentOS 4 Beta x86_64 schickt er mir,
• zu CentOS 3.3/3.4 x86_64 schreibt er:

Zitat:

das ist grad etwas vertrackt: Für CentOS 3.4 find ich ein DVD-ISO, aber nur für i386. Zu 3.3 finde ich ISOs zu x86_64, aber nur CD-Images, keine DVD. Auch den Informationen von Distrowatch.com zufolge besteht die x86_64-Version lediglich aus CDs. Ich würde vorschlagen, dass ich die 4 Images der CentOS 3.4 RC1 (x86_64) herunterlade. Möglicherweise haben Sie aber auch einen Link parat, der mir verborgen geblieben ist.

Soll ich mir auch die V3.3 x86_64 - zusächlich zu CentOS 4 Beta x86_64 - nun auf 4 CDs schicken lassen?

MfG, Quintus

Gerade im EnterpriseKernel verstecken sich aber einige Feinheiten, die die Performance ordentlich voranbringen.

Wir haben die Server von RH8/9 auf RHEL3 upgegraded, das hat ordentlich was gebracht, bei NFS und Samba.

Zitat:

Original geschrieben von Quintus14 FTP hab' ich noch nicht probiert - da müsst' ich mich erst einlesen, vermutlich geht das mit Apache, das ich unter Debian nicht zum Laufen gekriegt hab' (kein Zugriff) -> Forschungsarbeit

Vielleicht krieg' ich es auf die Schnelle hin ... Apache hab' ich mittlerweile nachinstalliert, wie man es startet (Dienst httpd) hab' ich auch gefunden - aber irgendwo müssten doch noch ein paar Einträge in irgendwelche configs rein - freigegebenes Verzeichnis, berechtigte User und so. Unter /etc/httpd gibt's eine conf - schaut aber nicht so aus, als ob da was rein gehört.???

----

Meint Ihr, dass meine "Pulsierungen" was damit zu tun haben könnten, dass ich eine i386-Version auf einem A64 installiert hab'...?

Ich werd' mir die CentOS 4 Beta x86_64 auf jeden Fall kommen lassen (webloader hat sie in der Nacht für mich schon gesaugt).

MfG, Quintus


Nachtrag: die httpd.conf hab' ich gefunden, user eingetragen, Listen steht auf 80, DocumentRoot steht nun auf /mnt/video, restartet - Zugriff funzt noch nicht. Hoffentlich nur mehr eine Kleinigkeit...

Ja, ich würde beides nehmen.

Den Enterprise Kernel von CentOS 4 kann man auch auf Fedora Core 3 installieren:
rpm -ivh --force http://beta.centos.org/centos/4.0bet...75_EL.i686.rpm

Der Kernel sollte danach im GRUB Menü auswählbar sein. Allerdings dürfte der einzige Unterschied einige fehlende Treiber (Firewire usw) sein.

Auf dem Windows Rechner irgendeinen ftp-Server aufspielen?
Linux: http://www.siliconvalleyccie.com/lin...m#_Toc92808795 ?

Zitat:

rpm -ivh --force http://beta.centos.org/centos/4.0bet...75_EL.i686.rpm

Hab' ich mal am Terminal eingegeben - er sagt mir aber nicht, ob er was tut oder ich vergebens wart', dass der Kernel über die Leitung tröpfelt...nur blinkender cursor. Die Internet-Zugriffszeiten am anderen PC weisen eher darauf hin, dass im Hintergrund nix läuft. Ich glaub', ich lad' mir den Kernel mal unter Windows runter.

Zitat:

Auf dem Windows Rechner irgendeinen ftp-Server aufspielen?

Eigentlich wollte ich unter FC3 einen FTP-Dienst anbieten, damit ich von einem Windows-Rechner testweise einen FTP-DL starten kann - ich nehm' dazu immer den Win(Total-)Commander.

MfG, Quintus

So - ich hab' den Kernel mal downgeladen und installiert - here the results:

• angefangen hat es erfreulich - relativ hohe Auslastung, Pulsieren noch da, aber nicht mehr so hohe Amplitude, ...
• ...aber bei ca. 30% des AVIs ging die Netzauslasung auf 0 - der File war hier NOCH NICHT zu Ende,
• dann unerklärliche Kunstpause,
• dann pulsierte die Übertragungsrate so um die 30-40% weiter...

Was sagt uns das jetzt? Auf jeden Fall, dass die Installation bzw. der Kernel da doch eine Rolle spielt - hier hat also MANX anscheinend richtig getippt.

Bis morgen wird sich die Übersendung der CentOS 4 Beta x86_64-DVD und der V3.3 x86_64-CDs natürlich nicht ausgehen, wird vermutlich Anfang kommender Woche werden.

MfG, Quintus

Beim DL sieht es so aus - siehe GIF. 450 Sekunden für meinen 3,74GB-AVI.

MfG, Quintus

Fedora sollte den vsftpd standardmässig dabei haben.

Falls nicht, mit 'yum install vsftpd' übers i-net oder mit dem Packetmanager in der graphischen Oberfläche von DVD nachinstallieren.

hier:

http://squidward.mit.edu/rhel-doc/RH-DOCS/rhel-rg-en-3/

gibts anleitungen zur config.

Danke, Callas, für den Tip mit vsftpd - ich konnte dadurch die ftp-Verbindung testen :).

Die Testergebnisse sowohl mit dem EL-Kernel als auch mit dem Standard-FC3-Kernel hab' ich der Übersichtlichkeit wegen an meinem Dokumt hinten dran gehängt: siehe hier.

Was können wir daraus interpretieren? Ich seh' mal:

• die FTP-Datenübertragung liegt WEIT über smb - wir können daher Fehler an der HW oder am Controller-Treiber ausschließen,
• der EL.i686-Kernel zackt viel weniger herum als der FC3-Kernel,
• so alle Minute gibt's aber auch beim EL.i686-Kernel eine Zacke - warum? Weil ich nur mit einer HDD unterwegs bin?

Was heißt das jetzt unterm Strich? Soll ich jetzt eine Distri/Kernel nach der/dem anderen ausprobieren...?

Thx, Quintus

Noch ein Test: neuer Kernel EL.i686, smb - siehe GIF: stellt zwischendurch die Arbeit ein (der File war noch nicht fertig übertragen)...

MfG, Quintus

du könntest auf dem alten server einfach mal wie ich mal ein kernel update probieren. ein update auf 2.6 brachte mir damals einen spürbaren leistungszuwachs.

http://www.backports.org/debian/dist...e-2.4.27-i386/
http://www.backports.org/debian/dist...ge-2.6.7-i386/