Beiträge von FSMaxB


    top danke, noch jemand der MSI Boards zu mögen scheint ;)

    Das Board ist ZUM KOTZEN!

    • Es hängt sich manchmal beim Reboot auf (sodass nicht mal mehr die Reset-Funktion tut und man am Netzteil den Strom wegnehmen muss
    • Es braucht eeewig zum Booten
    • Die BIOS-Batterie ist unter dem f**ing Heatsink des Mainboards und das habe ich nur rausgefunden weil ich im Internet gesucht habe, in der Anleitung steht nix davon
    • Warum interessiert mich wo die Batterie ist? Weil das niegelnagelneue Mainboard seine Uhrzeit nicht hält (ist mir erst nach ein paar Monaten aufgefallen, nicht sicher ob es schon von Anfang an so war)

    Ich hatte davor eines von Gibabyte, hab ich leider mit Liquid-Metal zerstört, aber das hat deutlich besser performt, hatte allerdings auch kein 10GBit Ethernet, aber das kann man sich ja auch als PCIe-Karte holen, also kein Kaufgrund für das MSI-Board.

    Ich weiß nicht ob ich nach der Erfahrung jemals wieder ein Mainboard von MSI kaufen will ehrlich gesagt.


    okay hörte sich so an als würde die CPU 500W ziehen ich hab aber nicht nachgeschaut muss ich zugeben, der XEON selbst ist auf Last mit 105W angegeben hab aber turbo boost aus weil mein Board spackt, gibt wohl bald ein Bios Update hoffe ich.



    ok der hat max 300W sehe ich gerade

    Max TDP sind 280W, die 500W sind das ganze System inklusive zwei Monitoren. Hab da so ein Messgerät vor der Mehrfachsteckdose stecken. Aber für die Stromrechnung ist das was zählt. Ich denke aber mal die 280W wurden schon voll ausgereizt beim Cinebench-Score.


    Ach ja Neid ist die höchste Form der Anerkennung, und wenn es dazu führt das rein zufällig sich jemand hier anmeldet der seit 6 Jahren nicht mehr aktiv war nur um seine Heizung zu posten, dann fühlt sich das doch schon sehr gut an

    Zu meiner Verteidigung: Ich wurde von winfreak dazu aufgefordert hier mal mitzubenchen, sonst wäre ich gar nicht auf den Post aufmerksam geworden um ehrlich zu sein. Aber ja, besonders aktiv war ich nicht, seit ich mich hier 2015 mal angemeldet habe.

    Ich kann übrigens nicht wirklich empfehlen sich so nen Prozessor zu holen wenn es nicht unbedingt sein muss. Den zu kühlen ist eine Wissenschaft für sich und vermutlich wegen der geringen Verbreitung gehen die Mainboards dafür eher in Richtung Beta-Ware (oder liegt es vielleicht am Chipsatz, keine Ahnung).

    Ansonsten lieber entweder auf besagten ARM Mac Pro warten (und darauf, dass da jemand Linux drauf zum laufen bekommt), oder einen AMD Ryzen 9 5950X. Ist denke ich beides die bessere Wahl.


    @FSBMaxB würdest du noch nen Geekbench fahren, würde mich aj echt interessieren was der da packt

    329271305FSMaxB1243,8EigenbauAMD Ryzen Threadripper 3960X


    Was der M1-Prozessor so abliefert ist echt enorm. Da stellt man sich echt die Frage ob es sich gelohnt hat den Threadripper zu kaufen, wenn es jetzt schon Gerüchte gibt, dass es 2021 einen 32-Kern Mac Pro von Apple geben soll. Das rechnet sich ja wahrscheinlich schon durch die Stromrechnung. Beim Cinebench hat mein Threadripper einfach mal >500W geschluckt!


    Quatsch. USB-Geräte werden erst enumeriert, wenn das Rootfs bereits gemountet ist. Dementsprechend steht die Reihenfolge dann bereits. Erstmal einlesen wie Linux funktioniert und dann Blödsinn erzählen wäre was.

    Ich habe mal versucht ein bisschen über das Thema zu recherchieren, aber so einfach ist es nicht, informatinen zu finden.

    Die Gerätedateien /dev/sda etc. werden beim Booten von udev erstellt, allerdings muss der Kernel zum Mounten des Root-Dateisystems auch in der Lage sein, diese Device Nodes auch ohne udev zu erstellen (zumindest wenn man keine initial ramdisk (initrd) verwendet).

    Es ist fast sicher, dass in dem Fall zuerstmal alle Blockdevices vom Kernel enumeriert werden, dann das Root-Dateisystem gemountet wird (gemäß der Parameter, die man dem Kernel vom Bootloader mitgegeben hat) und anschließend udev während des Bootvorgangs all diese Device-Dateien neu erstellt. Sprich: Es kann durchaus sein, dass die Gerätedateien im early boot auf andere Geräte zeigen als später (zumindest ist das mein Verständnis, belegen kann ich das leider nicht).

    In der Regel werden per SATA angeschlossene Geräte vor den USB-Geräten aufgelistet, das kann man aber nicht als gegeben hinnehmen. Schau dir z.B. mal an was passiert, wenn du im laufenden betrieb eine per SATA angeschlossene Platte rausziehst, dann einen USB-Stick einsteckst und danach wieder die SATA-Platte einsteckst. Außerdem gibt es fälle, in denen man einen per USB angeschlossenen Datenträger als Root-Device verwendet.

    Selbst wenn es gegeben wäre, dass sich die Reihenfolge nicht ändert, will man trotzdem noch, dass ein System von ehemals /dev/sdc immer noch bootet, selbst wenn die Festplatte, die ehemals /dev/sdb war, nicht eingesteckt ist.

    Insofern rechtfertigt sich die Existenz von UUIDs durchaus, weil sie einem die Möglichkeit bieten, Dateisysteme zu identifizieren, egal wieviele andere Geräte gerade ein/ausgesteckt oder kaputt sind und in welcher Reihenfolge der Kernel oder udev die Device-Nodes angelegt hat. Ich persönlich verwende für meine fstab allerdings lieber das Dateisystemlabel.

    Übrigens: Die UUIDs haben noch einen anderen Vorteil: Sie bleiben auch dann erhalten, wenn man ein Festplattenimage per dd bzw. Clonezilla wiederherstellt, oder wenn man seine Festplatte in einen anderen Rechner einbaut. Dann kann man nämlich gleich loslegen, und muss nicht erst mit einem Live-System seinen Bootloader und seine /etc/fstab fixen.



    Hier mal ein Artikel aus dem Archlinux-Wiki zu dem Thema: https://wiki.archlinux.org/index.php/Pers…k_device_naming

    Gemäß diesem Artikel ist es eben gerade nicht eindeutig, in welcher Reihenfolge die Block-Devices angelegt werden.