Top10/Flop10 von HW-Komponenten?

[Eisenfaust]

Ich habe unter FreeBSD mit allen Radeon HD47XX/HD46XX Karten, und zuletzt mit einer HD4830 Karte, nur Ärger. Der Rechner, egal ob FreeBSD 8, 9 oder jetzt FreeBSD 10, hat sich nach Verlassen des Desktops (in meinem Falle windowmaker, aber auch GNOME zeigte das Problem) und (vermeintlichen) Anzeigens des XDM die Kiste aufgehangen - gnadenlos und durch durch Hard-Reset lösbar. Oder es gab nur streifige Bilder.

Das Problem ist auch unterschiedlicher Hardware aufgetreten - zuletzt auf meiner Labormaschine auf Basis des X79-Chipsatz, also kein Hardware-Problem der Plattform.

Seither vermeide ich alles Graphische aus dem Hause AMD und deklariere für meinen Teil die HD-Graphikkarten als Flop im FreeBSD Kontext.

[Wotan]

Worüber ich mich dieses Jahr besonders geärgert habe, sind die PowerVR Dinger(GMA 3600 aka Cedar Trail) die Intel in ihrer zwei tausender Reihe verbaut hat.

Nichts ahnend hatte ich mir ein passiv gekühltes Board zugelegt und habe erst dann erfahren das intel keine Treiber bereitstellt sondern nur PowerVR und die auch nur proprietäre. Die einzige Möglichkeit den Grafikkern zu nutzen ist im Moment Meego mit BLOB oder angeblich Windows7, was wohl auf einem Atom Dual Core mit 1.86GHz nicht besonder viel Spaß machen sollte und ich auch nicht will.

Ab linux 3.3 wird die GPU wenn auch ohne 2D/3D Beschleunigung unterstützt, aber z.B. ein Video in Vollbild schafft man damit leider nicht.

Aber Konsole geht

[stadtkind]

Zitat von Crest

stadtkind: OpenSSL nutzt AES-CTR das OS unabhängig. Der große Vorteil von Padlock gegenüber anderen HW-Cryptobeschleunigern ist unter anderem, das es keinen Kernelsupport braucht.

Soweit ich weiß, geistert AES-CTR Support in OpenSSL hoechstens in Form von irgendwelchen Patches von Intel im OpenSSL Bugtracker rum, aber vielleicht gibts ja da inzwischen Neuigkeiten und wenn du weißt wie das geht, wuerde ich mich ueber eine HOWTO freuen.

Zum Thema Padlock AES-CTR im Kernel. Nun ohne Support kann ich GELI oder DM-Crypt mit der »sichereren« AES Verschluesselung (AES-XTS) vergessen und bin weiterhin auf CBC angewiesen.

Auch nutzt ssh inzwischen defaultmaeßig aes-ctr, so das man bei den Padlock CPUs inzwischen staendig nachjustieren muss, wenn man HW Crypto haben will.

[Eisenfaust]

Abseits der CPU-Spezifika, was sicherlich für eingebettete Systeme und Niedrigvolt-Prozessoren wichtig ist, die nicht unterstützt wird, hier noch einen anderen, viel gravierenderen FLOP.

Schlagwort GPGPU, Schlagwort OpenCL/CUDA. Nutzung einer nVidia oder AMD Graphikkarte als GPGPU-Device. Dank nVidia können "wir BSDler" froh sein, daß unter modernen 64bit Systemen 3D Beschleunigungen und OpenGL >3 nutzbar sind. Leider ohne CUDA, leider ohne OpenCL, denn der nVidia-eigene Compiler "nvcc" ist linuxbinär, die entsprechenden OpenCL und CUDA Bibliotheken sind nur als 32bit Versionen mit Hilfe des Linuxulators nutzbar - wenn überhaupt nutzbar (es geht jedenfalls nicht bei uns). Unsere TESLA Karten müssen mit Linux betrieben werden, will man diese im HPC Umfeld nutzen.

Unter FreeBSD ist weder unter OpenCL noch CUDA eine GPGPU-Nutzung möglich, die für mich/uns im wiss. Bereich zunehmend wichtiger wird. HPC ist eine Domäne, die ich als die Königsdisziplin der Betriebssystemnutzung sehe. FreeBSD bzw. die BSDs allgemein haben in den vergangenen 15 Jahren sehr viel Terrain verloren.

AMD blubbert zwar seit Jahren über offene Treiber und Dokumentation, aber dabei ist nicht sonderlich viel bei herumgekommen bis auf Lippenbekenntnisse. nVidia ist ausschließlich auf Markt und Profit fixiert. Die größte Enttäuschung aber sind Graphikkarten und treiber für AMD Karten allgemein, meine Probleme mit der HD4XXX Serie von AMD habe ich einem verlogenen Versprechen seitens AMD zu verdanken, die in einem Gespräch bemerkten, daß deren Chips OpenCL fähig seien und man die Chipspezifika offenlege werde, so daß die FOSS Treiber in spätestens einem Jahr OpenCL "können" sollten.

Der Chip hatte Probleme, die Dokumentation war nach nur zwei oder drei Wochen Präsenz auf den offiziellen Webservern von AMD plötzlich nicht mehr verfügbar. Der schleppende Stand der Entwicklung des Gallium3D und CLover Gespannes im Radeon-Treiber zeigt, daß das Problem nicht *BSD- bzw. FOSS spezifisch ist, sondern seine Ursache in AMDs Spielchen hat. AMD Graphikkarten sind meiner Ansicht nach unter FreeBSD für eine ernsthafte Anwendung völlig unbrauchbar! Es gibt keine Catalyst 64bit Treiber für FreeBSD. Die aktuellen Radeon/RadeonHD treiber in Xorg-X11 unterstützen keine HD7000er Karten. Wenn ich heute Hardware bestelle - und die Budgest sind, wie in einem Unternehmen auch, limitiert und auf längere Zeiträume ausgelegt, so werde ich keine Hardware von gestern ordern, sondern moderne, neue Hardware. In Maßstäben der Zyklenzeit, welche die gierige Industrie selbst mit ihren hohen Produktfrequenzen zu verschulden hat, sind sechs Monate eine halbe Ewigkeit und man sollte jetzt für die HD7000 auch für FreeBSD funktionierende 64bit Treiber erhalten. Wo sind diese? nVidia schafft das problemlos, wenn auch mit einem BLOB.

[darktrym]

@Eisenfaust: Schau dir mal die Produkte von Pathscale an, die haben FreeBSD Support.

[zuglufttier]

Zitat von Wotan

Die einzige Möglichkeit den Grafikkern zu nutzen ist im Moment Meego mit BLOB oder angeblich Windows7, was wohl auf einem Atom Dual Core mit 1.86GHz nicht besonder viel Spaß machen sollte und ich auch nicht will.

Also Windows 7 läuft selbst auf einem Atom Single Core ganz anständig, nicht wirklich langsamer als XP z.B.

[Amin]

Wie sieht es eigentlich mit dem Nvidia-Binary-Treiber für FreeBSD unter NetBSD/OpenBSD aus? Kann man den dort auch nutzen?

@Eisenfaust! D.h. man kann GPGPUs zum Rechnen aktuell nicht unter *BSD nutzen?

@all! Ich habe in einer News gelesen, das die FreeBSD Foundation an Intel-Grafiktreibern arbeitet. Was hat es damit aufsich?

[darktrym]

Der Nvidia Treiber ist nur für FreeBSD. Es gab mal Interesse seitens NetBSD die notwendigen Anpassungen zu unternehmen, mittlerweile wurde das verworfen. Und Nouveau benötigt einiges(KMS, TTM) was bei Open- und NetBSD gänzlich fehlt.

Und zu GPGPU, pscnv wurde erweitert für FreeBSD, schaut zum. recht versprechend an.

[Yamagi]

Darüber hinaus kann man mit dem Nvidia-Treiber unter FreeBSD Linux-CUDA-Anwendungen ausführen, das CUDA-SDK läuft einwandfrei im Linuxulator. Es geht, da die CUDA-Unterstützung für den Kernel vorhanden ist, allerdings die Runtime-Bibliothek fehlt. Nvidias Statement dazu war, dass sich eine Portierung auf FreeBSD nicht lohnt und daher erst einmal mangels Nachfrage nicht durchgeführt wird. Der Nachteil der Linuxulator-Lösung ist, dass man auf 32-Bit Prozesse beschränkt ist.

