# Migration von AMD FX-8320 auf Ryzen 9 5900x

## Erdie

Hallo allerseits,

ich habe mir eine neues Motherboard + Cpu + Speicher gekauft. Irgenwann mußte das mal sein. Jetzt habe ich gelesen, dass ein System mit "march=native" auf dem Bulldozer gebaut auf Ryzen nicht lauffähig sein soll ergo zum Absturz führt. Man solle das System komplett mit generischen march - flag neu bauen.

Ist das definitiv richtig so bzw gilt das auch für meine Kombination? Wer hat Erfahrung damit? Vielleicht kann jemand mit ein paar Erfahrungen helfen. Wann das richtig ist, welches Flag wäre dann sicher?

Danke und Grüße

Erdie

----------

## Christian99

Ich kanns jetzt nicht konkret für deine CPUs sagen, aber in der Regel haben neuere CPUs zusäztliche Features, und Programme für ältere CPUs sollten auf neueren laufen.

Aber, ob deine CPUs jetzt eine Ausnahme sind, kann ich nicht sagen

----------

## Erdie

 *Christian99 wrote:*   

> Ich kanns jetzt nicht konkret für deine CPUs sagen, aber in der Regel haben neuere CPUs zusäztliche Features, und Programme für ältere CPUs sollten auf neueren laufen.
> 
> Aber, ob deine CPUs jetzt eine Ausnahme sind, kann ich nicht sagen

 

Das habe ich auch immer gedacht aber man schaue mal hier:

https://www.reddit.com/r/Gentoo/comments/do66kb/processor_upgrade_leading_to_invalid_opcode/

Ich möchte vermeiden, dass ich meine Kiste 2x hin und her umbauen muß. Dass ich evtl. sogar erst noch einen alten Ryzen Prozesser besorgen muß, um das MoBo Bios upzudaten, finde ich schon nervig. Aber alles zuurückbauen für eine "-e world" on top wäre dann der Knüller. 

Es kann doch sein, dass hier jemand den Schritt von FX auf Ryzen gemacht hat und aus Erfahrung sagen kann, ob das geht. Diesem Forum vertraue ich weit mehr als sonst jemandem  :Wink: 

Was mich wundert, da spricht einer vom Kernel, dass der wegen XOP in den CPU_FLAGS_X86 neu gebaut werden muß. Bisher dacht ich immer, dass die Flags in der make.conf keine Auswirkungen auf den Kernel build haben, stimmt das etwa nicht?

----------

## firefly

Ich hatte eine Ähnliche Migration:

Von einem Intel i7 4. Generation (2014 gekauft) zu einem Ryzen 9 3900X.

Ich hatte keine Probleme das System zu starten.

Und ich verwende auch march=native.

----------

## Christian99

ich hab mal ein bisschen recherchiert: https://en.wikipedia.org/wiki/XOP_instruction_set

XOP instructions scheint es tatsächlich nicht mehr in ryzen zu geben. Vermutlich ist das das problem.

----------

## Erdie

Danke! Ich mach das dann so: 

Das XOP flag habe ich aus den CPU flags entfernt, denn dass AMD das rausgeworfen hat, stimmt sogar, kann man in der Wikipedia nachlesen. Damit baue ich die wichtigsten Systembestandteile neu und mit dem Stand werde ich es dann probieren. Im Kernel habe ich ein paar Optionen eingebaut, die bzgl Ryzen im Wiki stehen aber im Großen und Ganzen sah meine config ziemlich ähnlich aus.

Jetzt hoffen wir mal schwer, dass das Teil ohne Bios update hochfährt, sonst muß ich mir noch den Ryzen 2 aus dem Rechner meiner Tochter ausleihen. Ich habe sie schon vorgewarnt  :Wink: 

Leider muß ich jetzt von allen Soundkarten Abschied nehmen, da es keine Boards mit PCI Slot mehr gibt  :Sad: 

----------

## mike155

 *Quote:*   

> Ich habe mir eine neues Motherboard + Cpu + Speicher gekauft. Irgenwann mußte das mal sein. 

 

Prima! Habe ich vor 4 Wochen auch gemacht. Ein ASUS TUF Gaming B550-Pro und den brandneuen AMD Ryzen 5700G. Ich bin geradezu begeistert, wie schnell das neue System ist.

 *Quote:*   

> Jetzt habe ich gelesen, dass ein System mit "march=native" auf dem Bulldozer gebaut auf Ryzen nicht lauffähig sein soll ergo zum Absturz führt. Man solle das System komplett mit generischen march - flag neu bauen.

 

Mach's doch so wie ich:

Am alten System beim Kernel die AMD Zen Gen 3 Optionen aktivieren, Kernel neu bauen. Dieser Kernel sollte dann mit dem alten und mit dem neuen System laufen.

Neues System zusammenbauen, alte Festplatte einstecken. 

Einschalten und Booten. Bei mir lief es problemlos. Wenn es nicht problemlos laufen sollte, kannst Du die Festplatte wieder ans alte System anschließen, und die Pakete mit generischen Flags neu bauen.

 *Quote:*   

> Dass ich evtl. sogar erst noch einen alten Ryzen Prozesser besorgen muß, um das MoBo Bios upzudaten,

 

Neuere Mainboards für AMD CPUs können das BIOS auch OHNE Prozessor updaten. Das gab's mal vor ein paar Jahren, dass ma einen alten Prozessor dafür brauchte. Den konnte man sich dann von AMD zuschicken lassen... Bei den neueren Mainboards, die ich mir angeschaut habe, ist das aber nicht mehr notwendig - wie gesagt: die können ein BIOS Update auch ohne Prozessor.

 *Quote:*   

> Leider muß ich jetzt von allen Soundkarten Abschied nehmen, da es keine Boards mit PCI Slot mehr gibt

 

Wahrscheinlich kein Verlust. Die meisten neueren Mainboards haben recht gute Audio-Komponenten on board...Last edited by mike155 on Thu Sep 16, 2021 1:31 pm; edited 2 times in total

----------

## Christian99

nur die cpuflags anzupassen wird nicht reichen, wenn dein System bisher mit march=native gebaut ist.

Die Cpuflags sind nur für solche pakete, die explizit verschiende flags unterstützen und dafür extra codepfade oder ähnliches haben.

march=native betrifft die Codegenerierung des kompilers und trifft immer zu, auch wenn ein Paket keine explizite unterstützung für verschieden Instruction sets hat.

Du solltest wohl am besten @system ohne ein march flag neu bauen, dann die hardware austauschen. das sollte gehen, zumindest kannst du dann soweit booten, dass du dann alles mit march=native neu bauen kannst.

----------

## Erdie

 *Christian99 wrote:*   

> nur die cpuflags anzupassen wird nicht reichen, wenn dein System bisher mit march=native gebaut ist.
> 
> Die Cpuflags sind nur für solche pakete, die explizit verschiende flags unterstützen und dafür extra codepfade oder ähnliches haben.
> 
> march=native betrifft die Codegenerierung des kompilers und trifft immer zu, auch wenn ein Paket keine explizite unterstützung für verschieden Instruction sets hat.
> ...

 

Wenn die CPU bis auf "XOP" abwärtskompatibel sind, dachte ich, sollte es gehen. Ich migriere ja von AMD zu AMD neu. Ich werds einfach versuchen. Das einzige Problem, wenn es nicht klappt, wäre: Ich mußte das Mobo wieder umbauen, da ich keinen kompletten neuen Rechner habe. Naja, mal schauen ..

----------

## Erdie

 *mike155 wrote:*   

> 
> 
> Wahrscheinlich kein Verlust. Die meisten neueren Mainboards haben recht gute Audio-Komponenten on board...

 

Schau mal auf meinen Status unten. Das ist professionelle Hardware, die das vielfache eines Rechners gekostet hat. 24 Kanäle 96kHz mit Störabstand 110dB, symmetrische Leitungen etc. etc. Dagegen kannst du alles, was in irgendwelchen Rechnern verbaut ist, wegschmeissen  :Wink: 

----------

## Erdie

[quote="mike155"] *Quote:*   

> 
> 
> Neuere Mainboards für AMD CPUs können das BIOS auch OHNE Prozessor updaten. Das gab's mal vor ein paar Jahren, dass ma einen alten Prozessor dafür brauchte. Den konnte man sich dann von AMD zuschicken lassen... Bei den neueren Mainboards, die ich mir angeschaut habe, ist das aber nicht mehr notwendig - wie gesagt: die können ein BIOS Update auch ohne Prozessor.
> 
> 

 

