Linux Erfahrung mit AMD Ryzen + nVidia Grafik unter Ubuntu

[bemymonkey]

Moin zusammen,

ich überlege langsam ob ich vielleicht nicht doch auf meiner Arbeitsmaschine (P15v Gen3 AMD) auf Ubuntu umsteigen sollte, jedoch habe ich wegen der Kombi aus dem Ryzen und der nVidia Grafik Bedenken.

Mein letztes Thinkpad mit nVidia Grafik (W550s) hatte unter Ubuntu (ich glaube das war 20.04LTS) das Problem, dass die nVidia Grafik daueraktiv war und auch unterschiedliche Treiber (offiziell nVidia, der Opensource Kram und irgendwelche Switchable-Optimierten) nicht wirklich geholfen haben. Entsprechend schlecht war die Akkulaufzeit und das thermische Verhalten des Systems.

Kann jemand berichten, wie's bei aktuellen Geräten mit AMD + nVidia aussieht? Am Besten unter Ubuntu 22.04LTS, aber ich nehme gerne auch Hinweise basiserend auf anderen Distros entgegen . Muss ich noch zusätzliche Treiber installieren? Kann ich manuell die nVidia ein und ausschalten? Ist die Akkulaufzeit mit ausgeschalteter nVidia Grafik halbwegs so gut wie unter Windows?


Ich hoffe ich hab am Wochenende mal Zeit das mit nem Live-Stick auszuprobieren, aber ich denke Vieles werde ich erst erfahren, wenn ich richtig installiert habe... und dann ist es wahrscheinlich schon zu spät

 

[bemymonkey]

Soooo Leute, nachdem Windows am Freitag mal wieder eine Glanzleistung abgeliefert hat (USB-C Dockingstation abziehen und zuklappen => Hänger beim nächsten Aufklappen - ging nur noch harter Reset mit Power-Taste => Windows-Update-Orgie mit 5 Reboots unter Zeitdruck***) läuft auf dem P15v Gen3 nun Debian 12.

TLP drauf (noch nichts konfiguriert außer Akkuschwellen)
nVidia Treiber laut Anleitung für Bookworm von hier

Sonst noch nicht viel gemacht, und der Idle-Verbrauch im Akkubetrieb mit 70% Helligkeit pendelt sich irgendwo um 12W ein. Da fehlen noch ein paar Watt gegenüber Windows, aber so schlimm wie erwartet ist es jetzt nicht.


I like it!

Danke Euch nochmal für die vielen tollen Tipps



*** Die Fußnote - natürlich war ich im Endeffekt selbst schuld, hatte ich doch früher am Tag von Hand Windows Update angestoßen und nicht *sofort* neu gestartet - das wäre halt eigentlich irgendwann nach Feierabend gekommen. Ooopsie

-edit- Halbwegs erfreuliche Nachricht: Sogar das mit dem Power Button funktioniert einwandfrei mit dem P15v, sprich kein Freeze beim Drücken davon. Scheint vielleicht wirklich am X390 bzw. irgendeiner Low-Level SW dafür zu liegen. Dafür funktioniert mit dem Button Hibernate nicht - der Rechner macht das übliche Geblinke als würde er in den Hibernate gehen, der nächste Start ist aber ein frischer Boot. Mit systemctl hibernate (bzw. Gnome Extension) funktioniert scheinbar alles...

Lustig dabei: Hibernate von 32GB (P15v) dauert eher 4x so lang wie Hibernate von 16GB (X390) - dabei ist doch in meinem X390 eine ziemliche Krücke von SSD (Kingston NV1)... kann das an meiner sehr großen Swap-Partition (hab halt nach Verkleinern der Hauptpartition auf 960GB einfach den verbleibenden Platz genommen - Ziel war eigentlich so 40GB) liegen? Ist jetzt kein Beinbruch, mich wundert's nur

-edit2- Resume dauert auch spürbar länger als beim X390 und Hibernate funktioniert irgendwie nicht ganz deterministisch - ca. jeder zweiter Versuch, egal ob direkt über systemctl oder die Gnome-Erweiterung endet in der Fehlermeldung hier drunter... Da muss ich wohl noch ein Bisschen recherchieren. Das ist wohl etwas für nächstes Wochenende

 

[Schwartz]

Bei mir waren die Sleep-Funktionen sowieso nie ganz wasserdicht unter Linux. Da ging gerne mal was nicht mehr richtig danach. Hibernate schreibt den kompletten RAM auf die Platte, und wenn man noch bedenkt dass SSDs einen Write Cache haben wo die ersten X Gigabyte sehr schnell laufen und die Bandbreite irgendwann wegbricht... nehmen wir an, der Write Cache deckt 10 GB ab - Im Fall von 16 GB RAM laufen 10 GB dann schnell und es wird für die Dauer von 6 GB langsam. Bei 32 GB wären es immerhin 22 langsame GB.

Daran kann es liegen, muss es aber nicht. Der Write Cache könnte auch locker groß genug sein.

 

[bemymonkey]

