Re: Anfrage Multi-Prozessoren in FreeBSD

On 10/27/11 14:33, Bernd Walter wrote:
> On Thu, Oct 27, 2011 at 01:24:06PM +0200, O. Hartmann wrote:
>> On 10/27/11 12:44, Bernd Walter wrote:
>>> On Wed, Oct 26, 2011 at 11:36:11PM +0200, Colloid.Silver wrote:
>>>>
>>>> Wie viele Prozessoren mit je wie vielen Kernen unterstützt FreeBSD 8.x /
>>>> 9.x auf einem großen System ?
>>>
>>> Traditionell 32, da diverse Informationen als Flags in einer 32-bit
>>> Zahl gespeichert werden.
>>> Ein Update auf eine 64-Bit Zahl wurde nicht vorgenommen, weil das keine
>>> dauerhafte Lösung gewesen wäre.
>>
>> Das gilt schon eine geraume Zeit nicht mehr. Im englischsprachigen Forum
>> hatte ich einmal eine ähnliche Frage gestellt, die relativ schnell
>> beantwortet wurde (ich suche das gerne mal heraus). FreeBSD hat, wenn
>> ich mit irre, seit Version 8 keinen Integer mehr, der die CPU-Map hält,
>> sondern die Haushaltsverwaltung wurde auf einen String verlagert, der
>> beliebig lang sein darf. Wenn ich mich nicht irre funktioniert deshalb
>> auch in FBSD 9 zur Zeit das selektive Ab- und Zuschalten von CPUs
>> (physische wie virtuelle) nicht (mehr) und ist auf der Wunschliste der
>> Kernelentwickler ganz oben.
>
> Also die 8.0 hat mit Sicherheit noch das Limit - so lange gibt es das
> nämlich noch nicht.
> Ob das später gemerged wurde kann ich nicht sagen, aber das wäre doof,
> wenn das abschalten nicht mehr geht.

Ich habe mich da vertan, es ist richtig, daß 8.2-STABLE noch einen INT
mit 32 Bit verwendet. Die HEAD Maschinen arbeiten bei mir bereits mit
10.0-CURRENT, alle anderen bis auf eine mit 9.0.

Ich kann auch nicht 100% sagen, ob der Wechsel zur neuen Strukur auch
zur Folge hatte, daß das selektive Zu- and Wegschalten von Prozessoren
aufgrund der Änderungen erfolgte, so tief hänge ich in der
Kernelentwicklung nicht drin. Jedenfalls gab es in CURRENT einige
Mitteilungen, daß die entsprechendn OIDs, die per sysctl zur Laufzeit
angesetuert werden können, deaktiviert wurde. In aller regel sind das
Bitmaskierungsmakros gewesen. Aber es gab wohl eher Ärger mit korrekter
Synchronistaion von Jobs und Scheduler.

>
>> Factum est: Von Supermicro gibt es ein System mit insgesamt 8 CPU
>> Sockeln, die mit 10-Kern XEONs der Westmere-generation bestückt werden
>> können und somit 80 physikalische und 160 virtuelle CPus bieten. Und
>> genauso ein System wird wohl auch von einem FreeBSD 8 oder 9 angefeuert,
>> wie man mir versicherte.
>
> Das ist aber für die meisten hier immer noch sehr theoretische Hardware.

Nun, für uns nicht und für die, die FreeBSD einsetzen wollen, eben auch
nicht. Und ich sehe keinen Grund es nicht anzuführen. BSD war ein
akademisches Betriebssystem und verkommt zunehmend zu einem zahnlosen
Desktopsystem, während das Frickelsystem Linux vom Witz zunehmend zum
Hochleistungssystem avanciert. Und ganz nebenbei: Die Entwicklung eines
Betriebssystems ala Microsoft aus der Sicht eines Endanwenders zu
betrachten, der von Tuten und Blasen keine Ahnung hat, ist gefährlich.
Die Grundlegung eines formalen und theoretischen Konzeptes ist spannend,
die korrekte Umsetzung in einer Sprache viel Arbeit und nicht minder
spannend. Und hier hat "brauch ich doch eh nicht" keine Legitimation.

>
>> Derzeit kann mit einer Kernelvariable die maximale Anzahl CPUs
>> eingestellt werden und ist, meines Wissens, auf 256 gesetzt.
>>
>>> Im Regelfall schaltet man bei den Hyperthreading ab, wenn man über dem
>>> Limit liegt - die meisten Systeme liegen spätestens dann unter 32 und
>>> der Leistungszuwachs von Hyperthreading ist eh nur selten relevant.
>>> Das ganze wurde später richtig umgesetzt und ich meine es wäre in der
>>> 9'er bereits drin.
>>> Es gibt immer noch ein Maximum, aber das nur wegen dem Speicherbedarf.
>>> Man kann das Maximum bei Bedarf jederzeit hoch drehen.
>>>
>>>> Beispiel, die kommerzielle Version von SUSE-Nvell Linux unterstützt
>>>> bis zu 4096 Prozessoren, mit jeweils mehrfachen Kernen.
>>>
>>> Das ist bei Linux IMHO ziemlich witzlos.
>>> Linux skaliert nicht besonders gut, sodass anzunehmen ist, dass man
>>> die Leistung nur auf der Stromrechnung sehen dürfte.
>>> Bereits im Bereich der von FreeBSD traditionell unterstützten CPU Anzahl
>>> konnte man bei Tests immer deutliche Unterschiede sehen.
>>> Die Intel Architektur skaliert aber im allgemeinen nicht besonders gut.
>>>
>>
>> Das glaube ich nicht. Im Linuxumfeld hat sich in den vergangenen Jahren
>> sehr viel getan und eigentlich ist Linux derzeit Vorreiter und in den
>> BSDs, bis auf die Sicherheitsaspekte SSH wie in OpenBSD, werden
>> architektonische Merkmale integriert, die aus anderen Entwicklungen
>> stammen. Gerade im Hinblick auf HPC, wo sehr viel Wert auf
>> Skalierbarkeit gelet wird, hat FreeBSD so gut wie nichts mehr zu melden.
>
> Die regelmässigen Anwendungsbenchmarks, die aus dem BSD-Team kommen
> sprechen da eine ganz andere Sprache.