[Eisenfaust]

Zitat von Amin

[...]
@Eisenfaust! D.h. man kann GPGPUs zum Rechnen aktuell nicht unter *BSD nutzen?

[...]

Das Schwert ist zweischneidig.

Nutzt man "klassische" Hacks unter OpenGL, also die Abstraktion eines mathematiswchen problems in der formalen Sprache der OpenGL Implementation, kann man auch unter FreeBSD die GPU bedingt zum Rechnen bewegen. Da aber das OpenGL-Backend wiederum abhängig von der Nutzung der Beschleunigungen in der Hardware abhangt, geht das, meines Wissens, nur sinnvoll mit den binären Treibern von nVidia. Ich habe mich eine Weile damit beschäftigt, diese Option aber schnell wieder verworfen, weil der Aufwand und der Nutzen in keinem vernünftigen Verhältnis steht.

Von Seiten PathScale wird eine Compiler Suite angeboten, die sich "Enzo2011" nennt. Zur GPU-gestützten Parallelisierung kommt hier HMPP, eine Compiler Erweiterung ähnlich OpenMP, ein API. HMPP und OpenACC sind "offene" Standards, die in den Quellcode mittels #pragma-Anweisungen eingebaut werden. PathScale garantiert die Funktion nur mit neueren TESLA Architekturen, die Compiler-Lizenz ist üppig und maschinengebunden. Wir konnten uns jedenfalls nicht zu dieser Investition durchringen, obwohl HMPP/OpenACC eine phantastische Möglichkeit bietet, bestehenden Code auch auf einer GPU ausführen zu lassen.

Seit einigen Jahren geistert nun die Mähr von der Verwendbarkeit der CUDA Binaries unter FreeBSDs Linuxulator, hierzu wird auch eine bereits seit langem völlig veraltete Anleitung im Netz angeboten. Diese "Lösung" ist aus mehreren Gründen nicht in Betracht zu ziehen, zumindest aus unserer Sicht.

Einerseits muß man den Code auf einer funktionierenden Linux-Plattform compilieren oder Cross-compilieren. Die Plattform muß dann 32bittig sein, weil der Linuxulator nur 32bittig arbeitet. Für unseren Modell-Code, der durchweg 64bittig arbeitet, ein Problem. Ich optimiere keinen Modell-Code auf 64Bit, um ihn dann mit angezogener Handbremse auf einem 32Bit System mit all seinen speicherlimitierenden Nachteilen laufen zu lassen. Zudem muß man, um vernünftig entwickeln und testen zu können, eine komplette Linux 32Bit Infrastruktur einrichten - meiner Meinung nach völliger Unsinn, denn ich benutze dann lieber ein wesentlich moderneres und schnelleres 64Bit Linux nativ.

Andererseits haben wir (und insbesondere ich) es nie geschafft, auf aktuellen FreeBSD Systemen (FBSD 9.0-STABLE, FBSD 10.0-CURRENT) CUDA und insbesondere OpenCL lauffähig zu machen. Der Aufwand ist einfach zu groß und ich bezweifele, daß es überhaupt geht - schon im Hinblick auf die 32-64-Bit-Problematik.
Es mag sein, daß es "irgendwie" gehen mag, es ist aber gemessen am Aufwand und letztlichen Ergebnis eher als Unsinn abzutun und völlig impraktikabel.

Wir entwickeln und forschen mitlerweile auf Linux mit TESLA Karten und nutzen OpenCL. openCL hat nach meiner Meinung den weitaus größeren Vorteil, CUDA ist zu sehr auf nVidia Karten festgelegt (wie auch PathScales ENZO-Lösung). Mal von Instabilitaten und unsauberen Verhaltensweisen des AMD SDK abgesehen, zeigen die aktuellen GCN-basierten AMD Karten einen gigantischen Leistungsvorteil gegenüber nVidia Karten, wenn es um doppelt genaue Fließkommaarithmetik geht. Eine 500-Euro teure AMD Karte nimmt es spielend mit einer fast zehnfach teureren TESLA Karte auf (die gröste TESLA, die wir derzeit haben, ist eine M2075 mit 6GB RAM). Zudem ist das Intel-SDK, ebenfalls OpenCL-fähig, wesentlich besser.

