Note that AMD' claim that it's only local loopback (127.0.0.1) has been refuted by numerous comments, and without further reply from AMD.
Given AMD's refusal to work with libreboot, or document the on-die Arm cores with DMA memory access, these processors should not be considered secure for any layer 3 networking, financial or security related tasks.
Beyond that, just pick your burner application of choice and let it run for an hour while you go watch a movie. The rest are all kinda interchangeable as far as I'm concerned. Aida64 maybe?
(one note: I would not leave Prime95 running for prolonged periods of time. Modern CPUs are not designed for a program that is so small it fits into uop cache and runs AVX nonstop. With a heavy overclock it can pull 300W+ (potentially above 400W) on HEDT processors and OEMs like Asus have warned that it may cause damage. Electromigration seems like a likely culprit meaning time is a key factor. Running Prime95 for like a half hour is fine and a great stability test, but 24H+ runs are extremely unnecessary and potentially damaging.)
(Note that while this article is regarding Haswell-E, the same logic really applies to Broadwell-E as well as Ryzen 5 and 7. Running a processor at triple its nominal TDP nonstop for a prolonged period with most of that power going though a few specific execution units simply cannot be healthy for it.)
This is a slippery slope towards CPUs which are only warranted to run certain approved apps. Overclocking aside, I'd consider a CPU broken if it can't run any sequence of instructions 24/7 without damage at the stock speed and voltage.
Besides, Prime95 isn't what I'd consider a pathological case anyway --- FFTs are common in scientific computing and signal processing, and having a CPU continuously perform them is not at all an unusual workload.
It somewhat reminds me of https://news.ycombinator.com/item?id=7205759
AVX has been on a separate clock/offset for a while now, and many OC'ing motherboards will let you tweak it.
Given how much power AVX consumes I wouldn't be surprised if throttling it even let you clock the rest of the core higher.
> run prime95 small FFTs albeit at 90C for 24 hours with no issues then your OC should as well
That's nice in theory but in practice if it's gonna crash it's gonna do it quick. I doubt many CPUs are suddenly erroring out for the first time at 23 hours. So why not just test for an hour and call it good? An hour of super abnormally high stress is more than enough to validate it for standard usage in my opinion. More than OK at 30 minutes too. Usually fails within the first 5 seconds, if you make it to 1 min then you have a very solid chance of making it the whole way. 30-60m is plenty.
If your data assurance requirements exceed one "proof test" shot, so to speak, then you have no business using overclocked CPUs at all. Prime95 SmallFFT is way way more stress than you would ever put a CPU under in any real-world load, and like an overpressured proof shot it's not really the best thing in the world for the processor to do this nonstop. Electromigration is a thing that exists.
Wait, SmallFFT? Isn't that the test that focuses heavily on CPU and very little on the memory?
Since this news is about memory timings/overclocking, I'd rather put much more focus on tools like Memtest86+, running that for a few hours to be sure that it touches all the addressable regions and uses various access patterns.
Whatever test you do, you want to exercise all the memory, or else you'll end up with a computer that always seems fine after boot, but accumulates errors and crashes based on uptime and how much concurrent work you throw at it.
Is it because the question is not whether or not a particular bit of RAM is damaged and rather whether or not the overclock to the communications bus between CPU and RAM is affected?
Obviously you want to focus your testing on whatever subsystem you're trying to OC. I was just giving generic advice on overclocking. There is pretty broad consensus that Prime95 is a good stability test for CPUs.
Someone also suggested Intel Burn Test as a test that might catch some instabilities that Prime95 misses in a reply and then deleted it for some reason (why?).
In particular though, it's not just the memory subsystem you're overclocking here, you're really overclocking the interconnect as well. It will have its own "silicon lottery" and a particular point of instability, in addition to your individual memory kit's own stability characteristics. There are a lot of moving parts here.
I do wonder how much of this is getting the memory controller stable versus getting the interconnect stable. It seems possible they may have knobs they can twiddle on the interconnect as well.
[Serious question here:] I wonder if Prime95 or burn-test type tools would stress the interconnect with enough cross-core communication to be worth running.
The combination of instructions it used meant that even if, under sustained 100% CPU load with a normal benchmark, your cooling solution was sufficient, within 30 seconds the CPU would hit 100° and activate it's thermal protection before a shutdown.
I went through 3 water cooling setups and numerous thermal paste reapplications before I realized, since I was driving the CPU hard (4690k at 4.9Ghz with a high overvoltage I recall being considered at the limit for non-LN2 setups, 1.4?) and thought that cooling was the issue
Do they have anything in their contracts telling you not to do that?
You mean 'really sensitive'. 'real' is the adjective form - 'really' is the adverb submodifier form, which is the one you want in this case.
If you clock your memory to its advertised speed and timings (i.e. enable the XMP profile) you ~~won't~~  shouldn't have any problems after booting. What may happen is that your system fails to POST, in which case you need a better motherboard.
Using the correct memory profile is extremely important. Reviewers found that the performance of Ryzen is strongly correlated to the memory clock - something to do with Infinity Fabric. This means that DDR4-4000 is, in theory, absolutely required if you want the most out of Ryzen - making this patch a big deal for Ryzen users.
In Intel systems it was* required to have the uncore clock be twice the memory clock-rate. The "uncore" clock rate controlled the clock for caches, the memory controllers, possibly other IO components, and the like.
It makes sense that certain benchmarks would be insensitive to increases in memory frequency if those same components were locked at ~2.1GHz in Ryzen's initial release.
On a related note: does AMD publish block diagrams for their infinity fabric or is there any firm information about how many PCIe 3 lanes will be available on the Threadripper platform?
* - I'm not sure if it still is, to be honest!
I'm interested in a block diagram or documentation as well, if anyone knows of any.
PcPer did some tests which show the inter-core latency and some other experimental data.
> My understanding (please, someone tell me if I'm off base!) is that the infinity fabric is kind of like Intel's QuickPath Interconnect and the "uncore" in one.
Yeah that sounds about right. The only thing I will add is that I've heard (can't source) inter-die communication on Threadripper/EPYC multi-chip-modules apparently happens by a different mechanism than intra-die/inter-CCX communication.
As such, my suspicion is that Threadripper and EPYC will basically behave like a multi-socket system.
As for lanes: I think it's official at this point that Threadripper has 44 lanes like Skylake-E does, and EPYC has 128 PCIe lanes. Possibly plus additional lanes from the PCH?
I used to overclock, but stopped after realising the errors that occurred with Linpack; it really made me appreciate the fact that a CPU could miscalculate, and a system that appears "stable" can actually be silently corrupting data.
I have not done overclocking for quite a while, but general strategy was:
0. Get the right hardware - some hardware oveclocks better.
1. Depending on what you overclock come up with a short stress test. This would be GPU/CPU/RAM/PSU testing.
2. One component at a time. Identify top voltage/temp you are willing to tolerate. Overlock in steps of 5-10% nominal frequency. When the stress test fails increase the voltage by 5-10% until you reach the voltage limit. Once you get all of the data look at the frequency voltage curve and pick a voltage point (generally lower is better), back off a step or two from the frequency that passed and run an endurance test.
3. Run all components at the same time and stress test the entire system. The caveats here are to look out for power and temperature issues. I.E. make sure nothing get too hot (this includes the motherboard power regulators!) or voltage rails drop out of spec.
4. Slightly back off from the setup that passed 3 and you should be good to go for long term usage.
TL-DR: Overclock one component at a time come up with frequency/max temp/required voltage chart and don't try to run the hardware on the bleeding edge.
edit: list spacing...
So I tried to find the rough limits and wrote down idle/load temperatures for various combinations of settings/frequencies, and then picked my "sweet spot" at which temperatures started to increase a lot more per little increased performance. Granted, I did get a good case and CPU cooler, which I clean religiously, and of course there's always luck involved, but divided by the 8 years it's running this current computer is the cheapest I ever had, apart from having to replace the PSU because that was the one bit I paid less attention to, even the hard drives are still spinning, it's freaky. So the next one will have an even better case and cooling and then not get overclocked much or at all, either, that's for sure.
FWIW I do agree with you though. I overclocked my 5820K to 4.13 GHz all-core, which is as far as it would go on stock voltages. According to the on-chip sensors I pull 90W during a normal (non-AVX) load. I could probably get another 400-500 MHz if I really pushed it, but getting the last 10% isn't worth turning that 90W processor into 200W+ for me.
For scaredy-cats: I think that's a pretty reasonable approach to overclocking. Just go as far as you can at stock voltages. I bet pretty much any processor can overclock all its cores to max turbo speed with either no extra voltage or a very minor voltage increase.
I still have one lying around, it still works and was in daily use (for mail, file and miscellaneous serving tasks) until a few years ago.
Use to be a frequenter of extremesystems.org 10-15 years ago, in the overclocking and water-cooling threads.
Now practicality wise, I had no use to OC really. Wasn't even a big gamer at the time. Pure fully fun and just seeing if I could (thought I was the cool kid running water-cooling, overclocked cpu/mem/you, installing every nightly patch in Gentoo portage with a tonne of system specific gcc and kernel flags lol).
Now my thousands of dollars water-cooling parts, and a q6600 processor have been sitting in garage for 10 years.
Use a standard i7 low-end laptop, no desktops in past 10 years
I started off using the machine for gaming and building C++. Now that machine is is part of Jenkins cluster running several VMs each building C++. This machine is about as stressed as a desktop CPU can be. I do not believe these are built to fail.
I overclocked my i7-4790k from 4.0 to 4.7 GHz just using the "easy" button in my ASUS software and called it a day. It's been humming happily along for 24/7 since the chip came out.
For some people (myself, gamers, hobbyists etc.) that doesn't matter.
* Take 100 identical machines and run them with a specific setting for a year. Take the number of failures and write it down.
* Take another 100 machines and run them with a different settings for a year. Write down the failures.
* Do this for like 10 different speed settings. (You need 1000 machines and have to wait one year of time.)
* Make a graph of the data. Log of failures over linear speed axis.
* Try to see a curve in the graphed data.
* Determine the failure rate that you want to achieve.
* Look up the speed setting in the curve.
* Now you have your speed.
I guess only people like the processor manufacturers actually do it this way. Most other folks just do guesswork.
If you have advanced knowledge about the failure curve you might come up with a law like this:
* Turn up the speed until you hit 1 failure per 24 hours under heavy load.
* Turn down the speed by 30% and sell.
No, seriously — it crashed my CPU (i5-6400) at 4.5GHz when linpack finished just fine at these settings. Lowered to 4.4 and no more crashes.
Do this for Memtest86+ and Prime95/OCCT/Intel Burn.
Contrary to some opinions I've seen, playing a game for a while is not a sufficient test for overclock stability.
"""The last addition should excite those interested in virtualization. AMD has announced "fresh support" for PCI Express Access Control Services (ACS), which enables the ability to manually assign PCIe graphics cards within IOMMU groups. This should be a breath of fresh air to those who have previously tried to dedicate a GPU to a virtual machine on a Ryzen system, since it has thus far been fraught with difficulties."""
People have been fairly successful over the years combining their windows games box into their linux workstation by doing this.
I haven't dipped in but I am pretty tempted.
Can anyone comment on the stability of the linux workstation if the windows vm takes a dump via bad drivers etc? That's my concern is that my linux workstation is highly highly stable and I don't want to borrow problems just to save a box.
It's supposed to speed up virtual memory handling in the guest by avoiding the need for shadow page tables and/or emulation by the host.
Currently the feature is broken, resulting in crippled GPU performance, allegedly due to the IOMMU not keeping up with the DMA transaction rate. You can disable it entirely (kernel command line amd-kvm.npt=0) at the cost of ~5x increased CPU usage and constant stuttering in games, which is what most people choose to do for now.
Well that will help me push this project off for a few months more :)
Is there a good spot to keep up with this, that is very linux focused?
There's nothing to indicate that this will help with the NPT issue, so expect poor performance (CPU or GPU, your choice).
There's also a thread on the vfio-users mailing list and on a few other mailing lists as well as some discussion on /r/vfio.
Edit: looks like you can do it inside the firmware GUI, no OS is required. You can update over the net, or load update files from USB stick.
Wikipedia has a good table for DDR3:
DDR3-2133 has a 266.67 MHz memory clock, and a 1066.67 MHz bus clock (x 4), and a "data rate" of 2133 "mega-transfers per second". And a bunch of other details, it's complicated.
The point is, don't take the "4000" literally. It's complicated. And timings and latency can differ between models of the same "data rate".
Ryzen is getting improvements here because it's designed as a die containing a pair of 4-core complexes (CCX) that are interconnected with a fabric that runs at RAM speed. Faster RAM => better inter-core performance is the primary mechanism here, not actual bandwidth increases or latency improvements. If you need that stuff you'll want Intel HEDT/Xeons or Threadripper/EPYC with more actual memory channels.
[actual answer]: Second hand but: the replies I'm seeing on Reddit are saying that the performance gains on the interconnect are linear up to 2933 and diminishing up to 3466 and you get little additional gain past there. Full thread and a specific reply from someone who claimed to have tested it.
We need faster ECC RAM though: the external RAM speed affects the internal AMD Infinity Fabric, which provides inter core comms.
Sure, you don't have to hard fault. Just like regular memory controllers don't fail on any bit-errors. But it's ideal, when dealing with critical data.
Currently there aren't Ryzen server chips out, just desktop/enthusiast models.
This also isn't a Ryzen-specific behavior. All x86 ECC-capable machines work this way.