My impressions of the 2990WX after building and using it.

[Markfw]

In my experience Linux seems to do a better job with high core count builds, and much better when using numa-like CPUs such as Threadripper.

Mark, I’m very curious how your Linux experience has been so far. Have you tried any virtualization workloads? I’m keen to jump back over to AMD should the IOMMU weirdness be mostly solved.
I am tempted to just go all out and do an EPYC build since my Cosmos II can handle XL-ATX/SSI EEB/SSI CEB motherboards but I’m being quite cautious this time around.

Linux is what it runs, I had to reboot into Win 10 to setup OWL. I have not tried any virtualization anything, just doing F@H and Rosetta.

 

[DrMrLordX]

Well, first, I am only up to 3066 on the memory speed. Also, I would not know how to do that test you mention. Sorry, I would if I could.

Not a problem! I've (mostly) got you covered.

Ryzen Ping Test:

https://www.tomshardware.com/reviews/amd-ryzen-threadripper-1950x-game-performance,5207-2.html

Shouldn't be too hard to run.

As far as your RAM speed goes, just pull half your DIMMs (go to 4x8GB) and you should be able to achieve much higher RAM clocks. Though it may take another UEFI revision on that board to hit speeds comparable to what would probably be achievable on something like your x399 Taichi or the top-of-the-line ASUS board.

 

[Markfw]

Not a problem! I've (mostly) got you covered.

Ryzen Ping Test:

https://www.tomshardware.com/reviews/amd-ryzen-threadripper-1950x-game-performance,5207-2.html

Shouldn't be too hard to run.

As far as your RAM speed goes, just pull half your DIMMs (go to 4x8GB) and you should be able to achieve much higher RAM clocks. Though it may take another UEFI revision on that board to hit speeds comparable to what would probably be achievable on something like your x399 Taichi or the top-of-the-line ASUS board.

Well, I am downloading sissoft sandra lite, is that what you want me to run ?

 

[DrMrLordX]

Well, I am downloading sissoft sandra lite, is that what you want me to run ?

Yes. That will do nicely. The "Lite" version of the software won't go into the fine-grain result reporting that you see in the Tom's review, but that's not overly-important. You'll get an average instead. Just make sure to run the MT version of the benchmark (which is the default). My recommendation is to run the "best case" and "worst case" tests and see what are the results. On my 1800x, my average latencies were actually better in the "worst case" scenarios - it was the core-to-core bandwidth that suffered in that test.

For reference, my 4.0 GHz 1800x produced the following approximate results:

DDR4-2133: 88.8 ms
DDR4-3200: 75.6 ms
DDR4-3466: 73.3 ms

I almost got results from DDR4-3600, but it was not stable enough to complete the run. Alas.

 

[Vattila]

OK< I downloaded OWL and installed it, and Visual Studio. I started reading the instructions, and frankly, its a little beyond me. Any way to simplify what I need to do to benchmark ?

In the installation guide, you can ignore the stuff about version control and build setup. Simply go to branches/644 (OWLNext 6.44, latest release) and download a snapshot of the source code by pressing "Download Snapshot" in the page title bar. Extract the contents of the ZIP-file into "C:\OWLNext" on your drive. Then run the build tool OWLMaker (download) and follow the instructions in the OWLMaker User Guide.

Thanks for your efforts.

 

[StefanR5R]

I like hearing about it because I can use that many cores for DCing.

How does it compare to all your other DC rigs?

Rosetta@home PPD:
https://forums.anandtech.com/threads/ppd-for-my-new-2990wx.2552774/
It scales very well there, considering that Rosetta@home is somewhat on the RAM intensive side, as Distributed Computing applications go.

Twice as fast as 2 1950X's for example?

At stock, the power budgets are 250 W / 180 W = 1.39. Scaling should be near this factor in workloads with little synchronization and moderate RAM bandwidth or latency dependency.

Edit: My reasoning here is that 1950X's and 2990WX's stock clock ranges are not too far off of each other, so that non-linearity of the voltage-frequency curve isn't a big factor here.

Most distributed computing applications are single-threaded, i.e. don't have any synchronization across logical CPUs going on. Some DC applications are multithreaded but scale well only to modest thread counts per process, e.g. 4, hence should run well on 2990WX's topology too on an OS with useful scheduler. Furthermore, most DC applications are not particularly sensitive to RAM speed or timings.

That said, I admit that I was skeptical about 2990WX's scaling, specifically at Rosetta@home, until I saw Mark's results at Rosetta which are IMO very good (to me, surprisingly good).

 

[fibonacc]

Compiling with latest Chrome sources on Windows 10 shows core scaling to be as expected, similar to the tests done on Linux:
https://www.reddit.com/r/Amd/comments/99ckjv/threadripper_2990wx_compilation_performance_with/

 

[mattiasnyc]

So, I have had it up and running and stable, at 4 ghz for a while, but 3.7 all day every day. But nobody wants any custom benchmarks, that the web sites have not done, and its like crickets talking about it. Does no one have any interest in the new monster ?

I do have an interest actually. I'm not sure if you'd be willing since it's a bit tedious to execute the benchmark.

It's essentially two similar benchmarks for digital audio workstations. All downloadable freeware with instructions on how to execute. The one drawback might be if you would be running built-in audio (i.e. whatever is on your motherboard).

Let me know if this is something you'd be interested in doing. If not I understand.

 

[Markfw]

I do have an interest actually. I'm not sure if you'd be willing since it's a bit tedious to execute the benchmark.

It's essentially two similar benchmarks for digital audio workstations. All downloadable freeware with instructions on how to execute. The one drawback might be if you would be running built-in audio (i.e. whatever is on your motherboard).

Let me know if this is something you'd be interested in doing. If not I understand.

Yup, built in audio. So what does that mean ?

 

[DrMrLordX]

Yup, built in audio. So what does that mean ?

Hey, did you ever get a chance to see if your 2990WX could run RAM faster than DDR4-3066 using only four DIMMs? So that you could run Sandra's core latency tests at different RAM speeds above DDR4-3200?

 

[Markfw]

Hey, did you ever get a chance to see if your 2990WX could run RAM faster than DDR4-3066 using only four DIMMs? So that you could run Sandra's core latency tests at different RAM speeds above DDR4-3200?

Well, I need the ram, and the box is a working box that can't be down for too long, so no, sorry.

 

[mattiasnyc]

Yup, built in audio. So what does that mean ?

The test is carried out by installing an audio workstation software and then a plugin or two, and then loading up a template. By turning the template plugins on one by one the load increases on the system (CPU). Sooner or later audio will begin to be interrupted by 'clicks' or even 'crackling', and at that point the CPU has failed. The resulting amount of plugins turned on with a clean audio stream is the benchmark test result.

The two parameters are 1) the audio buffer size, where lower increases the load on the CPU's realtime performance, and 2) the audio playback device (interface, or codec or whatever it's called in consumer circles) where a more consumer oriented device typically has worse drivers that make realtime performance worse.

So it's a bit time consuming because you'd have to turn those plugins on manually, and I'd have to check what the implications are of having built-in audio since that's not what we use professionally.

If you're still interested I can get you links for instructions and downloads etc.

 

[StefanR5R]

@mattiasnyc, there is more needed to prepare for such a test: All of the kernel-mode drivers that are present on the system must be vetted for never creating any latency spikes.

 

[DrMrLordX]

Well, I need the ram, and the box is a working box that can't be down for too long, so no, sorry.

Bummer. Wasn't there someone else in here with a 2990WX? Maybe they can give it a shot.

 

[mattiasnyc]

@mattiasnyc, there is more needed to prepare for such a test: All of the kernel-mode drivers that are present on the system must be vetted for never creating any latency spikes.

That's not how that test is performed. At least I've never seen that in the 15 or so years it's been used.

 

[StefanR5R]

Are we talking about below or above 10 ms audio buffers?

And why can't the processing time of the plugins be measured directly, instead of waiting for buffer under-/overruns?

 

[mattiasnyc]

Are we talking about below or above 10 ms audio buffers?

I haven't had enough coffee yet to calculate that. Typical buffer parameters are;

64, 128, 256 and 512 samples 'per buffer', at 44.1kHz or 48kHz. Some also test at double that sample rate.

And why can't the processing time of the plugins be measured directly, instead of waiting for buffer under-/overruns?