Diese Freiheiten lernt man schätzen mit der Zeit - und vermißt sie schmerzlich, wenn man den Blick von Linux wieder zurück auf FreeBSD wendet.

Was den OpenSource-Vorstoß PathScales betrifft, so kann ich sagen, daß ich vor zwei Jahren einmal Kontakt zu dieser Firma hatte und sich abzeichnete, daß es hier zu einem "Schritt in die richtige Richtung" kommen würde. Leider waren die Versprechungen aber vollmundiger als das Resultat - ich vermute, daß firmenpolitische Gründe zum Zurückrudern zwangen, denn PathScale kooperiert in Sachen HMPP/OpenACC über CAPS eng mit nVidia.

Daß nVidia keinen "Bedarf" auf Seiten der *BSD Linien sieht, halte ich für nicht haltbar. Gerade die Lizenzpolitik der BSD Systeme würde es Entwicklern viel einfacher machen, Produkte mit geschlossenen Quellen anzubieten - das ist Dank Linux und GPLv3 anders. Dennoch verstehe ich die Entwicklung nicht - sie erscheint mir als ein Paradoxon.

Letztlich, unter dem Strich, ist CUDA oder OpenCL NICHT mit FreeBSD verwendbar, zumindest wenn man ernsthaft HPC betreiben will. Neben eigens entwickleter Modellsoftware gibt es ja auch noch andere Bestrebungen softwareseitig, eine vorhandene GPU in den Rechenprozeß einzubeziehen. Auch kastriert eignen sich nVidias Graphikkarten hervorragend dazu, ich verwende zum Beispiel eine nVidia GTX570, wenn ich die TESLAs im hause nicht nutzen kann - nur verwende ich sie nicht unter FreeBSD.
Die GEGL-Bibliothek wird nun auf OpenCL erweitert, um graphische Operationen in GIMP zu beschelunigen. Filter profitieren ungeheuer von solchen Beschleunigungen! Blender, als nächstes Beispiel, beschleunigt mit Hilfe CUDA oder OpenCL (abhängig vom Treiber, unter Ubuntu kann ich mit Hilfe des nVidia 302.07-Treibers aber beides auswahlen). Der Zugewinn ist phänomenal! Wenn wir Präsentationen rechnen/rendern, die zwischen zwei und 10 Minuten lang sind und minimal HD-Qualität mit 25 BPS aufweisen sollen, ist eine GPU-Beschleunigung ein Segen. Zwar hält sich der Effekt der Beschleunigung in Grenzen, aber wenn man bedenkt, daß ein 2x 6-Kern XEON mit 2,8 GHz fast eine Woche für ein solches Video gerechnet hat und mit Zuschaltung der CUDA Erweiterung dann um den Faktor 3 - 6 beschleunigen konnte - das sind dann Zeiten, die man sehr, sehr deutlich spürt!

[Eisenfaust]

Zitat von darktrym

[...]
Und zu GPGPU, pscnv wurde erweitert für FreeBSD, schaut zum. recht versprechend an.

Hat man bei NetBSD und OpenBSD nicht die Not zur Tugend gemacht? Was wollen die der Öffentlichkeit Rede und Antwort stehenden Verantwortlichen denn auch anderes sagen, als "wir haben uns anders entschieden", wenn der Hersteller, hier nVidia, keine Treiber liefern will? Man "entscheidet" sich IMMER anders, wenn man nicht das bekommt, was man dringend benötigt.

Letzteres, PSCNV, scheint wenig nutzbringend. Zumindest im Moment. Es sit wie viele andere auch ein Projekt im Entstehen.
Ich habe mich, ehrlich gesagt, nicht mehr nach einem kurzen Intermezzo PathScales um diese Sache gekümmert. Ich werde mal versuchen die Quellen zu bauen. Dann ist mir noch immer nicht klar, mit was dieser "Treiber" gefüttert werden soll - CUDA, HMPP, OpenCL? Und welcher Compiler, mal von PathScales ENZO abgesehen, könnte denn mit PSCNV umgehen?

[darktrym]

Zitat von Eisenfaust

