Return to Level1Techs.com

ASRock Rack X470D4U2-2T

This seems to be a prime candidate for a homeserver. Would be really great if this were reviewed by … somebody cough @wendell

ASRock Rack X470D4U2-2T
https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Specifications

There are some experiences of that model in the second half of the X470D4U thread:

@wendell said that their ASRock Rack stuff seems to have gotten lost during shipping (eBay China or something).

2 Likes

Thx for the info! Maybe ASRock should ship another round of Rack Boards to @wendell

I think they wouldn’t do that since @wendell would be rightfully sh***ing on them for the current BIOS/IPMI software quality. Just browse a little through the X470D4U thread and you’ll get an impression.

I’m personally quite angry with them since we the users here found severe power management issues with certain PSU models among some other stuff and ASRock Rack has been absolutely radio-siilent about fixing these things since late July.

My strongest current annoyance is that their latest BIOS 3.20 doesn’t even have AGESA 1003 ABB so RDRAND is broken when using a Zen 2 CPU which then leads to stuff like Fedore 30 or the latest VMware ESXI 6.7 U3 not booting. :frowning:

1 Like

I’m just skimming through the thread. Very unfortunate that ASRock isn’t more helpful. Especially with these pricey server boards.

Hope they fix it. You could give the board back entirely if they were not able to resolve the issues.

And then, what AM4 board with KVM-IPMI would I get? :wink:

1 Like

I was kinda excited about am4 home server… but the 8 core epyc rome is so cheap and power sippy and the ipmi is so good… its worth the price of admission. lol.

Plus grub & serial console into the router goes a long, long way for ipmi-like functions till you have h/w failure which is going to require physical intervention anyway.

Am I being nitpicky for wanting a functioning firmware that doesn’t throttle down the CPU to 550 MHz at 35°C for thermal protection with certain PSUs (Seasonic), being able to read DIMM SPD settings from within an operating system and critical AGESA fixes maybe within a month after the other manufacturers (I consider ABB critical due to the RDRAND fix, ABBA is more of a cosmetic one for that kind of motherboard)?

Currently I enjoy higher frequencies more than more cores in the range of 8-16 cores - the 22 PCIe 3.0 lanes the X470D4U offers (not exactly sure where the last 2 are coming from but I checked every PCIe/M.2 slot for its functionality) for my own devices are also enough for me.

I’m at the point where I have to cut pieces out of my trusty mATX home server tower to be able to really use every PCIe lane there is with an additional PCIe riser abomination :smiley:

I like over-powered understatement, too, but craming an Epyc into an mATX tower would even be too over-the-top for my taste :wink:

Also stumbled across this board.

So far 2 Atom CPUs have died on me and I’m not in the mood for yet another RMA that I’m not even sure I’ll get even though it’s a manufacturing defect…

So, with that being said. How “critical” are the mentioned IPMI issues for a home-NAS-type-situation? I may or may not consider pulling the 2700X from my main PC and putting it in there, get a new shiny Ryzen 3000 for the main PC instead.

Also, how well is the ECC support working? I.e. does it actually report errors in a log? In a manner that ZFS (or any other FS?) can deal with it?

Well, the board reports Multi-bit ECC capability to an OS. If you make a normie-proof guide on how to test the way the firmware is presenting corrected errors to the OS I can check this - as long as the OS doesn’t require RDRAND to function :wink:

I only have the X470D4U (not X470D4U2-2T) but the platform/BIOS is basically the same.

Not actually sure how to test this. Never really got into.
Reason I’m asking is just because it would be a bummer if ZFS couldn’t actually work with the errors.

Why would that affect ZFS? I know that data integrity in RAM is very important (not only when using ZFS) but wouldn’t the OS handle the ECC functionality and if there were more errors than multi-bit ECC could handle the system would likely completely crash anyway?

Or is that only my normie-centric way of thinking?

Well the thing is… suppose there occurs an error in RAM, and it may or may not be corrected (especially with multi-bit errors not every of them can be corrected), it should be reported to the OS and consequently ZFS to be able to handle that non-correction.
As for corrected errors it would just be good to be logged since repeated error could hint at something wrong with the hardware or the drives.

Problem with a lot of “ECC-supporting” consumer boards is that they “support” ECC in a way that they accept ECC sticks and that’s about it. I.e. no reporting or anything useful.
I know this is a server-oriented board so I’m kind of expecting this works, just wanting to confirm it.

@nx2l has one of these im pretty sure.

1 Like

I’m currently reading up on the other thread, but 450 posts man :sweat:

I have the non 10G version MB
but I did recently get a aquantia 10G nic

The 10Gb MB version wasnt available when I ordered my x470d4u

ZFS doesn’t care or do anything about hardware errors reported to the system/os as far as I know.

It checks the correctness of the data (all blocks are checksummed) every time it reads it from disk, which deals with far more than just ram errors, which is what you need if a cable, disk, or disk controller goes bad.

I’m curious and unfamiliar about that. How do you have that set up?

https://help.ubuntu.com/community/SerialConsoleHowto

Mh interesting… I always kinda assumed it did because what would be the point otherwise :thinking: Because as far as I know an uncorrectable error isn’t necessarily a reason for the kernel to halt, right? So might still end up with broken data? Doesn’t really make sense to me :thinking:

@wendell probably knows? :stuck_out_tongue: