Nach inzwischen ziemlich genau vier Jahren mit meinem Core i7-6700k wurde es mal wieder Zeit für neue Hardware. Weil es inzwischen doch deutlich mehr Leistung gibt, weil ich ein AMD-Fanboy bin, aber vor allem, da sich meine Intel-CPUs langsam in Elektroschrott verwandelt.
Meine alter Sandy Bridge Core i7-2600k ist inzwischen fast unbenutzbar, der Skylake Core i7-6700k hat ziemlich Federn lassen müssen und in nach eigenen Angaben gut informierten Kreisen munkelt man, dass es Anfang Herbst noch eine Runde sehr leistungsfressender Mitigations brauchen wird... An dieser Stelle auch noch mal Danke an Intel für das wirklich gute, die Bedürfnisse der Kunden ernst nehmende Krisenmanagement.
Wie dem auch sei, ein Ryzen 3000 sollte es werden und wurde es dann am 07.07.2019 zum Start auch gleich. Da mich diverse Leute gefragt haben, ob ich meine Eindrücke aufschreiben könnte, mache ich es hier einmal. Es wird kein Review der Ryzen 3000 Serie, davon gibt es im Netz inzwischen mehr als genug und sie alle sind besser, als ich es könnte.
Die Hardware
* AMD Ryzen 3700X (8 Kerne, 3,6GHz Basistakt, 4,4GHz Maximaltakt)
* 2x Corsair CMK32GX4M2B3200C16 RAM-Kit (4x16GB, 3200MHz, CL16-18-18-36)
* Asus TUF B450M-PRO GAMING
* PowerColor Radeon RX 580 Red Dragon V2
* Samsung 970 Pro
* Crucial MX500 2TB
* Seasonic Focus Plus Platinum 550W
* Fractal Design Define Mini C
* 2x Noctua NF-A14 ULN, Noctua NF-A14 FLX, Noctua NH-U12S
Ziel war es ein möglichst leises, im Leerlauf idealerweise unhörbares System mit überschaubarem Wärmeeintrag zu bauen. Leise, weil mich das Rauschen nervt und ein geringer Wärmeeintrag, da bei meinen etwas über 20m² die Heizleistung von ein paar hundert Watt nicht zu unterschätzen ist. Gerade im Sommer.
Der Ryzen 3700X dürfte zusammen mit dem noch einmal gut 100€ günstigeren Sechskerner 3600X das Rückgrat der Ryzen 3000 Serie bilden. Für derzeit 350€ bekommt man 8 Kerne mit SMT, 3,6GHz Basistakt und 4,4GHz maximaler Takt. Die TDP beträgt sehr geringe 65W, bei meinem Exemplar liegt das Powerlimit bei moderaten 88W.
Die Corsair CMK32GX4M2B3200C16 sind Dual-Rank Riegel zu je 16GB, also insgesamt 64GB. Verbaut werden Samsung K4A8G085WB-BCPB und Hynix H5AN8G8NAFR-TFC, ich habe die als sehr kompatibel mit Ryzen geltende Samsung Variante. Das ist das in einigen Foren fast schon religiös bejubelte B-Die. Corsair garantiert 3200MHz bei 1,35V (das heißt nicht, dass man sie praktisch auch erreichen kann) und recht guten Latenzen von CL16-18-18-36. Damit sind alle 8 Ranks belegt, dass ist nicht wenig und AMD spezifiert da dann auch nur noch 2666MHz. Trotz dessen und der noch recht frühen BIOSe ließen sich die 3200MHz einstellen, wurden auf Anhieb und ohne Gebastel übernommen und überlebten eine Nacht mit memtest86.
Das Asus TUF B450M-PRO GAMING ist ein durchschnittliches Mainboard und sehr ähnlich zu den ca. anderen 70 B450-Modellen auf dem Markt. Ich habe es genommen, da es mit dem Realtek S1220A einen besseren Soundchip hat und Asus zwar relativ zögerlich mit BIOS-Updates ist, ihre BIOSe dafür aber meist gut funktionieren. Die B450-Modelle sind inzwischen ein gutes Jahr auf dem Markt, FreeBSD erkannte auf Anhieb alle Hardware. Die NIC von Realtek kommt mit einem guten ROM und machte in meinen Testläufen keine Probleme. Ansonsten kann man die leider unvermeidbaren RGB-LEDs im BIOS abschalten (bei den beliebten MSI-Boards braucht man dazu ein Tool im Betriebssystem) und die hässlichen Plastikabdeckungen lassen sich mit nur zwei Schrauben abbauen.
Zu beachten ist, dass das Board ein neues BIOS braucht, um Ryzen 3000 zu unterstützen. Ich habe mir bei Bekannten eine CPU zum Flashen ausgeliehen, aber einige Händler bieten gegen meist zu viel Geld auch an das BIOS zu aktualisieren. AMD startet dieses Jahr auch wieder ein Service-Aktion [0]. Meine Test habe ich mit Version 1607 gemacht. Es basiert auf AGESA 1.0.0.2, hat damit den RDRAND-Bug (wahrscheinlich ein Problem mit der Firmware des CCP 5.0) und ein passives Boostverhalten. Es wird sicher noch Updates geben, welche die Probleme lösen.
Warum kein X570? Ganz einfach. Der X570 braucht relativ viel Strom und ist aktiv gekühlt, ich brauche weder PCIe 4 Support, noch die weiteren PCIe-Lanes. Interessant wäre lediglich die verdoppelte Anbindung zwischen dem Chipsatz und der CPU. Aber das ist den doch sehr hohen Aufpreis nicht wert und vor allem mit FreeBSD ist es meiner Erfahrung nach besser auf etwas ältere, etablierte Hardware zu setzen.
Die Radeon RX 580 nähert sich ihrem Lebensende. Die Radeon 5700XT sieht zwar sehr sexy auf, aber ich werde da noch auf Custom-AIBs warten und der Treibersupport sollte auch einige Monate reifen. Zumindest bis Linux 5.3 erschienen ist. Auch zu den SSDs muss man nicht viel sagen. Das Seasonic Netzteil ist ein hocheffizientes, semipassiv gekühltes Modell der mittleren Leistungsklasse. Irgendwie gibt es in den letzten Jahren einen ungesunden Trend zu immer größeren Netzteilen, in der Praxis dürften die 550W für mehr als 95% der Anwender locker ausreichen.
Für das Fractal Design Define Mini C Gehäuse habe ich mich entschieden, da es als MicroATX-Gehäuse relativ kompakt ist (es gibt noch kompaktere Modelle, aber viel weniger Volumen bringt es nicht), Grafikkarten voller Länge aufnehmen kann und einen guten Innenaufbau hat. Es unterteilt sich in eine gedämmte Hauptkammer und eine kleinere Kammer für das Netzteil und diee Laufwerke. Die Haupkammer bietet auf der Vorderseite Platz für zwei 140mm Lüfter, die such über die ganze Höhe erstrecken. Da setze ich die beiden langsam laufenden, unhörbaren Noctuas ein. Hinten ist Platz für einen 120mm Lüfter, dort kommt ein per PWM synchron zum CPU-Kühler geregelter 120mm Noctua zum Einsatz. Unter dem Strich ist das Gehäuse sehr gut durchlüftet und das System im Leerlauf unhörbar, unter Last rauscht es leise. Im Leerlauf erreicht die CPU ca. 33°C, unter Last ca. 55°C. Bei knapp 22°C Raumtemperatur.
FreeBSD
Eigentlich soll ein Linux auf die Kiste, FreeBSD bleibt auf dem Core i7-6700k. Allerdings habe ich es mir natürlich nicht nehmen lassen FreeBSD einmal zu testen. FreeBSD 12.0 bootet problemlos durch und erkennt alle Hardware, ich habe für meine Tests allerdings ein aktuelles 13-CURRENT gebaut. Vor allem, da ich den aktuellen amdgpu Treiber wollte. Dazu gleich mehr, für eine reine FreeBSD-Maschine hätte ich aber eine Nvidia-Karte genommen.
Einzig die Temperatursensoren wurden nicht sofort erkannt. Ich habe die Device-IDs in den amdtemp Treiber gepatcht, damit funktionierte es. Allerdings wird nur ein einziger Sensor erkannt, ich vermute stark, dass es der Sensor des IO-Die ist und nicht ein Sensor im CCD. Das macht ihn recht aussagelos.
FreeBSD erkennt die recht komplexe Topologie korrekt:
Auch P-States und C-States werden exakt wie unter Linux erkannt und genutzt. Auch dazu unten noch etwas mehr.
Die Realtek-NIC läuft wie gesagt problemlos:
Sound, zusammen mit der Radeon. Zur Abwechslung kommuniziert das BIOS nur Ausgänge, die auch vorhanden sind:
Die Radeon 580 funktionierte mit aktuellem graphics/drm-devel-kmod problemlos. Trotz UEFI-Boot! Einfach amdgpu.ko geladen, dazu noch x11-drivers/xf86-video-amdgpu installiert, X.org gestartet und es ging. Mit OpenGL, Vulkan und vollem Powermanagement. Allerdings kommt es ab und an zu GPU-Hängern, sie haben sich zwar jedes Mal von alleine gefangen, aber es nervt doch etwas.
Powermanagement
Ich habe mich in den letzten Wochen sehr tiefgehend mit Powermanagement unter FreeBSD beschäftigt, viele Mails geschrieben, Patches getestet, gemessen, theoretisiert... Ich könnte viel dazu schreiben, aber erspare es euch mal.
Nur so viel: Seitdem ca. 2003 P-States (Frequenzskalierung, das was powerd und powerd++ machen) und C-States (Schlafmodi für die Kerne) aufkamen, ist Power Management immer mehr Sache der Software geworden. Bis einschließlich Sandy Bridge (Core i-2000 Serie) konnten die Kernel neben Windows und Linux noch gut mithalten, seitdem fielen sie immer mehr zurück. Das betrifft alle BSDs. Intel wurde sich dem Problem der immer komplexeren Anforderungen an die Software irgendwann bewusst und führte mit Skylake (Core i-6000 Serie) hwpstate, auch als Speedshift bekannt, ein. Damit wird das Powermanagement wieder in die Hardware zurückverlagert. FreeBSD und co. können davon bisher aber nicht profitieren, da weiterhin etwas Softwareunterstützung benötigt wird. Intel entwickelt die unter seinem FreeBSD-Sponsorship gerade und die ersten Patches sind sehr vielversprechend [1].
AMD geht einen anderen Weg. Dort versucht man die Software weitgehend außen vor zu lassen, man gibt ihr lediglich die Möglichkeit eine Abwägung zwischen Stromersparnis und Leistung vorzugeben. Dafür setzt man auf CPPC2, einem offenen, in UEFI enthaltenen Standard. FreeBSD hat auch dafür noch keine Unterstützung, das ist allerdings nicht weiter schlimm, die CPU hat sinnvolle Standardwerte gesetzt. Das ist sicher kein Entgegenkommen an FreeBSD, sondern eher Pragmatismus hinsichtlich Microsofts immer noch vorhandener Intel-Fokussierung.
Wie oben schon geschrieben, werden P-States unterstützt. FreeBSD sieht die gleichen Frequenzen wie Linux, beginnend bei 2000MHz und endend bei 3601MHz. Sie zu nutzen hat aber weder unter Linux, noch unter FreeBSD messbare Auswirkungen. powerd oder powerd++ mitlaufen zu lassen, hat keine Auswirkungen auf den Verbrauch an der Steckdose, auf die von sysutils/turbostat gemessenen Verbrauchswerte und auch nicht auf das reale Taktverhalten. Kurz gesagt, man kann es sich sparen.
Auch C-States werden unterstützt, allerdings werden sowohl unter Linux, als auch FreeBSD nur C1 und C2 kommuniziert. Auch turbostat und powertop (nur für Linux) sehen keine tieferen States. C2 zu erlauben, bringt sowohl unter Linux, als auch FreeBSD etwa 0,3W an der Steckdose. Weitere Auswirkungen hat es nicht.
Unter dem Strich komme ich auf ca. 44W an der Steckdose unter Linux und 48W an der Steckdose unter FreeBSD. Diese 4W Unterschied sind sehr gut, bei meinem Core i7-6700k bin ich (ohne die Patches für hwpstate-Support) nie unter 22W Unterschied gekommen. Vor allem aber bleibt es sowohl in Teillast, als auch unter Volllast bei ca. 4W. Während der Core i7-6700k vor allem im Teillastbetrieb unter FreeBSD auf bis zu 35W gegenüber Linux zurückfiel.
Ich kann es nicht wirklich beweisen, aber ich vermute, dass die CPU an sich unter Linux und FreeBSD sogar ähnlich viel oder wenig Energie benötigt. Der Unterschied scheint mir eher auf das Mainboard zurückzugehen, FreeBSD unterstützt anders als Linux auch kein HDA-Powersave für die Soundkarte und kein Powersave für die Realtek-NIC.
Interessant ist auch die Frequenzskalierung. Der Core i7-6700k kam ohne die Patches für hwpstate-Support nie über Basisfrequenz hinaus. Der Ryzen 3700X hingegen erreicht bei Last auf bis zu 2 Kernen sowohl unter Linux, als auch unter FreeBSD etwa 4320MHz dauerhaft. Die 4400MHz habe ich auf beiden Systemen nie gesehen, obwohl genügend Energie und Wärme-Budget vorhanden wäre. Das wird das AGESA 1.0.0.2 sein. Unter Volllast pendelt er sich unter beiden Systemen auf 3950MHz ein.
Leistung
Dann noch kurz, was das Blech auf die Straße bringt. Das sind keine sauber durchgeführten Messungen! Wie gesagt, es gibt genügend Reviews im Netz. make -j$(sysctl -n hw.ncpu) buildworld mit Sourcen und Objekten auf einem tmpfs. Sourcen waren 13-CURRENT von gestern.
Core i7-6700k: 57:25 Minuten
Ryzen 3700X: 24:53 Minuten
Also etwas mehr als doppelt so schnell.
0: https://www.amd.com/en/support/kb/faq/pa-100#faq-Short-Term-Processor-Loan-Boot-Kit
1: https://github.com/bwidawsk/freebsd/tree/hwp2
Meine alter Sandy Bridge Core i7-2600k ist inzwischen fast unbenutzbar, der Skylake Core i7-6700k hat ziemlich Federn lassen müssen und in nach eigenen Angaben gut informierten Kreisen munkelt man, dass es Anfang Herbst noch eine Runde sehr leistungsfressender Mitigations brauchen wird... An dieser Stelle auch noch mal Danke an Intel für das wirklich gute, die Bedürfnisse der Kunden ernst nehmende Krisenmanagement.
Wie dem auch sei, ein Ryzen 3000 sollte es werden und wurde es dann am 07.07.2019 zum Start auch gleich. Da mich diverse Leute gefragt haben, ob ich meine Eindrücke aufschreiben könnte, mache ich es hier einmal. Es wird kein Review der Ryzen 3000 Serie, davon gibt es im Netz inzwischen mehr als genug und sie alle sind besser, als ich es könnte.
Die Hardware
* AMD Ryzen 3700X (8 Kerne, 3,6GHz Basistakt, 4,4GHz Maximaltakt)
* 2x Corsair CMK32GX4M2B3200C16 RAM-Kit (4x16GB, 3200MHz, CL16-18-18-36)
* Asus TUF B450M-PRO GAMING
* PowerColor Radeon RX 580 Red Dragon V2
* Samsung 970 Pro
* Crucial MX500 2TB
* Seasonic Focus Plus Platinum 550W
* Fractal Design Define Mini C
* 2x Noctua NF-A14 ULN, Noctua NF-A14 FLX, Noctua NH-U12S
Ziel war es ein möglichst leises, im Leerlauf idealerweise unhörbares System mit überschaubarem Wärmeeintrag zu bauen. Leise, weil mich das Rauschen nervt und ein geringer Wärmeeintrag, da bei meinen etwas über 20m² die Heizleistung von ein paar hundert Watt nicht zu unterschätzen ist. Gerade im Sommer.
Der Ryzen 3700X dürfte zusammen mit dem noch einmal gut 100€ günstigeren Sechskerner 3600X das Rückgrat der Ryzen 3000 Serie bilden. Für derzeit 350€ bekommt man 8 Kerne mit SMT, 3,6GHz Basistakt und 4,4GHz maximaler Takt. Die TDP beträgt sehr geringe 65W, bei meinem Exemplar liegt das Powerlimit bei moderaten 88W.
Die Corsair CMK32GX4M2B3200C16 sind Dual-Rank Riegel zu je 16GB, also insgesamt 64GB. Verbaut werden Samsung K4A8G085WB-BCPB und Hynix H5AN8G8NAFR-TFC, ich habe die als sehr kompatibel mit Ryzen geltende Samsung Variante. Das ist das in einigen Foren fast schon religiös bejubelte B-Die. Corsair garantiert 3200MHz bei 1,35V (das heißt nicht, dass man sie praktisch auch erreichen kann) und recht guten Latenzen von CL16-18-18-36. Damit sind alle 8 Ranks belegt, dass ist nicht wenig und AMD spezifiert da dann auch nur noch 2666MHz. Trotz dessen und der noch recht frühen BIOSe ließen sich die 3200MHz einstellen, wurden auf Anhieb und ohne Gebastel übernommen und überlebten eine Nacht mit memtest86.
Das Asus TUF B450M-PRO GAMING ist ein durchschnittliches Mainboard und sehr ähnlich zu den ca. anderen 70 B450-Modellen auf dem Markt. Ich habe es genommen, da es mit dem Realtek S1220A einen besseren Soundchip hat und Asus zwar relativ zögerlich mit BIOS-Updates ist, ihre BIOSe dafür aber meist gut funktionieren. Die B450-Modelle sind inzwischen ein gutes Jahr auf dem Markt, FreeBSD erkannte auf Anhieb alle Hardware. Die NIC von Realtek kommt mit einem guten ROM und machte in meinen Testläufen keine Probleme. Ansonsten kann man die leider unvermeidbaren RGB-LEDs im BIOS abschalten (bei den beliebten MSI-Boards braucht man dazu ein Tool im Betriebssystem) und die hässlichen Plastikabdeckungen lassen sich mit nur zwei Schrauben abbauen.
Zu beachten ist, dass das Board ein neues BIOS braucht, um Ryzen 3000 zu unterstützen. Ich habe mir bei Bekannten eine CPU zum Flashen ausgeliehen, aber einige Händler bieten gegen meist zu viel Geld auch an das BIOS zu aktualisieren. AMD startet dieses Jahr auch wieder ein Service-Aktion [0]. Meine Test habe ich mit Version 1607 gemacht. Es basiert auf AGESA 1.0.0.2, hat damit den RDRAND-Bug (wahrscheinlich ein Problem mit der Firmware des CCP 5.0) und ein passives Boostverhalten. Es wird sicher noch Updates geben, welche die Probleme lösen.
Warum kein X570? Ganz einfach. Der X570 braucht relativ viel Strom und ist aktiv gekühlt, ich brauche weder PCIe 4 Support, noch die weiteren PCIe-Lanes. Interessant wäre lediglich die verdoppelte Anbindung zwischen dem Chipsatz und der CPU. Aber das ist den doch sehr hohen Aufpreis nicht wert und vor allem mit FreeBSD ist es meiner Erfahrung nach besser auf etwas ältere, etablierte Hardware zu setzen.
Die Radeon RX 580 nähert sich ihrem Lebensende. Die Radeon 5700XT sieht zwar sehr sexy auf, aber ich werde da noch auf Custom-AIBs warten und der Treibersupport sollte auch einige Monate reifen. Zumindest bis Linux 5.3 erschienen ist. Auch zu den SSDs muss man nicht viel sagen. Das Seasonic Netzteil ist ein hocheffizientes, semipassiv gekühltes Modell der mittleren Leistungsklasse. Irgendwie gibt es in den letzten Jahren einen ungesunden Trend zu immer größeren Netzteilen, in der Praxis dürften die 550W für mehr als 95% der Anwender locker ausreichen.
Für das Fractal Design Define Mini C Gehäuse habe ich mich entschieden, da es als MicroATX-Gehäuse relativ kompakt ist (es gibt noch kompaktere Modelle, aber viel weniger Volumen bringt es nicht), Grafikkarten voller Länge aufnehmen kann und einen guten Innenaufbau hat. Es unterteilt sich in eine gedämmte Hauptkammer und eine kleinere Kammer für das Netzteil und diee Laufwerke. Die Haupkammer bietet auf der Vorderseite Platz für zwei 140mm Lüfter, die such über die ganze Höhe erstrecken. Da setze ich die beiden langsam laufenden, unhörbaren Noctuas ein. Hinten ist Platz für einen 120mm Lüfter, dort kommt ein per PWM synchron zum CPU-Kühler geregelter 120mm Noctua zum Einsatz. Unter dem Strich ist das Gehäuse sehr gut durchlüftet und das System im Leerlauf unhörbar, unter Last rauscht es leise. Im Leerlauf erreicht die CPU ca. 33°C, unter Last ca. 55°C. Bei knapp 22°C Raumtemperatur.
FreeBSD
Eigentlich soll ein Linux auf die Kiste, FreeBSD bleibt auf dem Core i7-6700k. Allerdings habe ich es mir natürlich nicht nehmen lassen FreeBSD einmal zu testen. FreeBSD 12.0 bootet problemlos durch und erkennt alle Hardware, ich habe für meine Tests allerdings ein aktuelles 13-CURRENT gebaut. Vor allem, da ich den aktuellen amdgpu Treiber wollte. Dazu gleich mehr, für eine reine FreeBSD-Maschine hätte ich aber eine Nvidia-Karte genommen.
Einzig die Temperatursensoren wurden nicht sofort erkannt. Ich habe die Device-IDs in den amdtemp Treiber gepatcht, damit funktionierte es. Allerdings wird nur ein einziger Sensor erkannt, ich vermute stark, dass es der Sensor des IO-Die ist und nicht ein Sensor im CCD. Das macht ihn recht aussagelos.
FreeBSD erkennt die recht komplexe Topologie korrekt:
Code:
<groups>
<group level="1" cache-level="0">
<cpu count="16" mask="ffff,0,0,0">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15</cpu>
<children>
<group level="2" cache-level="3">
<cpu count="8" mask="ff,0,0,0">0, 1, 2, 3, 4, 5, 6, 7</cpu>
<children>
<group level="3" cache-level="2">
<cpu count="2" mask="3,0,0,0">0, 1</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="c,0,0,0">2, 3</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="30,0,0,0">4, 5</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="c0,0,0,0">6, 7</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
</children>
</group>
<group level="2" cache-level="3">
<cpu count="8" mask="ff00,0,0,0">8, 9, 10, 11, 12, 13, 14, 15</cpu>
<children>
<group level="3" cache-level="2">
<cpu count="2" mask="300,0,0,0">8, 9</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="c00,0,0,0">10, 11</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="3000,0,0,0">12, 13</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
<group level="3" cache-level="2">
<cpu count="2" mask="c000,0,0,0">14, 15</cpu>
<flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
</group>
</children>
</group>
</children>
</group>
</groups>
Auch P-States und C-States werden exakt wie unter Linux erkannt und genutzt. Auch dazu unten noch etwas mehr.
Die Realtek-NIC läuft wie gesagt problemlos:
Code:
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xf000-0xf0ff mem 0xfca04000-0xfca04fff,0xfca00000-0xfca03fff irq 33 at device 0.0 on pci5
re0: Using 1 MSI-X message
re0: Chip rev. 0x54000000
re0: MAC rev. 0x00100000
miibus0: <MII bus> on re0
rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 1 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 04:92:26:d4:62:69
re0: netmap queues/slots: TX 1/256, RX 1/25
Sound, zusammen mit der Radeon. Zur Abwechslung kommuniziert das BIOS nur Ausgänge, die auch vorhanden sind:
Code:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <ATI R6xx (HDMI)> (play)
pcm2: <ATI R6xx (HDMI)> (play)
pcm3: <ATI R6xx (HDMI)> (play)
pcm4: <ATI R6xx (HDMI)> (play)
pcm5: <ATI R6xx (HDMI)> (play)
pcm6: <Realtek (0x0b00) (Rear Analog)> (play/rec) default
pcm7: <Realtek (0x0b00) (Front Analog)> (play/rec)
pcm8: <Realtek (0x0b00) (Internal Digital)> (play)
Die Radeon 580 funktionierte mit aktuellem graphics/drm-devel-kmod problemlos. Trotz UEFI-Boot! Einfach amdgpu.ko geladen, dazu noch x11-drivers/xf86-video-amdgpu installiert, X.org gestartet und es ging. Mit OpenGL, Vulkan und vollem Powermanagement. Allerdings kommt es ab und an zu GPU-Hängern, sie haben sich zwar jedes Mal von alleine gefangen, aber es nervt doch etwas.
Powermanagement
Ich habe mich in den letzten Wochen sehr tiefgehend mit Powermanagement unter FreeBSD beschäftigt, viele Mails geschrieben, Patches getestet, gemessen, theoretisiert... Ich könnte viel dazu schreiben, aber erspare es euch mal.
Nur so viel: Seitdem ca. 2003 P-States (Frequenzskalierung, das was powerd und powerd++ machen) und C-States (Schlafmodi für die Kerne) aufkamen, ist Power Management immer mehr Sache der Software geworden. Bis einschließlich Sandy Bridge (Core i-2000 Serie) konnten die Kernel neben Windows und Linux noch gut mithalten, seitdem fielen sie immer mehr zurück. Das betrifft alle BSDs. Intel wurde sich dem Problem der immer komplexeren Anforderungen an die Software irgendwann bewusst und führte mit Skylake (Core i-6000 Serie) hwpstate, auch als Speedshift bekannt, ein. Damit wird das Powermanagement wieder in die Hardware zurückverlagert. FreeBSD und co. können davon bisher aber nicht profitieren, da weiterhin etwas Softwareunterstützung benötigt wird. Intel entwickelt die unter seinem FreeBSD-Sponsorship gerade und die ersten Patches sind sehr vielversprechend [1].
AMD geht einen anderen Weg. Dort versucht man die Software weitgehend außen vor zu lassen, man gibt ihr lediglich die Möglichkeit eine Abwägung zwischen Stromersparnis und Leistung vorzugeben. Dafür setzt man auf CPPC2, einem offenen, in UEFI enthaltenen Standard. FreeBSD hat auch dafür noch keine Unterstützung, das ist allerdings nicht weiter schlimm, die CPU hat sinnvolle Standardwerte gesetzt. Das ist sicher kein Entgegenkommen an FreeBSD, sondern eher Pragmatismus hinsichtlich Microsofts immer noch vorhandener Intel-Fokussierung.
Wie oben schon geschrieben, werden P-States unterstützt. FreeBSD sieht die gleichen Frequenzen wie Linux, beginnend bei 2000MHz und endend bei 3601MHz. Sie zu nutzen hat aber weder unter Linux, noch unter FreeBSD messbare Auswirkungen. powerd oder powerd++ mitlaufen zu lassen, hat keine Auswirkungen auf den Verbrauch an der Steckdose, auf die von sysutils/turbostat gemessenen Verbrauchswerte und auch nicht auf das reale Taktverhalten. Kurz gesagt, man kann es sich sparen.
Auch C-States werden unterstützt, allerdings werden sowohl unter Linux, als auch FreeBSD nur C1 und C2 kommuniziert. Auch turbostat und powertop (nur für Linux) sehen keine tieferen States. C2 zu erlauben, bringt sowohl unter Linux, als auch FreeBSD etwa 0,3W an der Steckdose. Weitere Auswirkungen hat es nicht.
Unter dem Strich komme ich auf ca. 44W an der Steckdose unter Linux und 48W an der Steckdose unter FreeBSD. Diese 4W Unterschied sind sehr gut, bei meinem Core i7-6700k bin ich (ohne die Patches für hwpstate-Support) nie unter 22W Unterschied gekommen. Vor allem aber bleibt es sowohl in Teillast, als auch unter Volllast bei ca. 4W. Während der Core i7-6700k vor allem im Teillastbetrieb unter FreeBSD auf bis zu 35W gegenüber Linux zurückfiel.
Ich kann es nicht wirklich beweisen, aber ich vermute, dass die CPU an sich unter Linux und FreeBSD sogar ähnlich viel oder wenig Energie benötigt. Der Unterschied scheint mir eher auf das Mainboard zurückzugehen, FreeBSD unterstützt anders als Linux auch kein HDA-Powersave für die Soundkarte und kein Powersave für die Realtek-NIC.
Interessant ist auch die Frequenzskalierung. Der Core i7-6700k kam ohne die Patches für hwpstate-Support nie über Basisfrequenz hinaus. Der Ryzen 3700X hingegen erreicht bei Last auf bis zu 2 Kernen sowohl unter Linux, als auch unter FreeBSD etwa 4320MHz dauerhaft. Die 4400MHz habe ich auf beiden Systemen nie gesehen, obwohl genügend Energie und Wärme-Budget vorhanden wäre. Das wird das AGESA 1.0.0.2 sein. Unter Volllast pendelt er sich unter beiden Systemen auf 3950MHz ein.
Leistung
Dann noch kurz, was das Blech auf die Straße bringt. Das sind keine sauber durchgeführten Messungen! Wie gesagt, es gibt genügend Reviews im Netz. make -j$(sysctl -n hw.ncpu) buildworld mit Sourcen und Objekten auf einem tmpfs. Sourcen waren 13-CURRENT von gestern.
Core i7-6700k: 57:25 Minuten
Ryzen 3700X: 24:53 Minuten
Also etwas mehr als doppelt so schnell.
0: https://www.amd.com/en/support/kb/faq/pa-100#faq-Short-Term-Processor-Loan-Boot-Kit
1: https://github.com/bwidawsk/freebsd/tree/hwp2