Das ist allerdings eine gute Nachricht  :Smile: 

----------

## mike155

 *Erdie wrote:*   

> Das ist professionelle Hardware, die das vielfache eines Rechners gekostet hat. 24 Kanäle 96kHz mit Störabstand 110dB, symmetrische Leitungen etc. etc. Dagegen kannst du alles, was in irgendwelchen Rechnern verbaut ist, wegschmeissen 

 

Ah, okay... Dann ist es natürlich schon ein schmerzhafter Verlust.   :Embarassed: 

----------

## Erdie

 *mike155 wrote:*   

>  *Erdie wrote:*   Das ist professionelle Hardware, die das vielfache eines Rechners gekostet hat. 24 Kanäle 96kHz mit Störabstand 110dB, symmetrische Leitungen etc. etc. Dagegen kannst du alles, was in irgendwelchen Rechnern verbaut ist, wegschmeissen  
> 
> Ah, okay... Dann ist es natürlich schon ein schmerzhafter Verlust.  

 

Mein Plan ist ein PCI-> PCIe Adapter zu probieren. Ob das funktioniert, ist Glücksache. Erstmal die Kiste generell laufen lassen und dann schauen wir weiter.

----------

## schmidicom

@Erdie

Wegen deinen PCI-Karten, du könntest da auch so etwas benutzen:

https://www.exsys-shop.de/shopware/de/kategorien/expansions-boxen/1157/kompakte-expansion-box-pcie-slot-zu-4-x-pci-slots?number=EX-1010

Ich persönlich bin auch kein Fan von den internen Audio-Teilen, aber weniger wegen der Hardware sondern mehr wegen den Treibern. Gerade bei einem Laptop kann man sich damit ein sehr "lustiges" Abenteuer einhandeln.

----------

## Erdie

 *schmidicom wrote:*   

> @Erdie
> 
> Wegen deinen PCI-Karten, du könntest da auch so etwas benutzen:
> 
> https://www.exsys-shop.de/shopware/de/kategorien/expansions-boxen/1157/kompakte-expansion-box-pcie-slot-zu-4-x-pci-slots?number=EX-1010
> ...

 

Das ist Top, danke. Damit werde ich mit dann beschäftigen wenn es erstmal funktioniert.

----------

## Christian99

 *Erdie wrote:*   

>  *Christian99 wrote:*   nur die cpuflags anzupassen wird nicht reichen, wenn dein System bisher mit march=native gebaut ist.
> 
> Die Cpuflags sind nur für solche pakete, die explizit verschiende flags unterstützen und dafür extra codepfade oder ähnliches haben.
> 
> march=native betrifft die Codegenerierung des kompilers und trifft immer zu, auch wenn ein Paket keine explizite unterstützung für verschieden Instruction sets hat.
> ...

 

Das Problem ist aber, dass nicht nur durch die CPUFlags gesteuert wird, welche Instruktionen vom Kompiler erzeugt werden, sondern auch von compileflags. wenn du march=native z.B. anhast, hat gcc potentiell für alle Programme XOP instruktionen erzeugt, unabhängig von CPU_FLAGS.

----------

## Erdie

Wenn das so ist, dann fang ich wohl wieder von vorne an, nur weiß ich nicht wie das generische flag denn nun heißt.

P.S Ich nehme mal an es ist "generic" ..

EDIT: Nein, das ist es nicht, da liefert gcc eine Fehlermeldung  :Sad: 

----------

## Josef.95

Du suchst vermutlich ‘x86-64’

-march=x86-64

–> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

----------

## Christian99

es reicht einfach kein march flag zu setzen, dann ist es generisch

----------

## michael_w

 *Josef.95 wrote:*   

> Du suchst vermutlich ‘x86-64’
> 
> -march=x86-64
> 
> –> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

 

warum nicht gleich "-march=znver2"?

----------

## Erdie

Ich habe jetzt "k8" gewählt, denn das ist eine ältere Architektur als FX aka Bulldozer und zu der sollte Ryzen abwärtskompatible sein. Leider konnte ich Eure Kommentare nicht mehr lesen und habe die ganze Nacht durchkompiliert. Die Maschine ist noch nicht fertig aber  ich werde vorher abbrechen. Wenn ein paar Anwendungsprogramme nicht stabil laufen, dass sollte für den Rebuild dannach unerbehlich sein.