Wo? Beispiele?

> Die Benchmarks aus dem Linux-Lager sind leider meistens geschönt und
> haben mit realer Nutzung wenig zu tun.

Was sind reale Nutzung? Webserver? Datenbanken? Oder andere Späße, für
die man allenthalben eine Integer ALU braucht, aber keine FPU?

> Das fängt schon damit an, dass Linux selbst heute noch darauf verzichtet
> auf SMP-Systemen eine monoton steigende Systemzeit zu bieten, während
> Linux typische Spielzeugsoftware, wie MySQL hingegen immer noch extrem
> oft eben diese Zeit abfragt - wozu, wo die doch unzuverlässig ist
> weiß wohl keiner so genau.

MySQl war auch im FreeBSD Umfeld stets eine Meßlatte und die letzten
Benchmarks, die ich diesbezüglich gesehen habe, waren stets auf eine
DB-optimierte Skalierung aus. Etwas, was ich leider im
naturwissenschaftlichen Bereich gar nicht brauchen kann.

> Wenn du auf derartige billigen Tricks reinfallen willst - bitte schön,
> das tun immerhin die meisten Menschen.

Und Du bist die große Ausnahme?

>
>> Mit dem Mangel an GPU-Unterstützung wird diese Kluft immer größer - sehr
>> zu meinem bedauern.
>
> Das ist aber kein OS-Problem, sondern ein Problem der Hardwarehersteller,
> die kein OpenSource unterstützen.

Ist es. In FreeBSD fehlen wichtige Kerneleigenschaften, um es für die
Treiberhersteller bequem zu machen, die entsprechenden Schnittstellen zu
implementieren. FreeBSD ist durch den Mangel an KVM weit abgeschlagen!
Argumentiert wird stets, daß das mit dem Mangel an Entwicklern zu tun
habe. Das ist dummer Unfug. Das ist nur ein kleiner Teil der Wahrheit.
Gerade die auf Sicherheit drängenden BSD-Systeme würden einen großen
Nutzen ernten, wenn KVM im Kernel implementiert wäre, da dann das
graphische Subsystem nicht mehr via UID 0 (root) eingebunden werden
müßte. Infolge dieser im Linux-Sektor massiv vorangetriebenen
Entwicklung werden auch neue Treiberkonzepte, die mit der GPU als ein
Rechengerät umgehen können, abgestimmt, die für FreeBSD, wie die anderen
BSD Systeme auch, unerreichbar sind.

> Immerhin könnte FreeBSD mit seiner Lizens sowas nutzen.
> Auch wenn das bislang nur vorwiegend bei Linux praktiziert wird ist
> genau hier die Fragestellung offen, ob das wirklich mit der GPL in
> Einklang steht.

Ich glaube, das ist nicht naiv betrachtbar. Theoretisch ist mit der
BSD/MIT Lizenz eine der wohl besten Lizenzen geschaffen worden, die sich
ein souveränes und autarkes Staatengebilde wie die BRD vorstellen
könnte. Und warum aber wird dann in Erwägung gezogen, Linux einzusetzen?
Da wir auch eben jene Leute ausbilden müssen, die später mal als VWL,
BWL oder Juristen in die "Entscheiderpositionen" kommen, kann ich ein
Lied davon singen, was diese Leute an mathematisch-logischem Verständnis
mitbringen. *Hüstel*

> Das ist aber irelevant - der Vorteil von GPU-Leistung gegenüber
> Anwendungsorientierte ist nur, dass die billig ist und zwar auch in
> der Qualität.
> GPU-Hardware hat keine Serverqualität, sondern ist Konsumerhardware.
> Für Server gibt es spezialisierte Hardware - manche davon auch mit
> FreeBSD-Support.
> Und nein - es gibt keine spezialisierte Serverhardware mit FreeBSD-Support
> zum errechnen von Bitcoins.

Das zeigt mir, daß Du keine Ahnung von der Materie hast. ich sage nicht,
daß ich Spezialist bin, aber wir arbeiten und Entwickeln mit CUDA und
OpenCL Software, die leistungsoptimiert und hochparallel auf der GPU
arbeitet. Modellierungen von Kollisionsprozessen, Wetter, Filter für
immens große Bilddaten.
Was hat eine GPU mit "Server" oder "Serverqualität" zu tun? Wichtig ist
der "Server" als Entität, der mir als Anwender und entwickler und
Forscher die Möglichkeit bietet, in angemessener Weise das gerät nutzbar
zur verfügung zu stellen. Und FreeBSD kann das nicht. Leider. Aber es
tut sich auch hier etwas. Man muß nur lange genug bohren!

Und der Schwachsinn Bitcoin hat nun hier wirklich nichts zu suchen. Das
soll im Resort der fachkundigen "Piraten" bleiben.

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 28 Oct 2011 - 11:57:30 CEST