Re: NetBSD, ist es wirklich so langsam?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thus "O. Hartmann" <ohartman(at)zedat.fu-berlin.de> spake on Thu, 27 Sep
2007 09:22:33 +0000:

> Timo Schoeler wrote:
> > Thus "O. Hartmann" <ohartman(at)zedat.fu-berlin.de> spake on Thu, 27
> > Sep 2007 08:10:42 +0000:
> >
> >>> Noe, das kann ich so nicht bestätigen; in der Reihe der BSDs
> >>> ergibt sich IMHO die Reihenfolge
> >>>
> >>> NetBSD -> DragonFly -> FreeBSD -> OpenBSD
> >>>
> >>> (von 'schnell' nach 'langsam'),
> >>>
> >>> was auch berüchtigte Benchmarks eines GNU/Linux-Apologeten so
> >>> widerspiegeln.
> >> Das ist sehr interessant, bezieht sich diese
> >> 'Von-Schnell-Nach-Langsam'-Angabe auf das Dateisystem oder auf die
> >> generelle Arbeitsgeschwindigkeit des Systems?
> >
> > Hier erstmal generell, wie sich mir die Systeme im täglichen
> > Gebrauch gegenüber darstellen; wie gesagt, es gibt da einen
> > (deutschen) GNU/Linux-Verblendeten (sorry, aber anders kann man ihn
> > angesichts der enormen Subjektivität seiner Benchmarks nicht
> > nennen), der die BSDs noch in Konkurrenz zu Windows, GNU/Linux und
> > (Open)Solaris gesetzt hat.
>
> Leider habe ich die Entwicklung seit FreeBSD 5.0 (große Enttäuschung)
> aus den Augen verloren, zur Zeit habe ich privat FreeBSD 7.0 im
> Einsatz, auf i386- und amd64-Plattformen.
> Die Gentoo/Linux-Systeme im Betrieb sind recht flott - auf gleicher
> Hardware machen sie einen zügigeren Eindruck als die FreeBSD
> 7.0-Systeme (identische AMD64-Hardware, 64-Bit OS). Leider sind die
> Maschinen in produktion, so daß ich da keine Benchmarks machen kann.
> Mir fehlt die Zeit.

Gentoo habe ich mir auch schon intensivst angeschaut, aber ich bin da
lizenzmäßig eigentlich (sehr) festgelegt. Zudem, und die Erfahrung habe
ich mit NetBSD über Jahre gemacht, kann man ein System auch recht
einfach (aber schwer zu debuggend) 'kaputt-tunen', je nachdem, was der
Compiler so macht. Und da muß ich sagen, daß GCC teilweise
ultragrottigen Code produziert.

> > Im übrigen stört mich die (durch die diversen
> > Sicherheitsmechanismen, auch bei Allokation von Speicher,
> > erklärbare) 'Langsamkeit' von OpenBSD nicht im geringsten, im habe
> > dafür (v.a. im Vgl. mit GNU/Linux) eben nicht mit drei remote
> > expoits wöchentlich zu kämpfen ;)
>
> Stimmt, man muß OpenBSD ja nicht als Serverplatform einsetzen.

:D

Gerade da habe ich sie aber am Start; das entscheidende ist für mich
ein sicheres und stabiles System, also kommt da GNU/Linux nicht in
Frage. Dann die Lizenzproblematik, da kommt für mich GNU/Linux nicht in
Frage und bei FreeBSD sind mir die Bauchschmerzen auch zu arg (wie im
übrigen auch bei NetBSD, leider; es ist aber noch auszuhalten).

Der Punkt ist m.E. der, daß ich mich hier nicht auf synthetische
Benchmarks stütze dahingehend, wieviele Sessions mein Webserver
aufreißen kann ohne in die Knie zu gehen -- da habe ich selbst mit
einer OC-48 ein anderes Nadelöhr, den WAN connect... ;)

> >> Gilt diese Aussage
> >> generell, also für UP und SMP oder nur für SMP-Systeme?
> >
> > Ich würde sagen, generell; so ist OpenBSD recht 'lahm' mit einer CPU
> > als auch im MP-Betrieb, weil (leider) immer noch mit Big Giant Lock
> > arbeitet (wie im übrigen auch DragonFly in den frühen Versionen).
> > FreeBSD und NetBSD sind da schon mit weit besseren MP-Mechanismen
> > ausgestattet und haben die Altlasten schon relativ gut entsorgt. Die
> > größten Fortschritte konnte ich bei NetBSD beobachten, da hat sich
> > sehr viel getan und selbst in den Benchmarks o.g. Person zeigte
> > sich NetBSD AFAIR besonders bei großen Datasets als FreeBSD
> > überlegen.
>
> Könntest Du mir den Link zu besagten Benchmarks senden?

Der (asbach-)uralte:

http://bulk.fefe.de/scalability/

Der neuere vom Linux Talk 2006:

http://bulk.fefe.de/lk2006/bench.html

Aber wie gesagt vorsicht, der Mann ist gnadenlos GNU-lastig.

> Wie gesagt,
> ich kenne derzeit nur einen Benchmark, der im FreeBSD-Forum
> (Performance) diskutiert wurde, das war ein Skalierungstest mit mehr
> als 4 CPUs (max.
> 16) und MySQL.