Ist der Write-Cache nicht meist DRAM-basiert und damit volatil? Das hieße ja, der muss auch komplett auf den normalen NAND weggeschrieben werden und sollte keinen Unterschied machen.
Aber der Ansatz gefällt mir - da merkt man wieder, dass man's hier im Forum echt mit schlauen Menschen zu tun hat

Bei mir waren die Sleep-Funktionen sowieso nie ganz wasserdicht unter Linux.

Das ist natürlich schade. Ich habe auf den ganzen Intelbasierten (also mit integrierter Grafik) die letzten Jahre zumindest mit Suspend gar keine Probleme gehabt. T400, X220, X390, T15 Gen1, T14 Gen2... bei Allen lief mit Ubuntu LTS und jetzt Debian Suspend perfekt OOTB. Bei Debian 12 lief sogar Hibernate auch noch auf Anhieb, sofern die Swap-Partition groß genug eingestellt wurde.

Erst beim T14 Gen3 AMD und P15v Gen3 AMD gibt's bei mir jetzt wieder Probleme. Sogar unter Windows 10 hatte ich bei Beiden unerklärbare Hänger beim Resume, da habe ich mittlerweile tatsächlich AMD im Verdacht... bzw. ehrlich gesagt ein kleines Bisschen den Embedded Controller, der auf der AMD Plattform etwas träger scheint...

Das nächste Arbeits-Thinkpad wird jedenfalls definitiv wieder eins mit Intelgrafik. Vielleicht frage ich heute tatsächlich mal ob sie noch ein freies T490 oder T14 mit Intelgrafik haben, auch wenn's ein massives Display-Downgrade ist

 

[Schwartz]

Ich meinte den SLC-Cache... das sollte mit dem RAM nichts zu tun haben, der Controller schreibt halt einfach und tut so, als wären die NAND-Zellen SLC. Kannst ja mal dazu ein Benchmark laufen lassen und schauen, ab wo die Geschwindigkeit einbricht.

Ach, das sind die Ryzen 6XXX. Die sind ja noch ziemlich neu, da wird an den Chipsettreibern noch gebügelt denke ich mal. Ist natürlich doof aber kennt man ja. Die Hardware ist jedenfalls ziemlich gut, ich hab auch einen Zen 2 und steh total drauf.

Auf Windows soll es helfen wenn "Quick Boot" deaktiviert wird, generell bei Problemen mit dem Suspend.

 

[bemymonkey]

Ich meinte den SLC-Cache... das sollte mit dem RAM nichts zu tun haben, der Controller schreibt halt einfach und tut so, als wären die NAND-Zellen SLC. Kannst ja mal dazu ein Benchmark laufen lassen und schauen, ab wo die Geschwindigkeit einbricht.

Aha! Ja stimmt, NAND-Cache gab's ja auch noch - werde ich mir mal ansehen müssen. Danke für den Tipp!

Ach, das sind die Ryzen 6XXX. Die sind ja noch ziemlich neu, da wird an den Chipsettreibern noch gebügelt denke ich mal. Ist natürlich doof aber kennt man ja. Die Hardware ist jedenfalls ziemlich gut, ich hab auch einen Zen 2 und steh total drauf.

Korrekt, soweit ich mich jetzt erinner' R5 6650U im T14 Gen3 und R7 6850H im P15v. Ich hätte gehofft, dass die nach über nem Jahr seit dem Launch glatter laufen... das erinnert mich jetzt ein Bisschen an die AthlonXP und Athlon64 Tage, die bei mir auch nicht so stabil waren wie ich's gerne gehabt hätte

Sollte ich mir erst mal ein alternatives Arbeitsgerät hinstellen werde ich auf der Kiste etwas Distrohopping betreiben (u.A. das hier im Thread bereits empfohlene Manjaro) und gucken ob die "bleeding edge" Distros sich da besser schlagen.

Auf Windows soll es helfen wenn "Quick Boot" deaktiviert wird, generell bei Problemen mit dem Suspend.

Immer der erste Handgriff bei Win10, das hat leider nichts damit zu tun gehabt


-edit- Wie lang hat das eigentlich bei Zen2 gedauert bis der Linux-Support zu 100% da war? Wobei Du ja schriebst, Du hast immer noch Suspend-Probleme? Das ist für mich auf nem Laptop irgendwie ein wichtiges Kriterium xD

-edit2- Gestern Abend beim letzten Shutdown hat die Kiste unaufgefordert fwupd ausgeführt - seitdem nach 10x Suspend und Resume keine Hänger mehr. Mal sehen ob und wie lang das anhält :O

 

[Schwartz]

Ich nutze nur Win 10 mit dem Ryzen. Testweise lief EndeavourOS als virtuelles System über HyperV und das ohne Probleme, wobei ich Suspend nicht getestet habe. Ich hatte mit dem X200 vor ein paar Jahren noch Probleme mit Suspend, da ging nach dem Aufwachen das WLAN nicht mehr, oder es gab Grafikfehler. In den Foren kamen dann Antworten die so klangen als sollte man Suspend auf Linux besser gar nicht nutzen.