Hat man bei NetBSD und OpenBSD nicht die Not zur Tugend gemacht? Was wollen die der Öffentlichkeit Rede und Antwort stehenden Verantwortlichen denn auch anderes sagen, als "wir haben uns anders entschieden", wenn der Hersteller, hier nVidia, keine Treiber liefern will? Man "entscheidet" sich IMMER anders, wenn man nicht das bekommt, was man dringend benötigt.

Anfangs gab's noch einen brauchbaren Nv-Treiber und Nouveau war relativ schnell linuxzentriert. Und was wollen die beiden mit einen binären Blob? OpenBSD hat nichts dafür übrig und bei NetBSD fehlte die Motivation nur für 2 Plattformen großen Aufwand zu betreiben.

Letzteres, PSCNV, scheint wenig nutzbringend. Zumindest im Moment. Es sit wie viele andere auch ein Projekt im Entstehen.
Ich habe mich, ehrlich gesagt, nicht mehr nach einem kurzen Intermezzo PathScales um diese Sache gekümmert. Ich werde mal versuchen die Quellen zu bauen. Dann ist mir noch immer nicht klar, mit was dieser "Treiber" gefüttert werden soll - CUDA, HMPP, OpenCL? Und welcher Compiler, mal von PathScales ENZO abgesehen, könnte denn mit PSCNV umgehen?

PathScale-Computing-NV-Treiber soll CUDA unterstützten, etwas abspeckt. Im Gegensatz zu Nouveau ist es auch portabel, benutzt kein TTM. OpenCL will man mit Nvidia eh nicht machen, OpenCL wird da über CUDA gelöst. Einige Teile der freien Toolchain sind prop. von PathScale. (Pscnv ist im übrigen ein Fork von Nouveau und so wie deren Compiler von Open64.) Will man ausgereiftes GPGPU jetzt bis in die nächste Jahre nutzen, führt kein Weg an CUDA vorbei.

[Bummibaer]

ASUS E35M1-M mit AMD E-350 (2x 1,6 GHz) Mainboard:
- 2x 4 GB SDRAM DDR3-1066
- beide PCI Slots mit DVB-S2 Karten bestückt
- 2 USB-Sticks an den onboard USB-Slots

Die SAT Karten werden vom Bus nicht mit ausreichend Strom versorgt. Bei vielen Schreibzugriffen auf diversen getesteten USB-Sticks kommt es zu Lese-/Schreibfehlern. Es ist mir nicht begreiflich wie man zwei PCI Slots auf das Board packen kann und noch nicht mal die Stromversorgung für eine Karte wirklich ausreichend gut war. Auch diese seltsamen USB Controller sind mir ein Dorn in der Pfote. Es war mir mit 19 getesteten Sticks nicht möglich auch nur einen zu finden der keine Lese-/Schreibfehler hatte.

Die vom Hersteller für die CPU angegebene TDP von 18 Watt entputte sich dann später bei einem 250 Watt Netzteil auf 230V mit rd. 58 bis 62 Watt im Betrieb. Ich habe keine Ahnung was da so viel "Strom" zieht. Das Netzteil verbrauchte beim Atom Board nur rd. 27 Watt bei einem D525.

Gruß Bummibär

[ralli]

Mein jetziger Rechner, den ich vor ca. sechs Jahren erwarb, war der letzte Komplettrechner, der ins Haus gekommen ist. Obwohl ich ein Markengerät (Packard Bell) kaufte, kam das erste Problem bereits nach dem Aufrüsten eine Grafikkarte, wo sich dann herausstellte, das das verbaute Netzteil völlig unterdimensioniert war mit 250 Watt. Der nächste Rechner wird nach meinem Gusto und Wünschen zusammengestellt und gebaut und dabei achte ich hardwaremäßig auf FreeBSD Kompatibilität.

[Rakor]

Zitat von ralli

...nach dem Aufrüsten eine Grafikkarte, wo sich dann herausstellte, das das verbaute Netzteil völlig unterdimensioniert war mit 250 Watt. ...

Wenn der Rechner zuvor gelaufen ist ohne Ausfälle auf Grund instabiler Spannung war das Netzteil eigentlich eher genau richtig dimensioniert ...