I don't know the answer to that.

One potential issue (I'm guessing here) is that the load is spread both 'wide' and 'deep' so to speak. So in an audio application you can see a big difference between X plugins processing in parallel versus in series. In this test a channel containing an audio signal has (typically) 8 plugins instantiated 'in series'. The signal will go from input of the channel, through the plugins one at a time, and then exist the channel. In the test the plugins are activated top to bottom, channel by channel.

So, even if you could calculate the required processing time of the plugin itself, which I suppose the manufacturer could do without too much problem, that won't tell us what happens when the CPU needs to store the result of process X and then recall it for process Y... for several hundred instances of plugins. Some CPUs do that fine while others fail earlier.

 

[mattiasnyc]

Something I found interesting regarding this CPU and audio;

In this case there were actually unusual results reported. Normally when a limit is reached, i.e. we hear 'clicks', the solution is to turn plugins off again. Often it means turning off a few more than right before the audio broke up. So if the template played back with 300 active plugins and started crackling at 301, then one might have to turn off more than 1 to get back to normal playback, say a new 'high' would be 290.

The two curious things are that with my Ryzen 1700 at least a restart of the software solves the problem and the hypothetical limit of 300 can be reached again (as opposed to 290). The same was apparently true with the 2990wx but with a bigger difference. The second and more curious issue was that the software apparently failed to respond when reaching the limit. This means that a potential user might work on a project and turn on a plugin and in practice lose all work between that point and the last save of the project, which is a very bad thing.

So, from a technical standpoint I find that curious, because it seems the CPU then gets 'stuck' for some very bizarre reason.

My wish for getting it tested is just to get a 'second opinion' on this behavior on a different system, since the CPU are so expensive we're not going to see people take a chance on it with this reported behavior.​

 

[slashy16]

Can you try benchmarking CPU miner on Monero?

The sweet spot for my 2700x is 7 threads at 550h. I usually run 4 threads 350h while gaming.

https://steemit.com/monero/@joshmocek/how-to-mine-monero-on-your-cpu-for-windows

 

[Markfw]

Can you try benchmarking CPU miner on Monero?

The sweet spot for my 2700x is 7 threads at 550h. I usually run 4 threads 350h while gaming.

https://steemit.com/monero/@joshmocek/how-to-mine-monero-on-your-cpu-for-windows

Sorry, the one thing I refuse to do is mining. I do plan on trying those latency tests today. And is that 550 hours ?

 

[StefanR5R]

@mattiasnyc, thanks for the additional info.

Re: unrecoverable situations observed with Ryzen and Threadripper: It's certainly not the CPU that gets stuck; rather the software stack doesn't recover properly from the under-/overrun. As you indicated, there is a big matrix of parameters (audio device driver, buffer size : sample rate, channel count, plugin count), whose combinations just cannot be entirely tested by the developers of the software stack's x-run recovery routines.

I asked for buffer sizes earlier because it makes a difference if live manipulation of an audio stream is the goal (with humanly imperceptible delay between live recorded input and live played back output - which needs very small buffers, such that system latencies can become an issue, e.g. from badly behaving drivers, regardless of CPU power) --- or if merely manipulation of a prerecorded stream is the goal (such that moderately large audio buffers can be set).

All in all, I believe that this sort of testing requires a basic experience with the setup of an audio workstation, otherwise you are bound to get confusing results. At the very least, the rather large parameter space needs to be narrowed down. Edit: And the software better detects and reports x-runs itself, because having to rely on the user to perceive x-runs as clicks or pops is not really objective testing.

 

[Markfw]

Sisoft Sandra Lite appears to be hung every time I run it, while all other software running is fine. It hangs during the benchmarks. It loads fine.

 

[Markfw]

Well, I got cinebench 15 to run 6107

 

[Markfw]

OK, I got aida64 latency to run. Next I will take out the memory and try again

 

[DrMrLordX]

Sisoft Sandra Lite appears to be hung every time I run it, while all other software running is fine. It hangs during the benchmarks. It loads fine.

Weird. I had that problem when running DDR4-3600 on my 1800x. Have you done any memory testing for stability?

Btw your latency for DDR4-3066 is pretty nice!