ASUS ROG Strix X670E‑E Gaming WiFi
Sonstiges/Erkenntnisse
Bevor wir zum Fazit unseres heutigen Reviews kommen, möchten wir auf dieser Seite noch ein paar Kleinigkeiten zusammenfassen, die nicht unerwähnt bleiben sollen.
Aspekt | Ergebnis |
---|---|
Kondensatoren
|
Feststoffkondensatoren
|
Kondensatorenhersteller
|
nicht erkennbar
|
externer Taktgenerator vorhanden
|
ja
|
Bootmanager vorhanden
|
ja (Aufruf mit F8)
|
PCIe-Slots anders nutzbar (alle drei)
|
ja (getestet mit DeLock-Adapter auf M.2)
|
PCIe-Slots bootbar (alle drei)
|
ja (getestet mit DeLock-Adapter auf M.2)
|
funktioniert Wake-On-LAN Intel I225‑V
|
ja (nur aus dem StandBy heraus)
|
funktioniert Wake-On-LAN Intel AX210
|
ja (nur aus dem StandBy heraus)
|
zum Test verwendete BIOS-Version
|
0705
(AGESA ComboAM5PI 1.0.0.3 Patch A) |
Produktseite
|
|
aktueller Neupreis
|
Wake On Lan
Wie auch in unseren letzten Mainboardtests mit X570/Ryzen 3000 haben wir das Problem, dass die WOL-Kommandos immer nur dann funktionieren, wenn wir unser System in den Energiesparmodus schicken. Fahren wir Windows herunter, so funktioniert WOL nicht. In der Vergangenheit haben wir drei X570-Platinen getestet, bei denen das Problem immer beim verbauten Intel-Chip aufgetreten ist. Der damals übliche Realtek RTL8125 als zweiter Netzwerkadapter lieferte in allen Lebenslagen das gewünschte Ergebnis.
Auch das ASUS ROG Strix X670E‑E Gaming WiFi reagiert nur auf WOL-Kommandos, wenn der Rechner im Energiesparmodus ist. Heruntergefahren tut sich nichts. Das gilt sowohl für den Netzwerkadapter vom Typ Intel I225‑V als auch für den WLAN-Adapter vom Typ Intel AX210. Wieder Adapter von Intel – in beiden Fällen.
Wir wissen nicht, ob wir systematisch einen Fehler begehen und falls ja, worin dieser liegt. Fakt ist jedoch: In der Vergangenheit haben wir mit dem gleichen Prozedere bei Netzwerkchips anderer Hersteller die gewünschten Ergebnisse erzielt. In den letzten vier Mainboard-Revews jeweils mit den Intel-Adaptern nicht. Und was uns passiert, kann auch ganz schnell anderen Nutzern passieren. Daher wollen wir, auch wenn wir vielleicht einen systematischen Fehler begehen, diesen Sachverhalt unter keinen Umständen unter den Tisch fallen lassen.
Nervig lange Bootzeiten aufgrund Memory-Training
Anfang September machte eine News von TechPowerUp die Runde, wonach der erste Bootvorgang auf einem AM5-Mainboard von ASRock mehrere hundert Sekunden dauern konnte. Das in der News abfotografierte ASRock X670E Steel Legend trug einen entsprechenden Aufkleber auf den Speicherslots. In einem Update der News hieß es, dass es ein ASRock-Thema sei und es angeblich gefixt wurde.
Aber seit dem Launch ist von diesem Thema immer mal wieder etwas zu lesen oder zu sehen. Und auch wir haben dieses “Problem”, was scheinbar in Abhängigkeit der Speichermenge immer größer wird. Und da wir 4x 32 GiB verwenden, also aktuell das Maximum für AM5-Boards, dauert der Post hin und wieder arg lange. Wobei hin und wieder etwas untertrieben ist. Denn es betrifft bei weitem nicht nur den ersten Post des Systems, sondern deutlich mehr Situationen.
- beim First Boot nach Hardwaretausch
- beim First Boot nach einem BIOS-Flash
- beim First Boot nach Load Optimized Defaults
- beim First Boot nach dem Laden von Speicher-Profilen
- beim First Boot nach der Veränderung von Speichertimings
Die ersten drei Anstriche sind dabei die, bei denen die Boot-Zeit am längsten ausfällt. Bis zu fünf Minuten dürfen eingeplant werden, mal geht es auch in drei Minuten. Bei der Veränderung von Speichertimings sind die Zeiten nicht ganz so extrem, eine Minute kann man aber auch dort warten.
Wer also auf AM5 seinen Arbeitsspeicher ausreizen will, der sollte sich ein dickes Fell zulegen. Denn schon nach zwei, drei Veränderungen nerven die Wartezeiten einfach dermaßen, dass man den Spaß am Tweaking verliert.
Nun könnte man an dieser Stelle ASUS die Schuld in die Schuhe schieben. Aber warum sollte ASUS den gleichen Fehler machen wie ASRock? Wir vermuten hier eher ein Problem im AGESA-Code, den AMD zur Verfügung stellt. Nur so ist erklärbar, wieso verschiedene MB-Hersteller das gleiche Problem haben können. Und wenn wir mit dieser Vermutung recht haben, so sollte AMD schnellstmöglich mit weiteren AGESA-Updates für eine Verbesserung sorgen. Denn ansonsten ist Memory-Tweaking auf AM5 keine Freude.