ASUS ROG Strix X670E‑E Gaming WiFi

Artikel-Index:

Sonstiges/Erkenntnisse

Bevor wir zum Fazit unse­res heu­ti­gen Reviews kom­men, möch­ten wir auf die­ser Sei­te noch ein paar Klei­nig­kei­ten zusam­men­fas­sen, die nicht uner­wähnt blei­ben sollen.

Aspekt Ergeb­nis
Kon­den­sa­to­ren
Fest­stoff­kon­den­sa­to­ren
Kon­den­sa­to­ren­her­stel­ler
nicht erkenn­bar
exter­ner Takt­ge­ne­ra­tor vorhanden
ja
Boot­ma­na­ger vorhanden
ja (Auf­ruf mit F8)
PCIe-Slots anders nutz­bar (alle drei)
ja (getes­tet mit DeLock-Adap­ter auf M.2)
PCIe-Slots boot­bar (alle drei)
ja (getes­tet mit DeLock-Adap­ter auf M.2)
funk­tio­niert Wake-On-LAN Intel I225‑V
ja (nur aus dem Stand­By heraus)
funk­tio­niert Wake-On-LAN Intel AX210
ja (nur aus dem Stand­By heraus)
zum Test ver­wen­de­te BIOS-Version
0705
(AGESA ComboAM5PI 1.0.0.3 Patch A)
Pro­dukt­sei­te
aktu­el­ler Neupreis

Wake On Lan

Wie auch in unse­ren letz­ten Main­board­tests mit X570/Ryzen 3000 haben wir das Pro­blem, dass die WOL-Kom­man­dos immer nur dann funk­tio­nie­ren, wenn wir unser Sys­tem in den Ener­gie­spar­mo­dus schi­cken. Fah­ren wir Win­dows her­un­ter, so funk­tio­niert WOL nicht. In der Ver­gan­gen­heit haben wir drei X570-Pla­ti­nen getes­tet, bei denen das Pro­blem immer beim ver­bau­ten Intel-Chip auf­ge­tre­ten ist. Der damals übli­che Real­tek RTL8125 als zwei­ter Netz­werk­ad­ap­ter lie­fer­te in allen Lebens­la­gen das gewünsch­te Ergebnis.

Auch das ASUS ROG Strix X670E‑E Gam­ing WiFi reagiert nur auf WOL-Kom­man­dos, wenn der Rech­ner im Ener­gie­spar­mo­dus ist. Her­un­ter­ge­fah­ren tut sich nichts. Das gilt sowohl für den Netz­werk­ad­ap­ter vom Typ Intel I225‑V als auch für den WLAN-Adap­ter vom Typ Intel AX210. Wie­der Adap­ter von Intel – in bei­den Fällen.

Wir wis­sen nicht, ob wir sys­te­ma­tisch einen Feh­ler bege­hen und falls ja, wor­in die­ser liegt. Fakt ist jedoch: In der Ver­gan­gen­heit haben wir mit dem glei­chen Pro­ze­de­re bei Netz­werk­chips ande­rer Her­stel­ler die gewünsch­ten Ergeb­nis­se erzielt. In den letz­ten vier Main­board-Revews jeweils mit den Intel-Adap­tern nicht. Und was uns pas­siert, kann auch ganz schnell ande­ren Nut­zern pas­sie­ren. Daher wol­len wir, auch wenn wir viel­leicht einen sys­te­ma­ti­schen Feh­ler bege­hen, die­sen Sach­ver­halt unter kei­nen Umstän­den unter den Tisch fal­len lassen.

Ner­vig lan­ge Boot­zei­ten auf­grund Memory-Training

Anfang Sep­tem­ber mach­te eine News von Tech­Power­Up die Run­de, wonach der ers­te Boot­vor­gang auf einem AM5-Main­board von ASRock meh­re­re hun­dert Sekun­den dau­ern konn­te. Das in der News abfo­to­gra­fier­te ASRock X670E Steel Legend trug einen ent­spre­chen­den Auf­kle­ber auf den Spei­chers­lots. In einem Update der News hieß es, dass es ein ASRock-The­ma sei und es angeb­lich gefixt wurde.

Aber seit dem Launch ist von die­sem The­ma immer mal wie­der etwas zu lesen oder zu sehen. Und auch wir haben die­ses “Pro­blem”, was schein­bar in Abhän­gig­keit der Spei­cher­men­ge immer grö­ßer wird. Und da wir 4x 32 GiB ver­wen­den, also aktu­ell das Maxi­mum für AM5-Boards, dau­ert der Post hin und wie­der arg lan­ge. Wobei hin und wie­der etwas unter­trie­ben ist. Denn es betrifft bei wei­tem nicht nur den ers­ten Post des Sys­tems, son­dern deut­lich mehr Situationen.

  • beim First Boot nach Hardwaretausch
  • beim First Boot nach einem BIOS-Flash
  • beim First Boot nach Load Opti­mi­zed Defaults
  • beim First Boot nach dem Laden von Speicher-Profilen
  • beim First Boot nach der Ver­än­de­rung von Speichertimings

Die ers­ten drei Anstri­che sind dabei die, bei denen die Boot-Zeit am längs­ten aus­fällt. Bis zu fünf Minu­ten dür­fen ein­ge­plant wer­den, mal geht es auch in drei Minu­ten. Bei der Ver­än­de­rung von Spei­cher­ti­mings sind die Zei­ten nicht ganz so extrem, eine Minu­te kann man aber auch dort warten.

Wer also auf AM5 sei­nen Arbeits­spei­cher aus­rei­zen will, der soll­te sich ein dickes Fell zule­gen. Denn schon nach zwei, drei Ver­än­de­run­gen ner­ven die War­te­zei­ten ein­fach der­ma­ßen, dass man den Spaß am Twea­king verliert.

Nun könn­te man an die­ser Stel­le ASUS die Schuld in die Schu­he schie­ben. Aber war­um soll­te ASUS den glei­chen Feh­ler machen wie ASRock? Wir ver­mu­ten hier eher ein Pro­blem im AGE­SA-Code, den AMD zur Ver­fü­gung stellt. Nur so ist erklär­bar, wie­so ver­schie­de­ne MB-Her­stel­ler das glei­che Pro­blem haben kön­nen. Und wenn wir mit die­ser Ver­mu­tung recht haben, so soll­te AMD schnellst­mög­lich mit wei­te­ren AGE­SA-Updates für eine Ver­bes­se­rung sor­gen. Denn ansons­ten ist Memo­ry-Twea­king auf AM5 kei­ne Freude.