----------

## Christian99

wie schon weiter oben erwähnt, solltest du sicherstellen, das alle pakete aus @system neu gebaut sind. Damit kannst du booten und emergen.

K8 sollte zu ryzen kompatibel sein.

 *Quote:*   

> warum nicht gleich "-march=znver2"?

 

Weil das erst noch mit der alten CPU stattfindet und dann einfach die CPU getauscht werden soll, deswegen braucht man quasi etwas, mit dem beide CPUs klar kommen.

----------

## Erdie

Jetzt bin ich soweit. Das Bios war akutell genug um die cpu zu erkennen. Ich flashe gerade auf die neuste Version.

Momentanes Problem: Das Bios erkennt alle Platten erwartungsgemäß und zeigt sie im Setup auch an. Leider bootet das System nicht, da offenbar der MBR nicht gefunden wird. Ich nehme an, es liegt daran, dass ich DOS Partitionen und keine GPT verwendet habe. Ich hatte gehofft, dass es im lagacy Mode funktioniert. Es scheint aber irgendwie nicht zu funktionieren. Jettzt werte ich auf das Bios update und mache mich auf die Suche ob ich irgendeine Option im bios übersehen habe. Es sah aber nicht dannach aus.

----------

## Erdie

Sysemrescuecd startet. Mit der bin ich jetzt online. Die Frage ist: Was kann man tun um den Rechner zum booten von der Festplatte zu ueberreden, ohne eine Neuinstallation machen zu muessen (hab keine deutsche tastatur, hier steht ein fragezeichen)

----------

## Max Steel

Eigentlich müsste es helfen mal den legacy boot zu aktivieren und mal alle Fesplatte zu testen. IRgendeine wird schon klappen. Notfalls den bootloader von der sysresccd nutzen um temporär deinen KErnel und damit dein System zu starten.

----------

## Erdie

Im Bios setup wird der Festplattentyp incl Herstelleer genau angezeigt. Meine boot platte ist eine 128G Intenso SSD, home liegt auf einer 1TB Samsung und eine dritte 128GB ist fuer temporaere daten. Im Bios steht das 1. boot device "intenseo ssd"  Aber das System findet gar nichts. Ich kann ja nochmal die andere platte als 1. device angeben aber das waere definitiv falsch aber man weiss ja nie.

----------

## mike155

 *Max Steel wrote:*   

> Eigentlich müsste es helfen mal den legacy boot zu aktivieren und mal alle Fesplatte zu testen. 

 

Bei dem Wechsel auf mein neues Ryzen System habe ich das am Anfang auch so gemacht - das hat sehr gut funktioniert.

Nachdem das System fertig eingerichtet war und lief, habe ich das Partitionierungs-Verfahren der Festplatte von MBR auf GPT umgestellt und den "legacy boot" im BIOS wieder deaktiviert. 

Danach habe ich GRUB (=Bloatware) rausgeschmissen. Ich verwende den Boot-Manager des Mainboards.

2 sollte man machen, falls möglich. 3 ist rein optional - und hängt davon ab, ob man GRUB mag/benötigt oder nicht.

 *Max Steel wrote:*   

> Notfalls den bootloader von der sysresccd nutzen um temporär deinen Kernel und damit dein System zu starten.

 

Auch das ist ein sehr wertvoller Hinweis! Ich habe immer einen USB-Stick mit SytemRescue hier liegen. Der hat mir schon unzählige Male geholfen - insbesondere auch die Option "installiertes System booten".

----------

## Erdie

Festplattenproblem behoben: Es war trivial, ein Stromkabel war rausgerutscht, leider habe ich 2 Intenso SSD Platten und ich hatte die falsche im bios gesehen. Aber jetzt habe ich ein richtiges Problem:

Der Kernel bootet und openrc bricht beim Bootvorgang ab: "invalid optcode in ....<adresse>... trap in libropenc.so.  (oder hieß es librc? ich weiß nciht mehr so ganau) usw ich habs nicht abfotografiert.

