AIM-Benchmark: freie und eingeschr. freie Unices
Helmut Schellong
http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
www.schellong.de www.schellong.biz
home.t-online.de/home/schellong sche...@t-online.de
Lukas Ertl
>
> http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
Und was heißt das? Ich meine, ich sehe die Zahlen, aber ich kenne den
Benchmark nicht und kann sie deshalb nicht interpretieren...
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| Bugs don't happen because you do something. Bugs just are. |
+-- Vienna University Computer Center -- Phone: ++43 (1) 4277-14073 --+
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> wrote:
>
>>http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
>
>
> Und was heißt das? Ich meine, ich sehe die Zahlen, aber ich kenne den
> Benchmark nicht und kann sie deshalb nicht interpretieren...
Na, da bist Du der erste, der da nichts interpretieren kann.
Sogar Helmut Leitner, frischer Win-->Linux-Umsteiger, konnte da alles sofort
interpretieren.
Lukas Ertl
> Lukas Ertl wrote:
>> Helmut Schellong <sche...@t-online.de> wrote:
>>
>>>http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
>>
>> Und was heißt das? Ich meine, ich sehe die Zahlen, aber ich kenne den
>> Benchmark nicht und kann sie deshalb nicht interpretieren...
>
> Na, da bist Du der erste, der da nichts interpretieren kann.
Vielleicht bin ich nur der erste, der dich drauf angesprochen hat. Also,
kannst du nun die Zahlenkolonnen ein bißchen entwirren?
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| In the beginning was the word, but when the second word |
| was added, there was trouble, for with it came syntax. |
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> wrote:
>
>>Lukas Ertl wrote:
>>
>>>Helmut Schellong <sche...@t-online.de> wrote:
>>>
>>>
>>>>http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
>>>
>>>Und was heißt das? Ich meine, ich sehe die Zahlen, aber ich kenne den
>>>Benchmark nicht und kann sie deshalb nicht interpretieren...
>>
>>Na, da bist Du der erste, der da nichts interpretieren kann.
>
>
> Vielleicht bin ich nur der erste, der dich drauf angesprochen hat. Also,
> kannst du nun die Zahlenkolonnen ein bißchen entwirren?
Die sind zweidimensional sortiert.
Schau dort die *zweite* Tabelle *auch* an.
Ansonsten ist der Test+Doku download-bar auf:
http://www.wikiservice.at/dse/wiki.cgi?FreeBSD
Falls dieses alles nicht hilft, kann ich nicht mehr ...
Michael Gebetsroither
> http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
also suse7.3 hat einen nicht wirklich berühmten kernel. außerdem... auf
welche hardware wurden die kernel optimiert, vorallem bei freebsd hab
ich da keine ahnung wie es mit dem Standartkernel aussieht.
Dann die Shellscripts pro Sekunde... mit welcher Shell wurde getestet
(bash, ksh, ...). Was bedeutet eigentlich die Shellscripts pro Sekunde?
Wieviel Shellscripts gleichzeitig laufen, wieviel in 1s gestartet
werden konnten, oder ...? Das Starten sagt nichts über die
Ausführungsgeschwindigkeit aus.
Die Frage der Optimierung der verschiedenen Kernel kam mir weil ich den
Wert der "Program Loads per second" doch etwas krass fand. IMHO könnten
dort doch ein Kernel (der von Freebsd) mit den MMX registern beim
memcpy arbeiten, dann gehts klar sehr viel schneller.
Auch komisch finde ich das Suse7.3 obwohl es einen "schlechten" (total
unausgereiften) Kernel verwenden bei der "System Memory Allocations per
second" und "System Allocations & Pages per second" so weit vorne
liegt, obwohl doch genau die VM bei dem Kernel die größte Schwachstelle
war.
Alles in allem schaut mir der Benchmark irgendwie "komisch" aus,
vorallem weil so gut wie garnichts über die Testumgebung gesagt wird
und weil der Vergleich bei Linux mit sehr veralteten Kernels gemacht
wird (wen interressiert heute Suse6.3). was noch zu bemerken wäre ist
das ich es nicht verstehen kann wieso dort eigentlich Suse steht. Die
Distribution ist egal, wichtig ist der Kernel und die Patches welche
die verschiedenen Distributoren eigenmächtig in den Kernel ihrer
Softwarepackete stecken.
also die Angabe der Kernelversionsnummer und der enthaltenen patches
gegenüber einem vanilla Kernel wäre sehr viel zweckmäßiger.
Der Bench ist vorallem unfair gegenüber Linux weil alle getesteten
Linuxe veraltet sind (zum teil sehr stark) und weil vorallem der Kernel
der Suse7.3 große Probleme hat (nur eine Übergangslösung).
hint: test mit _eigenem_ Kernel (für Linux): Linux Kernel
versionsnummern 2.2.20 und 2.4.18 (vielleicht interessant wäre noch
2.5.11, aber der is eben in Entwicklung), mit allen Möglichen
Optimierungen. soweit das geht auch für Freebsd.
mfg michael
--
/*you can point a person the way TO learn
but you cant 'teach' a person to 'learn'*/
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> wrote in de.comp.os.unix.bsd:
>
>
>>http://www.wikiservice.at/dse/wiki.cgi?FreeBSD/BenchMarks
>
>
> also suse7.3 hat einen nicht wirklich berühmten kernel. außerdem... auf
Das höre ich jedesmal, sobald eine Nachfolgeversion 1 Woche auf dem Markt ist.
Meines Wissens war der 2.2 fehlerhaft.
SuSE 7.3 hat Kernel 2.4.10.
2.4.18 wird ja wohl kaum eine wesentlich andere Performance haben;
2.4 hat ja schon etwas weniger als 2.2...
> welche hardware wurden die kernel optimiert, vorallem bei freebsd hab
> ich da keine ahnung wie es mit dem Standartkernel aussieht.
Alle Kernel sind 686er/Pentium-Kernel.
> Dann die Shellscripts pro Sekunde... mit welcher Shell wurde getestet
> (bash, ksh, ...). Was bedeutet eigentlich die Shellscripts pro Sekunde?
> Wieviel Shellscripts gleichzeitig laufen, wieviel in 1s gestartet
> werden konnten, oder ...? Das Starten sagt nichts über die
> Ausführungsgeschwindigkeit aus.
Der AIM-Bench verlangt das 'sh'-Verzeichnis als Parameter bei S9setup.
Folglich wird überall /bin/sh verwendet.
Unter Linux ist das wohl ein Link auf bash, und bash ist bekanntlich
sehr groß und sehr langsam.
> Die Frage der Optimierung der verschiedenen Kernel kam mir weil ich den
> Wert der "Program Loads per second" doch etwas krass fand. IMHO könnten
> dort doch ein Kernel (der von Freebsd) mit den MMX registern beim
> memcpy arbeiten, dann gehts klar sehr viel schneller.
Es wurde *alles* in der Standard-Einstellung belassen - *alles*.
>
> Auch komisch finde ich das Suse7.3 obwohl es einen "schlechten" (total
> unausgereiften) Kernel verwenden bei der "System Memory Allocations per
> second" und "System Allocations & Pages per second" so weit vorne
> liegt, obwohl doch genau die VM bei dem Kernel die größte Schwachstelle
> war.
Wenn Fehler beseitigt werden, wird die fehlerbereinigte Software
meistens langsamer, weil sie zuvor 'leichtsinnig' schnell war.
> Alles in allem schaut mir der Benchmark irgendwie "komisch" aus,
> vorallem weil so gut wie garnichts über die Testumgebung gesagt wird
Was denn noch neben: BS, BS-Version, Test-Festplatte, Test-Filesystem, CPU?
> und weil der Vergleich bei Linux mit sehr veralteten Kernels gemacht
> wird (wen interressiert heute Suse6.3). was noch zu bemerken wäre ist
> das ich es nicht verstehen kann wieso dort eigentlich Suse steht. Die
> Distribution ist egal, wichtig ist der Kernel und die Patches welche
> die verschiedenen Distributoren eigenmächtig in den Kernel ihrer
> Softwarepackete stecken.
> also die Angabe der Kernelversionsnummer und der enthaltenen patches
> gegenüber einem vanilla Kernel wäre sehr viel zweckmäßiger.
>
> Der Bench ist vorallem unfair gegenüber Linux weil alle getesteten
> Linuxe veraltet sind (zum teil sehr stark) und weil vorallem der Kernel
> der Suse7.3 große Probleme hat (nur eine Übergangslösung).
>
> hint: test mit _eigenem_ Kernel (für Linux): Linux Kernel
> versionsnummern 2.2.20 und 2.4.18 (vielleicht interessant wäre noch
> 2.5.11, aber der is eben in Entwicklung), mit allen Möglichen
> Optimierungen. soweit das geht auch für Freebsd.
Was Du hier willst, ist ein unseriöser Test.
Es geht darum, Betriebssysteme in vollkommen gleicher Weise zu testen,
die von normalen Original-CD-Sets kommen und normal installiert werden.
Der AIM-Bench ist download-bar; jeder kann ergänzende Vergleichstests
vornehmen, und die AIM-Doku lesen und die AIM-Quellen ansehen.
Michael Gebetsroither
de.comp.os.unix.bsd:
> Michael Gebetsroither wrote:
> > also suse7.3 hat einen nicht wirklich berühmten kernel.
> > außerdem... auf
> Das höre ich jedesmal, sobald eine Nachfolgeversion 1 Woche auf
> dem Markt ist.
du schließt aber nicht schon wieder auf Suse8.0, denn genau _das_ ist
das was bei Linux eben Swachsinn ist. Der Kernel der Suse Distri ist
kein originalkernel suse hat ihn gepatcht im bezug auf die VM (imho
ist dort ein ac patch drinnen), eben deswegen weil die vm im 2.4.10
schlecht war.
DU _darfst_ bei Linux nicht eine Distribution mit dem Kernel
gleichsetzten, das ist was total verschiedenes!
> Meines Wissens war der 2.2 fehlerhaft.
_Autsch_!
nein der 2.2 ist sehr stabil, vorallem 2.2.20 ist ein sehr guter
Kernel. Erst mit der Version 2.4.18 kommt die 2.4er Kernelreihe an
den 2.2.20 heran. Die Kernelversion 2.4.19preX hat einige sehr gute
Geschwindigkeitsverbesserungen gegenüber 2.4.18 also wirds
geschwindigkeitsmäßig auch besser.
> SuSE 7.3 hat Kernel 2.4.10.
> 2.4.18 wird ja wohl kaum eine wesentlich andere Performance haben;
was sollen die einfach in den Raum gesetzten und völlig falschen
Vermutungen. Schau dir mal das Changelog an wieviel sich zwischen den
Versionen 2.4.10 und 2.4.18 getan hat! Die gesamte VM wurde
ausgewechselt (durch eine schnellere und stabilere Version), ...
> 2.4 hat ja schon etwas weniger als 2.2...
ja etwas, aber die 2.4er Serie wird die 2.2er sicher noch überholen.
aber er ist auf modernen Systemen mit den entsprechenden patches
(low-latency patch, ...) schon um einiges schneller. Außerdem bietet
der 2.4er Funktionen ohne die man heute eigentlich nicht mehr
auskommt.
> Der AIM-Bench verlangt das 'sh'-Verzeichnis als Parameter bei
> S9setup. Folglich wird überall /bin/sh verwendet.
na super. /bin/sh ist ein symlink und sagt rein garnichts darüber aus
welcher Shell wirklich genommen wurde, versuchs doch mal mit ksh.
Wenn dann sollte ein ordentlicher Test /bin/bash verwenden und kein
Symlink bei dem man nicht weiß welcher Shell dahintersteckt.
> Unter Linux ist das wohl ein Link auf bash, und bash ist
> bekanntlich sehr groß und sehr langsam.
ja meistens.
aber du hast noch immer nicht gesagt was wirklich gemessen wird. Sind
es die gestarteten Shellscripts pro Sekunde?
> Es wurde *alles* in der Standard-Einstellung belassen - *alles*.
Ich wollte eigentlich damit aus drücken das es nicht klar ist _was_
die Standarteinstellungen sind.
Dh. du testest nicht Linux sondern SuSe mit allen seinen Eigenheiten.
> Wenn Fehler beseitigt werden, wird die fehlerbereinigte Software
> meistens langsamer, weil sie zuvor 'leichtsinnig' schnell war.
Es wurden keine Fehler beseitigt sondern die VM _komplett_
ausgewechselt.
Und leichtsinnig schnell ist bei Linux nichts, nur so schnell wie
möglich und die neue VM ist noch schneller als die jetzige.
> > Alles in allem schaut mir der Benchmark irgendwie "komisch" aus,
> > vorallem weil so gut wie garnichts über die Testumgebung gesagt
> > wird
> Was denn noch neben: BS, BS-Version, Test-Festplatte,
> Test-Filesystem, CPU?
Weil du sagst alles wurde auf Standart belassen. Nur du hast den Suse
standart gemessen und der ist nicht gerade das beste.
außerdem was bringt mir das Dateisystem wenn du nicht mal die Type
angibst, bei reiserfs hat sich _sehr_ viel getan, dh. reiserfs als
Beschreibung reicht bei weitem nicht.
> > hint: test mit _eigenem_ Kernel (für Linux): Linux Kernel
> > versionsnummern 2.2.20 und 2.4.18 (vielleicht interessant wäre
> > noch 2.5.11, aber der is eben in Entwicklung), mit allen
> > Möglichen Optimierungen. soweit das geht auch für Freebsd.
>
> Was Du hier willst, ist ein unseriöser Test.
nein was du gemacht hast ist unseriös!
Du kannst nichtmal Linux selber und die verschiedenen Distributionen
auseinanderhalten. Geschweigedenn das du bei Linux betakernels zum
benchmarken hernimmst und dann netmal die Versionsnummern angibst
(nein ich installier mir kein Suse damit ich seh welche versionen
verwendet wurden).
> Es geht darum, Betriebssysteme in vollkommen gleicher Weise zu
> testen, die von normalen Original-CD-Sets kommen und normal
> installiert werden.
Die Betriebssysteme wurden weder in gleicher Weise noch fair
getestet.
> Der AIM-Bench ist download-bar; jeder kann ergänzende
> Vergleichstests vornehmen, und die AIM-Doku lesen und die
> AIM-Quellen ansehen.
nein die arbeit eines fairen Vergleichstest tu ich mir nicht an. Man
muss jedes OS vorausschauend configurieren und auf gleiche
Testbedingungen achten. Und vorallem, der Fairness halber, nicht bei
irgendeinem OS eine Betaversion zum testen nehmen. Sondern eine
Halbwegs akutelle Version.
Vergiss deine benchmarks mit Suse, auch die v8.0 ist nicht gerade das
beste.
wenn du gleiche Testbedingungen haben willst dann musst du jedes
deiner OS richtig und gleich configurieren.
also wenn das eine z.b. die MMX register für memcpy verwendet dann
müssen das die anderen auch tun (egal wie es in der
Standartinstallation ist).
Was du getan hast ist kein Vergleich zwischen OS sondern nur ein
simpler vergleich zwischen Standartinstallationen (mit ihren großen
Fehlern, vorallem bei Suse und _vorallem_ bei suse7.3).
du hast weder die _wichtigen_ versionsnummern noch das patchlevel des
kernels angegeben (der genau für 2.4.10-2.4.16 extrem wichtig ist,
weil dort die vanilla Kernel fast unverwendbar sind). Die Testwerte
sagen zum teil nicht viel über die Reale leistungsfähigkeit aus, weil
sie zwar schöne Werte liefern, die aber meistens net wirklich wichtig
sind.
dh => dein bench liefert zwar schöne Werte (ja er liefert vorallem
Werte), aber wirklich viel aussagen tut er nicht. Mag sein das der
Benchmark für Freebsd aussagekräftig ist (da kann ich nicht viel
sagen weil das os kenn ich nicht sehr gut), aber für Linux ist der
Benchmark definitiv unbrauchbar!
im allgemeinen kommt mir halt vor das du bei Linux nicht so richtig
zwischen linux und Suse unterscheiden kannst aber das machen Suse
Benutzer _meistens_ (da sie meistens anfänger sind und nicht sich
nicht wiklich mit Linux beschäftigen).
Dein Bench ist ein "Anfängerbenchmark" und sagt nicht viel über die
ware Leistungsfähigkeit von Linux aus (keine Ahnung wie "schlecht" du
bei den anderen OS's getestet hast)!
Standartinstallationen zu vergleichen kann jeder, aber faire
Benchmarks traue ich nicht sehr vielen Leuten zu, da es die meisten
Leute nicht können und von rest sich nur sehr wenige die Zeit dafür
nehmen.
mfg michael
--
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> wrote in
> de.comp.os.unix.bsd:
>
>
>>Michael Gebetsroither wrote:
>>SuSE 7.3 hat Kernel 2.4.10.
>>2.4.18 wird ja wohl kaum eine wesentlich andere Performance haben;
>
>
> was sollen die einfach in den Raum gesetzten und völlig falschen
> Vermutungen. Schau dir mal das Changelog an wieviel sich zwischen den
> Versionen 2.4.10 und 2.4.18 getan hat! Die gesamte VM wurde
> ausgewechselt (durch eine schnellere und stabilere Version), ...
Dann meß doch beide mal durch. Beide ohne eigene Optimierungen.
>>Der AIM-Bench verlangt das 'sh'-Verzeichnis als Parameter bei
>>S9setup. Folglich wird überall /bin/sh verwendet.
>
>
> na super. /bin/sh ist ein symlink und sagt rein garnichts darüber aus
> welcher Shell wirklich genommen wurde, versuchs doch mal mit ksh.
> Wenn dann sollte ein ordentlicher Test /bin/bash verwenden und kein
> Symlink bei dem man nicht weiß welcher Shell dahintersteckt.
Doch, weiß man doch, weil ich alles im Lieferzustand beließ.
>
>
>>Unter Linux ist das wohl ein Link auf bash, und bash ist
>>bekanntlich sehr groß und sehr langsam.
>
>
> ja meistens.
> aber du hast noch immer nicht gesagt was wirklich gemessen wird. Sind
> es die gestarteten Shellscripts pro Sekunde?
Eigentlich ist das irrelevant, weil der Test für alle Testkandidaten
vollkommen identisch war.
Es werden Shell-Scripts ausgeführt, die in der ersten Zeile
#!/bin/sh
stehen haben.
>>Es wurde *alles* in der Standard-Einstellung belassen - *alles*.
>
>
> Ich wollte eigentlich damit aus drücken das es nicht klar ist _was_
> die Standarteinstellungen sind.
Gerade die Standard-Einstellungen sind doch stets allseits bekannt.
> Dh. du testest nicht Linux sondern SuSe mit allen seinen Eigenheiten.
Genau, deshalb steht ja auch in der Titelzeile: "SuSE 7.3"
>>>Alles in allem schaut mir der Benchmark irgendwie "komisch" aus,
>>>vorallem weil so gut wie garnichts über die Testumgebung gesagt
>>>wird
>>
>>Was denn noch neben: BS, BS-Version, Test-Festplatte,
>>Test-Filesystem, CPU?
>
>
> Weil du sagst alles wurde auf Standart belassen. Nur du hast den Suse
> standart gemessen und der ist nicht gerade das beste.
> außerdem was bringt mir das Dateisystem wenn du nicht mal die Type
> angibst, bei reiserfs hat sich _sehr_ viel getan, dh. reiserfs als
> Beschreibung reicht bei weitem nicht.
SuSE 7.3: mkreiserfs /dev/hdb8
Standard - das was da ist.
>>>hint: test mit _eigenem_ Kernel (für Linux): Linux Kernel
>>>versionsnummern 2.2.20 und 2.4.18 (vielleicht interessant wäre
>>>noch 2.5.11, aber der is eben in Entwicklung), mit allen
>>>Möglichen Optimierungen. soweit das geht auch für Freebsd.
>>
>>Was Du hier willst, ist ein unseriöser Test.
>
>
> nein was du gemacht hast ist unseriös!
> Du kannst nichtmal Linux selber und die verschiedenen Distributionen
> auseinanderhalten. Geschweigedenn das du bei Linux betakernels zum
> benchmarken hernimmst und dann netmal die Versionsnummern angibst
> (nein ich installier mir kein Suse damit ich seh welche versionen
> verwendet wurden).
Es ist allgemein bekannt, was SuSE bei 7.3 für einen Kernel liefert.
Die Kernel-Version ist zudem irrelevant, da das kein Kernel-Vergleichs-Bench
war, sondern ein Unix-System-Vergleich.
>>Es geht darum, Betriebssysteme in vollkommen gleicher Weise zu
>>testen, die von normalen Original-CD-Sets kommen und normal
>>installiert werden.
>
>
> Die Betriebssysteme wurden weder in gleicher Weise noch fair
> getestet.
>
>
>>Der AIM-Bench ist download-bar; jeder kann ergänzende
>>Vergleichstests vornehmen, und die AIM-Doku lesen und die
>>AIM-Quellen ansehen.
>
>
> nein die arbeit eines fairen Vergleichstest tu ich mir nicht an. Man
> muss jedes OS vorausschauend configurieren und auf gleiche
> Testbedingungen achten. Und vorallem, der Fairness halber, nicht bei
> irgendeinem OS eine Betaversion zum testen nehmen. Sondern eine
> Halbwegs akutelle Version.
Ach, SuSE 7.3 ist ein Beta-Betriebssystem?
>
> Vergiss deine benchmarks mit Suse, auch die v8.0 ist nicht gerade das
> beste.
Ach, die allerneueste Version 8.0 auch?
> wenn du gleiche Testbedingungen haben willst dann musst du jedes
> deiner OS richtig und gleich configurieren.
> also wenn das eine z.b. die MMX register für memcpy verwendet dann
> müssen das die anderen auch tun (egal wie es in der
> Standartinstallation ist).
Und wenn das ein System gar nicht kann?
> Was du getan hast ist kein Vergleich zwischen OS sondern nur ein
> simpler vergleich zwischen Standartinstallationen (mit ihren großen
Genau das wollte ich auch.
> Fehlern, vorallem bei Suse und _vorallem_ bei suse7.3).
Welches Linux-System sollte ich denn Deiner Meinung nach testen,
zum Vergleich mit den anderen Testkandidaten?
> du hast weder die _wichtigen_ versionsnummern noch das patchlevel des
> kernels angegeben (der genau für 2.4.10-2.4.16 extrem wichtig ist,
> weil dort die vanilla Kernel fast unverwendbar sind). Die Testwerte
> sagen zum teil nicht viel über die Reale leistungsfähigkeit aus, weil
> sie zwar schöne Werte liefern, die aber meistens net wirklich wichtig
> sind.
Sag das mal den Firmen AIM und Caldera Inc.
Was außer den Testwerten ist denn noch wichtig - für alle Testkandidaten?
> dh => dein bench liefert zwar schöne Werte (ja er liefert vorallem
> Werte), aber wirklich viel aussagen tut er nicht. Mag sein das der
> Benchmark für Freebsd aussagekräftig ist (da kann ich nicht viel
> sagen weil das os kenn ich nicht sehr gut), aber für Linux ist der
> Benchmark definitiv unbrauchbar!
Dann ist Linux aber ein seltsames Betriebssytem -
das einzige, für den dieser AIM-Bench unbrauchbar ist.
> im allgemeinen kommt mir halt vor das du bei Linux nicht so richtig
> zwischen linux und Suse unterscheiden kannst aber das machen Suse
> Benutzer _meistens_ (da sie meistens anfänger sind und nicht sich
> nicht wiklich mit Linux beschäftigen).
Von welchem "Linux" redest Du hier?
Zwischen Linux und SuSE-Linux gibt es also einen Unterschied.
Ich kann ihn Dir nennen: "Linux" ist *nur* ein Kernel.
SuSE-Linux ist ein vollständiges Betriebssystem.
>
> Dein Bench ist ein "Anfängerbenchmark" und sagt nicht viel über die
> ware Leistungsfähigkeit von Linux aus (keine Ahnung wie "schlecht" du
> bei den anderen OS's getestet hast)!
Wie meinst Du das?
Ich habe alle Testkandidaten unter vollkommen gleichen Bedingungen getestet.
Willst Du *ungleiche* Bedingungen?
> Standartinstallationen zu vergleichen kann jeder, aber faire
> Benchmarks traue ich nicht sehr vielen Leuten zu, da es die meisten
> Leute nicht können und von rest sich nur sehr wenige die Zeit dafür
> nehmen.
Du gehörst zu denjenigen, die sich dafür keinerlei Zeit nehmen wollen,
wie Du oben sagtest.
Patrick M. Hausen
Michael Gebetsroither <micha...@gmx.at> wrote:
> Helmut Schellong <sche...@t-online.de> wrote in
> de.comp.os.unix.bsd:
> du schließt aber nicht schon wieder auf Suse8.0, denn genau _das_ ist
> das was bei Linux eben Swachsinn ist. Der Kernel der Suse Distri ist
> kein originalkernel suse hat ihn gepatcht im bezug auf die VM (imho
> ist dort ein ac patch drinnen), eben deswegen weil die vm im 2.4.10
> schlecht war.
> DU _darfst_ bei Linux nicht eine Distribution mit dem Kernel
> gleichsetzten, das ist was total verschiedenes!
Das hat er auch nicht. Was er getestet hat, ist die Performance von
_Produkten_, so wie sie beim Endanwender in der Standardinstallation
ankommt. Das _ist_ serioes, da man nur _Produkte_ miteinander
vergleichen kann.
Kein Mensch wird in einer RZ-Umgebung mit einigen Dutzend Servern
ueberall seine handoptimierte Kernel-Version zusammen mit der
Super-Glibc und Version X, Y, und Z von den Tools soundso
installieren - das ist nicht sinnvoll wartbar.
Man installiert FreeBSD 4.5 (z.B.) und trackt dann RELENG_4_5,
was einem aktuelle Security- aber _keine_ Feature- und Performance-
Verbesserungen bringt, weil sich bei RELENG_4 eben auch mal so viel
aendert, dass eine Andwenung neu compiliert werden muss.
Tut mir leid, aber fuer www.grossefirma.de ist es nicht akzeptabel,
laenger als 5 Minuten fuer einen Reboot offline zu sein - und der
auch noch nachts um 3.
Das ist nach allem was ich weiss, in der Linux-Welt identisch.
Man kann Suse 7.3 installieren oder Redhat 7.irgendwas oder
Mandrake soundso ... und dann installiert man die offiziellen
Bugfixes des Herstellers und belaesst es dabei. Wenn man auf
einem Single-User-Hobby-System oder auf dem einzigen Server
eines Instituts, der von einem "Linux-Freak" betreut wird,
eine spezielle Kernelversion installiert, ist das was anderes.
Im ernsthaften Betrieb tut man _alles_ um so nah wie moeglich
an der Standardinstallation des Softwarelieferanten zu bleiben
und so wenig eigene Arbeit wie moeglich zu haben.
Und dass Linux in einem "stable" Kernel mal eben das gesamte
VM auswechselt, ist etwas, was den Admin eines RZ nicht
zu interessieren hat - und was ganz nebenbei einiges ueber
die katastrophale Methodik bei der Softwareentwicklung im
Linux-Umfeld aussagt. Aber ich schweife ab - gleich sind wir
bei "Linux considered harmful" ;-))))
> Weil du sagst alles wurde auf Standart belassen. Nur du hast den Suse
> standart gemessen und der ist nicht gerade das beste.
Der ist aber das einzige, was man _sinnvoll_ messen kann.
Den Suse-Standard, den Redhat-Standard, den Mandrake-Standard,
den ...
Insofern darfst Du von Helmut berechtigterweise eine Erweiterung
der Tests um zumindest ein oder zwei weitere aktuelle Distributionen
wuenschen/fordern, wenn dein Punkt ist, dass Suse nicht taugt.
Wenn Redhat aber genauso schlecht ist, dann sagt der Benchmark
genau dieses: Linux kann man ohne Insider-Knowhow und handoptimierung
nicht sinnvoll benutzen. Und das war wohl nicht ganz Deine Intention,
oder?
Gruss,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100
76135 Karlsruhe http://punkt.de
Michael Gebetsroither
> Doch, weiß man doch, weil ich alles im Lieferzustand
beließ.
ich installier mir aber kein Suse damit ich weiß wie deine
Anfangsbedingungen sind.
> Gerade die Standard-Einstellungen sind doch stets allseits
> bekannt.
?, ja aber die Standart einstellungen bieten keine Fairen
testbedingungen, man muss sich faire Bedingungen schaffen.
> Genau, deshalb steht ja auch in der Titelzeile: "SuSE 7.3"
Ich wollte nur sagen das es bessere Distributionen als Suse
gibt und
mit Suse 7.3 hast du leider einen ganz blöden Testkandidaten
erwischt.
> SuSE 7.3: mkreiserfs /dev/hdb8
und ich soll jetzt dann wieder nachschauen gehen was diese
Befehlszeile für eine Reiserfs _Version_ erzeugt? Du musst
einfach
verstehen das vorallem bei Linux exterm viel gleichzeitig am
ganzen
System gearbeitet und auch komplett neu geschrieben werden.
Ich
wollte dir sagen das du allessamt alte sachen bei Linux
getestet
hast.
Du hast einfach eine schlechte Wahl getroffen. Reiserfs ist
genauso
noch sehr stark in der Entwicklung wie der Kernel zu Zeiten
des
2.4.10. 2.4.10 war ohne zusatzpatches (vom ac Thread) für
richtige
Computer _nicht_ geeignet.
> Standard - das was da ist.
den musst du aber auch sagen, es wird keiner für dich Suse
7.3
installieren nur damit er deine Testbedinungen weiß.
>>>Was Du hier willst, ist ein unseriöser Test.
wieso, gleiche Optimierungen für alle. Und vorallem bei
beiden
Software die stabil läuft und vorallem auch schnell ist.
> Es ist allgemein bekannt, was SuSE bei 7.3 für einen
> Kernel liefert.
ja aber kannst du mir bitte sagen welche Patches noch in dem
Kernel
sind, damit er überhaupt lauffähig ist?
> Die Kernel-Version ist zudem irrelevant, da das kein
> Kernel-Vergleichs-Bench war, sondern ein Unix-System-
> Vergleich.
Genau der Kernel ist das was ein OS ausmacht.
Außerdem, Freebsd hat ja seine Ports, nur dort wird ja alles
in
Sourceform übertragen, damit auch alles automatisch auf den
vorhandenen Prozessor optimiert, oder? dann installier auch
unter
Linux (mit debian) nur das basispacket und den Rest als
Sourcen die
du dann auf deinem Computer erst compilierst.
> Ach, SuSE 7.3 ist ein Beta-Betriebssystem?
Ja, leider, die Kernelversion der Suse 7.3 ist ohne
Zusatzpatches zu
vergessen und selbst dann ist es natürlich nur ein
Übergangslösung.
> Ach, die allerneueste Version 8.0 auch?
Suse ist einfach nicht das beste das Linux bei seinen
Distributionen
zu bieten hat.
> Und wenn das ein System gar nicht kann?
das arme System ;).
> Genau das wollte ich auch.
Dann hat dein Benchmark auch keine Aussagekraft über die
Leistungsfähigkeit eines OS.
> Welches Linux-System sollte ich denn Deiner Meinung nach
> testen, zum Vergleich mit den anderen Testkandidaten?
versuchs mal mit Debian Sid. ich weiß leider nicht inwieweit
Freebsd
bei den ports optimiert aber ich nehme mal an selbst bei
einer
Standartinstallation voll. Also solltest du auch bei Debian
dann
wenigstens den Shell (bash) über apt-get als Source
runterladen und
compilieren.
> Was außer den Testwerten ist denn noch wichtig - für alle
> Testkandidaten?
Das bei Linux einfach immer Chaos hersscht (aber geordnetes
bitte
*g*). Freebsd mag aufgeräumter sein weil doch dort alles
alles einen
Zusammenhalt hat. Bei linux hat der Kernel nichts mit der
Distri zu
tun, außer das bestimmte Kernel bei bestimmter Software
(modutils,
...) eine bestimmte Programmversion brauchen um bestimmte
Funktionen
ausführern zu können (z.b. module zu laden).
> Dann ist Linux aber ein seltsames Betriebssytem -
> das einzige, für den dieser AIM-Bench unbrauchbar ist.
naja das Linux seltsam ist hab ich auch schon oft gehört
*g*.
> Von welchem "Linux" redest Du hier?
Es gibt nur ein Linux, wenn man Linux sagt dann meint man
den Kernel
und höchstens noch die GNU tools dazu, aber keine
Distribution.
> Zwischen Linux und SuSE-Linux gibt es also einen
Unterschied.
> Ich kann ihn Dir nennen: "Linux" ist *nur* ein Kernel.
> SuSE-Linux ist ein vollständiges Betriebssystem.
Ja, mit allen Fehlern den Suse in einer Standartinstallation
macht.
Einen Server würde kein normaler Mensch mit einer Suse
Standartinstallation machen (bitte aber jetzt net alle stolz
drauf
sein, welche das doch machen, das wäre traurig).
> Wie meinst Du das?
> Ich habe alle Testkandidaten unter vollkommen gleichen
> Bedingungen
> getestet. Willst Du *ungleiche* Bedingungen?
Du hast sie _unter_ gleichen Bedingungen getestet aber die
OS
bringen unterschiedliche Anfangsbedingungen mit (bei Linux
muss man
sicherlich mehr machen als bei Freebsd, schonmal wegen den
ports bei
Freebsd, da wird schonmal standartmäßig optimiert, bei Suse-
linux
hast du immernoch größtenteils i386er Packete).
> Du gehörst zu denjenigen, die sich dafür keinerlei Zeit
> nehmen wollen, wie Du oben sagtest.
keinerlei stimmt nicht, aber soviel auch wieder nicht das
ich einen
FairenBenchmark zwischen den von dir genannten OS machen
würde.
mfg michael
--
/*Only two things are infinite, the universe and human
stupidity, an I'm not sure about the former. -Albert
Einstein*/
Michael Gebetsroither
> Das hat er auch nicht. Was er getestet hat, ist die Performance
> von _Produkten_, so wie sie beim Endanwender in der
> Standardinstallation ankommt. Das _ist_ serioes, da man nur
> _Produkte_ miteinander vergleichen kann.
Ja aber mit Suse 7.3 wollte ich nur anmerken das es eine _sehr_
schlechte Wahl ist, da es einen Betakernel hat.
> Kein Mensch wird in einer RZ-Umgebung mit einigen Dutzend Servern
> ueberall seine handoptimierte Kernel-Version zusammen mit der
> Super-Glibc und Version X, Y, und Z von den Tools soundso
> installieren - das ist nicht sinnvoll wartbar.
Doch ist es, aber eben nur für Leute die sich Auskennen.
> Man installiert FreeBSD 4.5 (z.B.) und trackt dann RELENG_4_5,
> was einem aktuelle Security- aber _keine_ Feature- und
> Performance- Verbesserungen bringt, weil sich bei RELENG_4 eben
> auch mal so viel aendert, dass eine Andwenung neu compiliert
> werden muss.
Bei Freebsd wird ja nur der Source aus dem Inet geladen (über eure
ports) und dann am lokalen Rechner compiliert (mit allen
Optimierungen), oder?
> Tut mir leid, aber fuer www.grossefirma.de ist es
> nicht akzeptabel, laenger als 5 Minuten fuer einen Reboot offline
> zu sein - und der auch noch nachts um 3.
also wenn ich einen neuen Kernel mache dann brauch ich auch nur
einmal schnell rebooten und das ist in 30s erledigt.
und wenn man den Kernel macht kann man ihm ja mit nice beim make eine
sehr niedrige Priorität geben, dann dauerst zwar etwas aber der
Server leidet nicht drunter.
> Im ernsthaften Betrieb tut man _alles_ um so nah wie moeglich
> an der Standardinstallation des Softwarelieferanten zu bleiben
> und so wenig eigene Arbeit wie moeglich zu haben.
Dann kann man den Admin nur bemitleiden und auch gleichzeitig schief
anschauen, da das inakzeptabel ist. Ein admin ist dazu da das er sich
mit dem Os sehr gut auskennt und das er es möglichst gut aufsetzt,
dazu gehört nunmal ein eigener Kernel und das die Server (wenn hohe
Belastungen zu erwarten sind) mit allen Optimierungen compiliert
werden, dh. keine Standartinstallationspackete.
> Und dass Linux in einem "stable" Kernel mal eben das gesamte
> VM auswechselt, ist etwas, was den Admin eines RZ nicht
> zu interessieren hat - und was ganz nebenbei einiges ueber
> die katastrophale Methodik bei der Softwareentwicklung im
> Linux-Umfeld aussagt.
Linux hat das nicht einmal gemacht sondern wenn man es genau nimmt 3
mal *g* (wenn man das aus dem sc Thread dazunimmt).
> Aber ich schweife ab - gleich sind wir
> bei "Linux considered harmful" ;-))))
:D
> Insofern darfst Du von Helmut berechtigterweise eine Erweiterung
> der Tests um zumindest ein oder zwei weitere aktuelle
> Distributionen wuenschen/fordern, wenn dein Punkt ist, dass Suse
> nicht taugt. Wenn Redhat aber genauso schlecht ist, dann sagt der
> Benchmark genau dieses: Linux kann man ohne Insider-Knowhow und
> handoptimierung nicht sinnvoll benutzen. Und das war wohl nicht
> ganz Deine Intention, oder?
Doch man kann Linux schon auch als Newbee aufsetzten aber dann ist es
eben ein Server wie so viele anderen Server im inet (schlechte
Systemausnutzung, total unsicher, ...).
Einen wirklich guten Linux Server aufzusetzen können nicht viele oder
mal sogesagt hat Suse auf einem Server IMHO nichts verloren. Wenn der
Server nur "funktionieren" soll dann ist Suse natürlich auch gut
genug, aber wenns was gscheides sein soll dann muss der Server sauber
aufgesetzt werden (eigener Kernel, die wichtigen Packete über apt-get
(gibts nur bei Debian) im Source runtergeladen und am Server
Compiliert.
Du kannst den Server einfach mal aufsetzten und dann nach und nach im
laufenden Betrieb die Software weiter ersetzten (das geht ja ohne
Probleme auch im laufenden Betrieb). naja für den Kernel musst du dan
noch einmal Rebooten, aber das wars auch schon, alles andere geht
auch ohne reboot.
Linux ist bei der Standartinstallation gegenüber Freebsd mit seinem
Sourcebasierenden port system sicher benachteiligt. Bei Linux (wie
auch bei allen anderen, wenn man einen "guten" Server aufsetzten
will) muss man eben auch händisch noch viel machen. Eine wirklich
gute Standartinstallation für Server gibt es nicht, es gibt nur gute
oder schlechtere Ausgangspunkte bei sowas (suse ist imho eher ein
schlechter).
Wenns ein 0815 Server sein soll dann is Suse klar gut genug. Wenn der
Server aber auch mal ordentlich Leistung bringen soll dann muss man
eben selber hand anlegen und man sollte auch eine andere Distri dafür
nehmen (z.B. Debian).
Michael Gebetsroither
[...]
großes Sorry für den schlecht gequoteten Text, die Software hat an
leichten Schaden :(.
hab grad wieder downgedatet.
Patrick M. Hausen
> Genau der Kernel ist das was ein OS ausmacht.
> Außerdem, Freebsd hat ja seine Ports, nur dort wird ja alles
> in
> Sourceform übertragen, damit auch alles automatisch auf den
> vorhandenen Prozessor optimiert, oder? dann installier auch
> unter
> Linux (mit debian) nur das basispacket und den Rest als
> Sourcen die
> du dann auf deinem Computer erst compilierst.
Nein, ein "Unix"-OS ist eine Implementierung der Unix Spezifikation.
Diese umfasst Kernel APIs, Library-APIs _und_ die Shell mitsamt
Utilities wie awk etc. pp.
Sie umfasst nicht Software wie Apache, o.ae.
All die Dinge, die in der Spec enthalten sind, werden von
Sun, SCO/Caldera, HP, IBM, ... und eben auch FreeBSD als
Binaer-Installation ausgeliefert.
Als Ports installiert man bei BSD nur Dinge wie eben den
Apache (und ~n andere Softwareprodukte).
Insofern ist Linux kein Betriebssystem. Betriebssysteme sind
Suse, Caldera, Redhat, ... und Betriebssysteme (naemlich
das "Suse" Betriebssystem und das "FreeBSD" Betriebssystem)
hat Helmut miteinander verglichen.
Suse schneidet dabei schlecht ab. OK, das ist ein Ergebnis.
Man koennte jetzt den Vergleich um weitere Betriebssysteme
erweitern wie Caldera, etc. pp.
Du unterstellst Helmut, er habe "Linux" gebenchmarkt (furchtbares
Wort ;-) und dafuer eine schlechte Distribution ausgewaehlt.
Das ist nicht richtig. Er hat das Suse Betriebssystem in der
Version 7.3 gebenchmarkt und als Ergebnis kam raus, dass es nicht
so wahnsinnig toll ist. Also seid Ihr Euch doch einig ;-))
> Suse ist einfach nicht das beste das Linux bei seinen
> Distributionen
> zu bieten hat.
Ja und? Seine Benchmark-Ergebnisse sind ja auch fuer alle
anderen Betriebsysteme ausser FreeBSD 4.5 und Suse 6.3/7.3
voellig irrelevant.
> Dann hat dein Benchmark auch keine Aussagekraft über die
> Leistungsfähigkeit eines OS.
Doch - er sagt etwa aus ueber die Leistungsfaehigkeit des
Betriebssystems "Suse 7.3" - und nur ueber dieses.
Rueckschluesse auf andere Linux-Kernel-basierte Betriebssysteme
sind nicht zulaessig und von Helmut auch nirgendwo impliziert.
Michael Gebetsroither
> Nein, ein "Unix"-OS ist eine Implementierung der Unix
Spezifikation.
> Diese umfasst Kernel APIs, Library-APIs _und_ die Shell mitsamt
> Utilities wie awk etc. pp.
> Sie umfasst nicht Software wie Apache, o.ae.
Unix-specs?
du meinst POSIX, oder?
> All die Dinge, die in der Spec enthalten sind, werden von
> Sun, SCO/Caldera, HP, IBM, ... und eben auch FreeBSD als
> Binaer-Installation ausgeliefert.
Echt? ok ich habe gedacht Freebsd geht weiter und hat nut das
nötigste als binärpacket und alles andere wird dann aus den sourcen
compiliert (wie es das auch schon bei einigen Linux distris gibt).
> Suse schneidet dabei schlecht ab. OK, das ist ein Ergebnis.
stimmt ;).
> Man koennte jetzt den Vergleich um weitere Betriebssysteme
> erweitern wie Caldera, etc. pp.
Ich wäre für Debian.
> Du unterstellst Helmut, er habe "Linux" gebenchmarkt (furchtbares
> Wort ;-) und dafuer eine schlechte Distribution ausgewaehlt.
> Das ist nicht richtig. Er hat das Suse Betriebssystem in der
> Version 7.3 gebenchmarkt und als Ergebnis kam raus, dass es nicht
> so wahnsinnig toll ist. Also seid Ihr Euch doch einig ;-))
jo stimmt.
Ich wollte nur sagen das er gerade mit Suse 7.3 einen Bock geschossen
hat weil der Kernel absolut mistig ist, der Kernel ist ohne
zusatzpatches nicht einsetzbar (wegen VM Fehlern => das Schlimmste
das es IMHO gibt).
> Doch - er sagt etwa aus ueber die Leistungsfaehigkeit des
> Betriebssystems "Suse 7.3" - und nur ueber dieses.
> Rueckschluesse auf andere Linux-Kernel-basierte Betriebssysteme
> sind nicht zulaessig und von Helmut auch nirgendwo impliziert.
stimmt, eben genau deswegen habe Standartinstallationen auf einem
Server nichts verloren, außer man legt keinen Wert auf
Geschwindigkeit und Sicherheit.
Lukas Ertl
> Kein Mensch wird in einer RZ-Umgebung mit einigen Dutzend Servern
> ueberall seine handoptimierte Kernel-Version zusammen mit der
> Super-Glibc und Version X, Y, und Z von den Tools soundso
> installieren - das ist nicht sinnvoll wartbar.
Natürlich tue ich das. Würd ich einen meiner Server in der
Standardinstallation lassen, würd ich mich vor mir selber ekeln.
> Man installiert FreeBSD 4.5 (z.B.) und trackt dann RELENG_4_5,
> was einem aktuelle Security- aber _keine_ Feature- und Performance-
> Verbesserungen bringt, weil sich bei RELENG_4 eben auch mal so viel
> aendert, dass eine Andwenung neu compiliert werden muss.
Und bei RELENG_4_5 muß nix neu kompiliert werden? Für einen neuen Kernel
muß man immer noch booten, egal ob in RELENG_4 oder RELENG_4_5.
> Tut mir leid, aber fuer www.grossefirma.de ist es nicht akzeptabel,
> laenger als 5 Minuten fuer einen Reboot offline zu sein - und der
> auch noch nachts um 3.
Zeig mir eine große Kiste, wie sie von www.grossefirma.de eingesetzt
wird, die 5 Minuten bootet (wohlgemerkt, nicht nur das Booten des OS,
auch schon die Initialisierungen vorher).
> Und dass Linux in einem "stable" Kernel mal eben das gesamte
> VM auswechselt, ist etwas, was den Admin eines RZ nicht
> zu interessieren hat
Das sehe ich anders. Wenn du einen Server betreust, solltest du schon
genau wissen, was da grade vor sich geht. Selbstverständlich mußt du
nicht die diversen Kernel-Mailinglisten verfolgen, aber ein gewisser
Überblick sollte schon da sein.
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| If it doesn't work, change the documentation. |
Robin S. Socha
> "Patrick M. Hausen" <hau...@nospam.de> wrote in de.comp.os.unix.bsd:
>> Kein Mensch wird in einer RZ-Umgebung mit einigen Dutzend Servern
>> ueberall seine handoptimierte Kernel-Version zusammen mit der
>> Super-Glibc und Version X, Y, und Z von den Tools soundso
>> installieren - das ist nicht sinnvoll wartbar.
>
> Doch ist es, aber eben nur für Leute die sich Auskennen.
Es ist nicht sinnvoll wartbar. Wie viele Server administrierst Du
nochmal?
>> Tut mir leid, aber fuer www.grossefirma.de ist es nicht akzeptabel,
>> laenger als 5 Minuten fuer einen Reboot offline zu sein - und der
>> auch noch nachts um 3.
>
> also wenn ich einen neuen Kernel mache dann brauch ich auch nur einmal
> schnell rebooten und das ist in 30s erledigt.
Seit wievielen Jahren verwendest Du FreeBSD, Michael?
> und wenn man den Kernel macht kann man ihm ja mit nice beim make eine
> sehr niedrige Priorität geben, dann dauerst zwar etwas aber der Server
> leidet nicht drunter.
Du kompilierst also Kernel auf Servern. Interessant. Vermutlich mit make
xconfig...
> Doch man kann Linux schon auch als Newbee aufsetzten aber dann ist es
> eben ein Server wie so viele anderen Server im inet (schlechte
> Systemausnutzung, total unsicher, ...).
Nimm es nicht als persönliche Kritik: Du redest Scheiße.
> Linux ist bei der Standartinstallation gegenüber Freebsd mit seinem
> Sourcebasierenden port system sicher benachteiligt.
http://www.gentoo.org/ - und apt hast Du offensichtlich ebensowenig
verstanden wie source rpms. Schade eigentlich.
> Wenns ein 0815 Server sein soll dann is Suse klar gut genug. Wenn der
> Server aber auch mal ordentlich Leistung bringen soll dann muss man
> eben selber hand anlegen und man sollte auch eine andere Distri dafür
> nehmen (z.B. Debian).
Okay. Nimm es als persönliche Kritik, wenn Du willst: Ich habe selten
zuvor in dieser Gruppe soviel unausgegorenen Müll in so kurzer Zeit von
einer Person gelesen (Affenbock und den bsheuerten Autohändler zähle ich
nicht mehr).
Was genau geht hier eigentlich gerade ab? Kann mal jemand die Gruppe
reparieren, bitte? [fup2 de.comp.advocacy]
Noses
>> Tut mir leid, aber fuer www.grossefirma.de ist es nicht akzeptabel,
>> laenger als 5 Minuten fuer einen Reboot offline zu sein - und der
>> auch noch nachts um 3.
>
> Zeig mir eine große Kiste, wie sie von www.grossefirma.de eingesetzt
> wird, die 5 Minuten bootet (wohlgemerkt, nicht nur das Booten des OS,
> auch schon die Initialisierungen vorher).
www-1.wetteronline.de. Nach einem crash (ja, man kann nicht alle Software
bis ins letzte darauf testen, wie sie mit hunderten gleichzeitiger Benutzer
fertig wird) kann das _wirklich_ lange dauern, bis die Platten wieder
aufgeraeumt sind. Abgesehen davon, dass bei einem HP Netserver schon der
Speichertest (den man ohne Tastaturbenutzung nicht umgehen kann) ca. 6
Minuten dauert.
Noses.
Lukas Ertl
> Lukas Ertl <l.e...@univie.ac.at> wrote:
>>
>> Zeig mir eine große Kiste, wie sie von www.grossefirma.de eingesetzt
>> wird, die 5 Minuten bootet (wohlgemerkt, nicht nur das Booten des OS,
>> auch schon die Initialisierungen vorher).
>
> www-1.wetteronline.de. Nach einem crash (ja, man kann nicht alle Software
> bis ins letzte darauf testen, wie sie mit hunderten gleichzeitiger Benutzer
> fertig wird) kann das _wirklich_ lange dauern, bis die Platten wieder
> aufgeraeumt sind. Abgesehen davon, dass bei einem HP Netserver schon der
> Speichertest (den man ohne Tastaturbenutzung nicht umgehen kann) ca. 6
> Minuten dauert.
Hach, wieder mal vertippt :-)
Ich meinte eh "die _in nur_ 5 Minuten bootet". Daß das Booten wirklich
lange dauern kann, hab ich am eigenen Leib erfahren, und zwar mit einer
bereits etwas älteren AIX-Kiste, die (sowie ich das verstanden habe)
zwei Boot-Modi hat: den schnellen und den langsamen. Der Schnelle
braucht schon 20 Minuten, der langsame fast 45. Wie ich das erste Mal
damit zu tun hatte, nahm ich natürlich den langsamen (weil ich nicht
wußte, daß es auch schneller gehen würde).
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| Internal sysadmin overflow. System halted. |
Patrick M. Hausen
Lukas Ertl <l.e...@univie.ac.at> wrote:
> Ich meinte eh "die _in nur_ 5 Minuten bootet". Daß das Booten wirklich
> lange dauern kann, hab ich am eigenen Leib erfahren, und zwar mit einer
> bereits etwas älteren AIX-Kiste, die (sowie ich das verstanden habe)
> zwei Boot-Modi hat: den schnellen und den langsamen. Der Schnelle
> braucht schon 20 Minuten, der langsame fast 45. Wie ich das erste Mal
> damit zu tun hatte, nahm ich natürlich den langsamen (weil ich nicht
> wußte, daß es auch schneller gehen würde).
Ich meinte "Routine-Reboot" nach Update per "make world" und Konsorten.
Das geht, wenn man nur z.B. RELENG_4_5 trackt, weil sich da an den
APIs nichts aendert. Kompilieren tut man vorher auf dem CVs-Server
und installieren dann per NFS.
Was man nicht tun sollte (weiss ich aus Erfahrung ;-), ist -STABLE
tracken und dann auf einem Produktionssystem so eine Nummer fahren.
Dann kann es naemlich sein, dass irgendwelcher Dynaloader-Kram
auf die Nase faellt, mod_ssl und mod_php4 nicht mehr starten und
man hektisch anfaengt, vom Apache ueber die Module und dem ganzen
Rattenschwanz hintendran alle Anwendungen zu aktualisieren.
Nachdem das das erstemal bei uns passiert ist, haben wir aufgehoert,
-STABLE auf Produktionssystemen zu tracken. ;-)
Und darauf spielte ich an in Bezug auf Linux: wenn man da einen
neuen Kernel einspielt, weiss man eben wie bei -STABLE auch nicht
100%, dass hinterher alles noch sauber durchstartet.
Bei RELENG_4_X bin ich mir da relativ sicher. Wie soll ich sonst
Openssh-Bugs o.ae. mit vertretbarem Aufwand fixen? Bei *BSD
fehlt hier ganz klar das modulare Basissystem.
Bei Linux wuerde man, IIRC, das "OpenSSH.rpm" oder ".deb" oder
wie auch immer aktualisieren und es passt auch weiterhin alles.
Aber ich frickel doch nicht an Kernel oder Libraries rum auf
einer Maschine, auf der Produktionsanwendungen laufen.
Martin Schmitz
> Das höre ich jedesmal, sobald eine Nachfolgeversion 1 Woche auf dem
> Markt ist. Meines Wissens war der 2.2 fehlerhaft.
Schwachfug!
> SuSE 7.3 hat Kernel 2.4.10.
Eine auch nur halbwegs gepflegte SuSE 7.3 läuft mind. unter 2.4.16
(SuSE-Security update!).
--
(e)mail-address and gpg-key at http://martins.zangpo.org/
or rot13 znegva-...@jro.qr and ask your favorite keyserver
______________________________________________________________
martins:x:500:100:Martin Schmitz:/home/martins:/usr/bin/emacs
Axel Gruner
Michael Gebetsroither <micha...@gmx.at> wrote something special:
> > Genau, deshalb steht ja auch in der Titelzeile: "SuSE 7.3"
>
> Ich wollte nur sagen das es bessere Distributionen als Suse
> gibt und
> mit Suse 7.3 hast du leider einen ganz blöden Testkandidaten
> erwischt.
Ich verstehe diesen Test zwar auch nicht so ganz, aber was an SuSE 7.3
nun blöd sein soll ebensowenig. SuSE 8.0 ist doch sicher der gleiche
SuSE Käse. Und was die Distribution angeht, es mag bessere geben, aber
er hat eben die Distribution genommen die im deutschsprachigen Raum die
wohl am weitverbreiteste ist, und das ist allemal legitim in meinen
Augen.
asg
Daniel Lang
In article <Xns92025A87ECCF...@195.3.96.116>, Michael Gebetsroither wrote:
[..]
> Echt? ok ich habe gedacht Freebsd geht weiter und hat nut das
> nötigste als binärpacket und alles andere wird dann aus den sourcen
> compiliert (wie es das auch schon bei einigen Linux distris gibt).
Ein -RELEASE wird natuerlich mit Binaerpaketen ausgeliefert.
Fuer eine Erstinstallation ist das auch gar nicht anders
moeglich.
Viele FreeBSD user installieren sich aber auch die kompletten
Sourcen und aktualisieren diese (mehr oder weniger regelmaessig)
zB per CVSup. Aus aktuellen Sourcen kann man dann das
_komplette_ Kern-System neu uebersetzen und bauen.
Dazu kann man optimierende Compilerflags einschalten
-O ist supported. -O2 -march=i686 -mcpu=i686 kann
man natuerlich auch einschalten (sowohl fuer das Basissystem
als auch die Ports), wenn man will. Falls es dann instabiler
wird, hat man halt dann Pech.
Ciao,
Daniel
--
IRCnet: Mr-Spock - signs of absurd developments in the net community:
#42: - "Wurstbrot gehoert m.E. zum Fruehstuecks-botnet von Cartoon" -
*Daniel Lang * d...@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/*
Michael Gebetsroither
> Ein -RELEASE wird natuerlich mit Binaerpaketen ausgeliefert.
> Fuer eine Erstinstallation ist das auch gar nicht anders
> moeglich.
ok jetzt ist es klar.
Ich dachte Freebsd bringt nur ein Grundgerüst (fileutils, gcc, ...) und
der Rest wird auch auf den CD's aus den Sourcen erstellt.
ok ich glaub ich werd mich jetzt endlich mal dazu überringen FreeBsd zu
installieren.
mfg michael
--
/*Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former. -Albert Einstein*/
Michael Gebetsroither
> Ich verstehe diesen Test zwar auch nicht so ganz, aber was an SuSE
> 7.3 nun blöd sein soll ebensowenig. SuSE 8.0 ist doch sicher der
> gleiche SuSE Käse. Und was die Distribution angeht, es mag bessere
> geben, aber er hat eben die Distribution genommen die im
> deutschsprachigen Raum die wohl am weitverbreiteste ist, und das
> ist allemal legitim in meinen Augen.
Ich meinte nur das Suse 7.3 ein _sehr_ schlechter Testkandidat ist,
weil es einen zur Funktionsfähigkeit gepatchten Kernel verwendet, dh.
der Kernel hat keine Einsatzerfahrung und hat sich auch überhaupt
nicht bewährt, weil die VM total unausgereift war in ihm.
Suse 8.0 wäre weit aus fairer, weil es einen allgemein als sehr
stabil bekannten Kernel verwendet (und zwar 2.4.18).
Was jetzt nach 2.4.18 als Kernel der 2.4.x Serie kommt bietet sicher
noch etliche Geschwindigkeitsverbesserungen gegenüber 2.4.18,
vorallem der Low latency patch, tut einem System sehr gut und noch
einige andere Patches.
Michael Gebetsroither
> Natürlich tue ich das. Würd ich einen meiner Server in der
> Standardinstallation lassen, würd ich mich vor mir selber ekeln.
*g*, naja wenigstens ein bisschen sollte man sich mit jedem Server
beschäfitgen. IMHO ist bei linux das minimale das man dem Server
einen auf das System zugeschnittenen Kernel spendiert und vielleicht
die verschiedenen Server (apache, Squid, ...) die auf dem System
laufen als source rpms oder source debs runterläd und compiliert.
> Zeig mir eine große Kiste, wie sie von www.grossefirma.de
> eingesetzt wird, die 5 Minuten bootet (wohlgemerkt, nicht nur das
> Booten des OS, auch schon die Initialisierungen vorher).
Ui ja ihr redet da jetzt von etwas anderen Dimensionen. Von solchen
riesengroßen Server hab ich noch net sehr viel mitbekommen. Meine
Systeme befinden sich alle in der IA32 klasse (meistens sind es
Athlon, oder intel P3 oder P4).
>> Und dass Linux in einem "stable" Kernel mal eben das gesamte
>> VM auswechselt, ist etwas, was den Admin eines RZ nicht
>> zu interessieren hat
> Das sehe ich anders. Wenn du einen Server betreust, solltest du
> schon genau wissen, was da grade vor sich geht. Selbstverständlich
> mußt du nicht die diversen Kernel-Mailinglisten verfolgen, aber
> ein gewisser Überblick sollte schon da sein.
Eben, man sollte wenigstens wissen wenn ein neuer Kernel gut ist (dh.
man es wagen kann ihn auf einem Server zu verwenden) oder ob man den
Kernel lieber bleiben lassen soll (bewährungszeit für eine Kernel
sind aber sicher >2 wochen nach Releas).
Andreas Krennmair
> die verschiedenen Server (apache, Squid, ...) die auf dem System
> laufen als source rpms oder source debs runterläd und compiliert.
Nein, soetwas gibt es nicht.
"One pristine archive from the original author, plus debian-specific
patches in another file."
mfg, ak
--
she sells c-shells by the c-shore.
Lukas Ertl
> Lukas Ertl <l.e...@univie.ac.at> wrote in de.comp.os.unix.bsd:
>
>> Natürlich tue ich das. Würd ich einen meiner Server in der
>> Standardinstallation lassen, würd ich mich vor mir selber ekeln.
>
> *g*, naja wenigstens ein bisschen sollte man sich mit jedem Server
> beschäfitgen. IMHO ist bei linux das minimale das man dem Server
> einen auf das System zugeschnittenen Kernel spendiert und vielleicht
> die verschiedenen Server (apache, Squid, ...) die auf dem System
> laufen als source rpms oder source debs runterläd und compiliert.
Wir reden hier von FreeBSD - Stichwort Ports Collection. Und ein
selbstgebackener Kernel, eigentlich sogar ein ganzes "make world", ist
nach einer Installation für mich sowieso Voraussetzung. (Natürlich
tracke ich dann -STABLE auch nicht jede Woche, sondern alle paar Monate
mal, grad wie's mir vorkommt.)
>> Zeig mir eine große Kiste, wie sie von www.grossefirma.de
>> eingesetzt wird, die 5 Minuten bootet (wohlgemerkt, nicht nur das
>> Booten des OS, auch schon die Initialisierungen vorher).
>
> Ui ja ihr redet da jetzt von etwas anderen Dimensionen. Von solchen
> riesengroßen Server hab ich noch net sehr viel mitbekommen. Meine
> Systeme befinden sich alle in der IA32 klasse (meistens sind es
> Athlon, oder intel P3 oder P4).
Auch die meine ich. (Nochmal: in meinem ersten Posting hab ich mich
vertippt, ich meinte "die _in nur_ 5 Minuten bootet".) Die Compaq
Server, mit denen ich mich beschäftigen darf, machen bei der
Initialisierung der Raid Controller immer eine kleine Pause - natürlich
kann man das durch Drücken einer Taste abkürzen, aber wer geht zum
Booten schon in den Systemraum :-)
lg,
le, der einem -STABLE meistens voll vertraut und das ganze "make world
kernel"-Prozedere auch remote durchführt (wenn auch nach einem Test
auf seiner Kiste zuhause :-)
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| The truth is out there! What's the URL? |
Michael Gebetsroither
> * Michael Gebetsroither <micha...@gmx.at> [de.comp.os.unix.bsd]:
>> die verschiedenen Server (apache, Squid, ...) die auf dem System
>> laufen als source rpms oder source debs runterläd und compiliert.
> ^^^^^^^^^^^
> Nein, soetwas gibt es nicht.
> "One pristine archive from the original author, plus debian-
specific
> patches in another file."
naja ok source debs war wohl das falsche, genauer meine ich die
sourcen die man über apt-get über einen sourcen mirror runterlädt und
dann compiliert *g*.
weitestgehend OT:
was mir in letzter zeit aufgefallen ist das viele sourcen von debian
zwar die endung .tar.gzip tragen aber trotzdem nur *.tar packete sind
ohne gzip comprimierung.
Michael Gebetsroither
> Wir reden hier von FreeBSD - Stichwort Ports Collection. Und ein
> selbstgebackener Kernel, eigentlich sogar ein ganzes "make world",
> ist nach einer Installation für mich sowieso Voraussetzung.
hm ja jetzt reichts *g*, ich installier mir in nächster zeit Freebsd,
ich möcht es einfach mal richtig kennenlernen.
> Auch die meine ich. (Nochmal: in meinem ersten Posting hab ich
> mich vertippt, ich meinte "die _in nur_ 5 Minuten bootet".) Die
> Compaq Server, mit denen ich mich beschäftigen darf, machen bei
> der Initialisierung der Raid Controller immer eine kleine Pause -
> natürlich kann man das durch Drücken einer Taste abkürzen, aber
> wer geht zum Booten schon in den Systemraum :-)
*g* niemand, zumindestens nicht ohne Ohrenschutz oder Kopfhörer mit
lauter Musik ;) und dann auch nur so kurz wie möglich.
welche Verbindung habt ihr eigentlich zu euren Servern, eigene
Leitung oder ssh über Uni-Netzwerk?
> le, der einem -STABLE meistens voll vertraut und das ganze "make
> world
> kernel"-Prozedere auch remote durchführt (wenn auch nach einem
> Test auf seiner Kiste zuhause :-)
ok wenn ich bei einem Server was update versuch ichs auch immer erst
Zuhause ;), das erspaart sehr viel Ärgen falls was net hingehauen
hat.
Lukas Ertl
> welche Verbindung habt ihr eigentlich zu euren Servern, eigene
> Leitung oder ssh über Uni-Netzwerk?
Letzteres.
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| "Blink your eyelids periodically to lubricate your eyes." -- Page |
| 16 of the HP "Environmental, Health Safety Handbook for Employees" |
Michael Gebetsroither
>>was mir in letzter zeit aufgefallen ist das viele sourcen von debian
>>zwar die endung .tar.gzip tragen aber trotzdem nur *.tar packete sind
>>ohne gzip comprimierung.
> Sowohl bei IE als auch bei Lynx habe ich schon beobachtet, daß die
> Browser Accept-Encoding: gzip und nochwas mitschicken und .gz-Dateien
> beim Download ungefragt entpacken.
Ja das habe ich auch schon bemerkt, aber die Dateiendung blieb mit
*.tar.gz erhalten, bei einer Decomprimierung fällt aber das .gz
zumindestens bei Lynx weg.
Michael Gebetsroither
>> welche Verbindung habt ihr eigentlich zu euren Servern, eigene
>> Leitung oder ssh über Uni-Netzwerk?
> Letzteres.
:), ich machs eigentlich gleich, aber meistens halt übers inet, weil
ich einfach zu faul bin um in die Firma zu gehen.
mfg michael
--
/*Der Horizont vieler Menschen ist ein Kreis mit Radius Null
und das nennen sie ihren Standpunkt. -A. Einstein*/
Michael Gebetsroither
> Und dass Linux in einem "stable" Kernel mal eben das gesamte
> VM auswechselt, ist etwas, was den Admin eines RZ nicht
> zu interessieren hat - und was ganz nebenbei einiges ueber
> die katastrophale Methodik bei der Softwareentwicklung im
> Linux-Umfeld aussagt. Aber ich schweife ab - gleich sind wir
> bei "Linux considered harmful" ;-))))
schau mal schnell den Thread an aus der lkml (20020502173656.A26986
@rushmore), da siehst du was bei Linux ein paar Versionsnummern
ausmachen können, vorallem jetzt wo so viele Sachen schon sehr gut
laufen aber noch immer nicht in den 2.4.x Kernels drinnen sind (rmap
VM v13, O(1) Scheduler, ...).