That is a false alarm for Epyc CPUs at least, not sure about Ryzen:
A reddit user with a dual Epyc 7551 confirmed that in the same thread.
I believe that does not quite address whether or not Epyc is affected, given that the poster on RWT only has access to a consumer Ryzen SKU - please correct me if I am wrong.
EPYC purportedly uses a B2 stepping, which might have a fix or general improvement in manufacturing that handled whatever is off about Ryzen under heavy utilization.
I thought the last time it was discussed for Threadripper that it was using B1, which isn't different from Ryzen in general unless there's a minor revision number difference between affected B1 chips. However, didn't AMD state that the highest binning chips went into Threadripper? If there's something variable like timings or physical characterization in early chips, perhaps they flake out on chips that don't meet the highest bins or don't get the same level of power-delivery or overall platform quality that an X399 board would.
Perhaps another reason might be that the multi-die setup of Threadripper and EPYC might be injecting a bit of latency somewhere that is slowing down some borderline portion of the memory pipeline due to extra synchronization or longer stalls.
I thought the last time it was discussed for Threadripper that it was using B1, which isn't different from Ryzen in general unless there's a minor revision number difference between affected B1 chips. However, didn't AMD state that the highest binning chips went into Threadripper? If there's something variable like timings or physical characterization in early chips, perhaps they flake out on chips that don't meet the highest bins or don't get the same level of power-delivery or overall platform quality that an X399 board would.
Perhaps another reason might be that the multi-die setup of Threadripper and EPYC might be injecting a bit of latency somewhere that is slowing down some borderline portion of the memory pipeline due to extra synchronization or longer stalls.
That would go to the question of whether there is a smaller increment to the steppings besides just B1 and B2.
If the circuit revision is consistent between affected and unaffected chips, then it's not immediately clear that AMD has fixed something.
If there were more sample data, it might be possible to see if there was a range of affected weeks, or if specific SKUs were more likely to be affected. The binning process might have been tightened after some point, which may explain why the less-forgiving high-end or high-reliability products don't see this within their factory clock ranges.
There's no clear indication that this can be fixed by an update, which may mean something like the microcode can't work around a timing path hit by bad binning, or something else that it cannot readily change due to characterization data written or fused by an older evaluation suite. Even if the bad data is in microcode, without the necessary testing environment there may not be a way to set the correct values in the wild.
Anarchist4000
Veteran
That was my thinking as well as it seems to be an obscure timing issue with some event happening too quickly. Might actually be memory timings in conjunction with Infinity, as TR/Epyc have relatively low memory clocks and not widely tested yet.
Doesn't occur on Windows, only Linux and only with some models according to the Phoronix article, so they might be able to fix it through software. Delaying the scheduler a couple cycles or whatever is required shouldn't be overly harmful to performance. Strange they haven't addressed it, but it could be in a future kernel update that hasn't been tested.
At least some of the descriptions of reported issue indicate this may not be limited to memory speeds above what EPYC officially supports.
Without knowing the cause, we may not be able to rule out a difference in the way the platforms handle specific kernel functions or how and where they allocate resources. Hitting a TLB corner case or hitting kernel and user space addresses in a certain sequence can be unique to the OS architectures. However, it would be disruptive to change a kernel function or remap buffers for a few steppings.
I am not sure which scheduler you are referencing in this case. OS thread scheduling in a high load case is probably not trying to intercede that frequently, and the internal scheduling of the SOC, CPU, or non-OS software routines may not be up to the kernel to modify.
hoom
Veteran
Ryzen PRO http://www.anandtech.com/show/11591...anced-security-longer-warranty-better-quality
Originally posted in the Review thread but relevant to Architecture I think.
***waiting on Intel to make a slide about how the security features are glued-on to a desktop CPU***
Originally posted in the Review thread but relevant to Architecture I think.
***waiting on Intel to make a slide about how the security features are glued-on to a desktop CPU***
The latest steam beta for Ashes improved things a lot, now I'm more GPU limited!
An impressive boost in CPU performance in the GPU bound test
CPU bound perf improved a bit as well: https://abload.de/img/ashesofthesingularityo6ai5.png
An impressive boost in CPU performance in the GPU bound test
CPU bound perf improved a bit as well: https://abload.de/img/ashesofthesingularityo6ai5.png
Kyyla
Veteran
Got the NH-U12s with the AM4 kit, looks quite nice
Now I can get stable 4 GHz with 1.38 vcore, max temp doesn't exceed 70C during stress testing and it is dead silent!
Noctua makes nice coolers. My previous one lasted me about 10 years.
Yes, but for the love of everything holy, they do not have any taste on colors they use.
Similar threads