Da ich nicht alles neu gebaut hatte, sind doch noch inkompatible binaries übrig, die essentiell sind.. Was kann ich tun? Hardware zurückbauen und neu compilieren oder manuell die libopenrc in der System kopieren?  Das Booten des Systems von der systemrescuecd hat nicht geklappt, aber das kann es ja auch nicht wenn das binär ncith paßt.

Jetzt habe ich genau den Schlamassel, den ich eigentlich vermeiden wollte  :Sad: 

----------

## mike155

Boote mal komplett von SystemRescue und wechsle dann mit dem Mount/Chroot-Trick auf Dein System auf der Festplatte (wie bei der Erstinstallation). Prüfe dann, ob GCC usw läuft. Wenn ja, musst Du vielleicht nur OpenRC (und evtl. ein paar weitere Pakete) neu bauen. Möglich wäre dann auch ein "emerge --empty @system" bzw. "emerge --empty @world"Last edited by mike155 on Fri Sep 17, 2021 12:26 pm; edited 2 times in total

----------

## firefly

Du hättest wohl eine emere -e @system machen sollen und komplett durchlaufen lassen sollen

Du könntest via livecd booten ein chroot machen und dann openrc neu emergen.

Mit der hoffnung, dass der rest, welches für das bauen von paketen benötigt wird, ohne diesen invalid opcode schon gebaut wurden.

Ansonsten bleibt wohl nur zurückbauen. Denn wenn openrc noch nicht neu gebaut wurde, ist die warscheinlichkeit groß, dass andere pakete, welche beim systemstart genutzt werden, auch nicht neu übersetzt wurden.

----------

## firefly

Wobei wenn chroot funktioniert und man pakete bauen kann, dann kann man hier auch ein emerge -e @system direkt laufen lassen. Dann ist sicher dass das system zu mindestens bis zu einem terminal login booten kann.

Das booten in einen display manager sollte man in dieser phase deaktivieren.

Oder du führst ein emerge -e @world in der chroot umgebung durch

----------

## Erdie

Ja das werde ich mal probieren btw. die systemrecsuecd läuft mit systemd, meine system nicht, könnte das ein Problem sein? theoretisch sollte es ja egal sein. Ich probier mal ein chroot

----------

## Max Steel

Nein das wird kein Problem sein.

----------

## Erdie

Ich bin jetzt in der chroot Umgebung und ein

```
emerge -ave1 @system laeuft!
```

und zum Glueck sogar ziemlich schnell  :Cool: 

Das bauen von openrc allein hat nicht gereicht, Es kam zu wieteren Fehlern aber openrc hatte dannach funktioniert. Ich bin auf dem Weg der Besserung   :Smile: 

Ich kann jetzt schon sagen: Die Zeilen scrollen mit derart atemberaubender Geschwindigkeit ueber die Konsole, da wird einem regelrecht schwindelig. Ich hatte zunaechst makeops Variable noch nicht geaendert aber als der Takmanager maximal 10-15% Auslastung angezeit hatte, habe ich nochmal gestoppt und bin auf j16 hochgegangen (erstmal vorsichtig, die cpu kann ja 24) Jetzt schaffe ich maximal 70% Auslastung und das nur bei sehr kurzen Peaks. Geschaetzt ist die Zeit von configure und das Wegschreiben der Daten zeitaufwaendger als das eigentliche Kompilieren.

----------

## Erdie

Inzwischen ist das System wieder bootfähig. Also ich kann mit Sicherheit sagen: Ausnahmlos alle binaries funktionieren nicht auf dem Ryzen - unabhängit davon, ob irgendwelche features genutzt werden oder nicht. Jetzt muß ich ja alles wieder bauen, dabei frage ich mich: Gibt es keine Möglichkeit, das Subset world - system zu bauen?. Die System pakete habe ich inzwischen mit march= native incl der korrekten cpu flags gebaut, da wäre es ja nicht nötig gewesen das innerhalb von world nochmal zu wiederholen, aber ich habe keine Möglichkeit gesehen, das zu vermeiden.

----------

## mike155

Zuerst einmal: Herzlichen Glückwunsch zu Deinem neuen und schnellen System! Die Ryzen Prozessoren sind schon klasse!

Zu Deiner Frage: bei emerge gibt es die Exclude-Option. Damit kannst Du die größeren Pakete aus @system überspringen:

```
emerge --empty --exclude="gcc binutils glibc" -av @world
```

----------

## Erdie

Das System ist jetzt fertig und ich habe gerade festgestellt, dass ich beim bauen die ganze Zeit nur 8 Kerne verwendet habe, da in meiner Kernel config die Option:

```
Processor type and feature - max count cores
```

auf 8 beschränkt war. Ich habe das dann auf 24 erhöht und beim nächsten boot gab es dann einen Kernel Panic. Man konnte gearde noch erkennen, dass es ein Problem beim Laden der virtualbox-modules gegeben haben könnte. Ich habe dann mit der LiveCD den Kern neu gebaut und vorläufig auf 8 beschränkt und dannach virtualbox-modules reemerged. Dann habe ich die Kernel auf einen anderen Name kopiert als Backup und dannch grub-mkconfig aufgerufen.

Beim nächsten Boot erscheint der backup Kernel ganz oben in der Liste mit gleichem Namen wie der, von dem er kopoert wurde. Das ist saudämlich, ein Grund warum ich grub2 nicht mag. Wie kann man erreichen, einen Kern mit gleichem Release unter anderem Namen erscheinen zu lassen und wie kann man die Reihenfolge in der Liste beeinflussen?

Ja, man kann die grub.cfg manuell editieren aber ich möchte ungern ein neues Desaster und bin daher vorsichtig. Darf man das label  des Kerns in der Datei ungestraft ändern?

----------

## Erdie

Es lag tatsächlich an der max core Einstellung, man muß dannach die virtualbox-modules neu bauen, sonst kallt´s. Was es nicht alles gibt?!

Ich habe mal einen kleinen Test gemacht: Der Firefox braucht zum bauen genau 12 Minuten wenn ich ihm 16 Kerne gebe. Wahrscheinlich gehst schneller mit mehr Kernen aber das probier ich erstmal langsam aus, denn die Temperatur geht dabei schon über 70°C.

Noch ein paar Sachen fürs Protokoll:

Bei Rebuild gab es einen Abbruch bei json-c, weil in der configure Phase Doxygen aufgerufen wird um die Version zu ermitteln. Doxygen stand aber weiter hinten in der Liste, es wird wohl nicht als Abhängigkeit von json-c geführt, und es ist bei Aufruf erwartungsgemäß gecrasht. Die configure Phase von json-c wurde daher abgebrochen. Ist das ein Grund für einen Bug?

----------

## firefly

bezüglich grub2.

Ich verwende eine komplett selbst erstellte grub.cfg. Da ich eh nur gentoo auf dem system habe und ich dadurch eine generierte version nicht brauche.

Bzw. die damit möglichen zusätzlichen features.

Meine sieht wie folgt aus (ein paar sachen sind uefi spezifisch da ich auf dem neuen system von legacy bios auf uefi umgestellt habe)

```

set timeout=1

set default=0

menuentry 'Gentoo Linux ' {

    insmod part_gpt

    insmod all_video

        linux /boot/bzImage-5.12.14 root=PARTUUID="<uuid>" quiet net.ifnames=0 init=/lib/systemd/systemd

        initrd /boot/amd-uc.img

}

menuentry 'Gentoo Linux (prev)' {

    insmod part_gpt

    insmod all_video

        linux /boot/bzImage-5.11.17 root=PARTUUID="<uuid>" quiet net.ifnames=0 init=/lib/systemd/systemd

        initrd /boot/amd-uc.img

}
```

----------

## Erdie

Danke, sowas muß ich mir auch mal bauen.

Nochmal zur Performance: ich habe nur mal testweise makeops auf 24 erhöht und dann nochmal firefox gebaut. Es macht keinen Unterscheid d. h. es bleibt bei ca. 12 Minuten. Die Zeit für das Festpaltten IO ist wohl der maßgebliche Faktor und die "2threads pro Kern" Methode hilft hier nicht wirklich. Ich bleibe daher erstmal bei 16.

----------

## firefly

Eventuell hilft eine RAM-Disk für /var/tmp/portage um das ganze etwas zu beschleunigen.

Ich verwende eine RAM-Disk schon länger. Früher via tmpfs und seit ca. einem halben jahr via zram (mit zstd compression)

Auf meinem system Ryzen 9 3900X, 32 GB-Ram und MAKEOPTS="-j18" dauert Firefox ~14min.

Da der 5900X was die Performance betrifft schneller ist als der 3900X könnte der Unterschied auch nur rein an der Prozessorleistung liegen.

Gut möglich ist auch, dass der code von Firefox sich nicht gut parallel bauen lässt (wegen diversen Abhängigkeiten der einzelnen code files zueinander)

----------

## Erdie

Ich habe noch einen kleinen Fehler gemacht. Als ich angefangen habe, habe ich übersehen, dass die Systemzeit ca 8 Stunden in der Zukunft liegt. Beim Aufbau ist mir das aufgefallen und ich habe vorsorglich den ntpd abgeschaltet, damit die Zeit nicht on the fly korrigiert es somit Zeitstempel in der Zukunft gibt. Insbsondere die Mariadb, welche von kdepim verwendet wird, könnte dadurch aus dem Takt geraten. Mein Strategie ist daher: Abends vor dem Schafengehen ins Bios und die Uhr einstellen, dann die Rechner 8 STunden ruhen lassen. Eine bessere Idee fällt mir dazu nicht ein.

----------

## firefly

Das macht der ntpd eben nicht. Der gleicht die lokale Uhrzeit der tatsächlichen schrittweise an, um genau sowas zu vermeiden, dass es zeitstempel gibt, welche in der zukunft der lokalen uhr liegen

Die Uhrzeit wird hard gesetzt wenn man z.b. ntp-date verwendet

----------

## mike155

Aber nicht bei 8 Stunden Zeitdifferenz. Da startet der ntpd erst gar nicht, wenn man ihm nicht erlaubt, die Zeit einmalig "hart" zu setzen...  :Smile: 

Siehe "man ntpd", Optionen "-g", "-G", "-x".

----------

## Erdie

Ich denke, die Sache ist jetzt erledigt. Ich danke Euch nochmal herzlich für alle Tips und Anregungen! Was nicht heissen soll, dass wir hier noch über dieses oder jenes quasseln können. 

Apropos quasseln: Die CPU Temperaturen sind erstaunlich hoch. Als das Gerhäuse offen war, ging es beim kompilieren knapp über 70° Ab und zu auch bis 75. Mit Deckel drauf und Gerhäuselüfter erreicht er dann doch zu "Spitzenzeiten" tatsächlich 80°. Erst hat mich das geschockt bis ich gelesen habe, dass das wohl by Ryzen halbwegs normal sein soll. Also glauben wir es einfach erstmal ..

----------

## Josef.95

AMD gibt für die Ryzen 9 5900X CPU in ihren Specs max 90°C an.

Wenn jetzt (bei den aktuell eher kühlen Herbsttemperaturen) schon 80°C erreicht werden, dann könnte es mit dem aktuellen Kühlsystem im Sommer wenn es mal richtig warm wird vermutlich knapp werden.

Und bezüglich der Soundkarten: Es gibt auch PCIe auf PCI Adapterkarten (hab ich aber noch nicht getestet).

----------

## Erdie

 *Josef.95 wrote:*   

> 
> 
> Wenn jetzt (bei den aktuell eher kühlen Herbsttemperaturen) schon 80°C erreicht werden, dann könnte es mit dem aktuellen Kühlsystem im Sommer wenn es mal richtig warm wird vermutlich knapp werden.
> 
> .

 

Ich habe da zum Glück einen kleinen Vorteil: Der Rechner steht im Keller! Da ist es auch im Sommer recht kühl. Aber klar, etwas wämer ist es dann schon und es könnte grenzwertig werden. Mein Kühler ist übrigens dieser hier:

https://www.bequiet.com/de/cpucooler/1659

Mir bleibt im Sommer (wenn denn mal doch wieder einen bekommen, der letze war ja ein Blindgänger) noch das Gehäuse zhu öffenen. Das mache nach  meinen Beobachtungen ca 5° aus.

Oh, es kommen gerade neue "Testcases" reingeflogen: Libreoffice und qtwebengine lol  :Wink:  Ich habe jetzt mal das Gehäuse aufgemacht während quwebengine kompiliert und es sind 5° Unterschied.

----------

## Erdie

welchen CPU frequency scaling governor verwendet ihr eigentlich?

----------