Da schau ich doch gleich mal rein; MySQL ist da, möchte ich einfach mal
anmerken, allerdings auch nicht geschmacksneutral ;)

> Hier schnitt FreeBSD 7.0 im Durchsatz besser ab als
> Net- und Open-BSD. FreeBSD 7.0 scheint einen deutlichen Sprung nach
> vorne gemacht zu haben, mich würde brennend interessieren welche
> Systeme getestet wurden, die Du oben genannt hast.
>
> Dragonfly-BSD steht derzeit fü¶ mich/uns nicht zur Debatte, da wir
> wegen numerischer Rechnungen ausschließlich 64 Bit OS einsetzen.
>
> >
> >> Ich habe in Erinnerung, daß von allen BSD-Systemen FreeBSD das
> >> schnellere sei. Die SMP-MySQL Bechmarks, die Kris Kennaway vor
> >> einiger Zeit veröffentlichte (SMP Systeme, 8/16 CPUs) gaben
> >> zumindest diesen Eindruck wider.
> >
> > Ich erinnere mich in diesem Kontext an den berühmten Fight auf Apple
> > PowerPC-Hardware, Mac OS X (was ja einen hybriden Mach 2.5-Kernel
> > nutzt und eben keinen (Free)BSD-Kernel, wie aber immer gerne erzählt
> > wird) versus GNU/Linux...
>
> ... das ist leider immer noch nicht ganz aus so manchem
> *BSD-Enthusiastenkopf heraus. Es sind nur die Userland-Programme, die
> aus dem FreeBSD-Umfeld stammen.

Eben.

> >> Grüße,
> >> Oliver
> >
> > Man sollte sich aber nicht nur an Benchmarks orientieren; selbst,
> > wenn ab und an GNU/Linux vorne liegt, denke ich mir, sollte auch
> > mal die Usability gemessen werden. In meinem letzten Kundenprojekt
> > mußte ich mit Red Hat Enterprise Linux arbeiten. Da bekommt die
> > Wendung 'Freude am Leben' leider eine ziemlich einseitige
> > Bedeutung: Nach Feierabend und vor Arbeitsbeginn ;D
>
> Bei mir/uns geht es um die Geschwindigkeit bei numerischen
> Rechnungen, prinzipilell hätte hier Linux ganz klar die Nase vorn,
> weil es eben bessere kommerzielle Compiler gibt. Ich beschränke mich
> aus diversen Gründen auf den gcc 4.2 auf 64 Bit Platformen, eine 2
> Kerne AMD 5400 CPU rechnet unter Gentoo/Linux (2007.1) schneller als
> unter FreeBSD 7.0 (rezentes System).

Interessant. Wir machen hier zur Zeit einige Durchläufe verschiedener
Modelle (Aero- und Hydrodynamik), auf IBM Power und AIX. Nach gut drei
Monaten geteste (auch von x86-Hardware) hat sich das als klarer Favorit
dargestellt, nicht nur wegen des fabelhaften XL C/Fortran Compilers.

> Vermutlich sind es Optimierungen
> bei der Speicherallokation (Linux nutzt wohl MMX/SSE Register für
> Kopierfunktionen, wie sie jüngst bei DragonflyBSD eingeführt wurden
> und die ja derweil bei allen AMD64-kompatiblen CPUs bis mindestens
> SSE2 vorhanden sein müßten!) unter Linux und ein schnelleres
> I/O-/Dateisystem sowie schnellere Scheduler bei SMP-Betrieb.

Aha, wird das Geraffel (sorry) tatsächlich benutzt? Hier läuft eine
IntelliStation POWER 185 Express, die (im Gegensatz zu den CPUs bis
Power5) eben AltiVec hat, was, auch wenn ich da keinen Flamewar
anzetteln möchte, schon vor knapp zehn Jahren da war, wo SSEx noch
hinkommen möchte. Je nach Aufgabe rennt das Teil im Kreis um neueste
Core2-basierte Xeons. (Auch die Statistiken bei Projekten wie
SETI(at)home zeigen dies.)

> RedHat schneidet in der Firma, in der ich arbeite, generell schlecht
> ab, wohl aber, weil deren Enterprise Versionen leider sehr vergattert
> sind und man kaum Optimierungen durchführen kann/darf, ohne gleich in
> Konflikt mit den Vertragsvereinbarungen zu kommen.

Die Vertragsvereinbarungen wären bei dem Kunden überhaupt gar kein
Problem gewesen, das Problem war das GNU-rumgekorkse und das, was die
Jungs 'Paketmanagement' nennen. Debilian enttäuscht ja schon zu oft,
aber das war ja wirklich nur ein Witz. Im Endeffekt macht mans dann wie
unter Solaris und zieht sich massig Tarballs und bringt Zeit mit. Viel
Zeit.

> > MsG,
> >
> > Timo
>
> Gruß Oliver

Gruezi,

Timo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (OpenBSD)

iD4DBQFG/AyCqPA9prlyiHMRAh45AKCMHzJejoKcH4PNaHZASqmDZqFnRACYjP9L
HuEyTrjvsO4PPKUXRrJ1Jw==
=kWR5
-----END PGP SIGNATURE-----

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 27 Sep 2007 - 22:04:34 CEST