[juyoung518]

I’ve got two systems - a dual 7742 node, and a single threadripper 5965wx system.

Both have 256gb of 3200mhz ram and runs on windows 10 pro for workstation.

My main use for ansys is explicit dynamics;

However, today I see that the dual 7742 system is x4 slower than the threadripper in exactly the same settings, with only the core number different (64 for the 7742 system, 20 for threadripper).

Moreover, I see that the simulation speed for the 7742 system is inversely proportional to the core count. 64 cores show 2000h remaining, while when using only 16 cores show 700h (Threadripper shows 400h).

I have no idea what the problem is.

Could anyone guide me through this?

[wkernkamp]

You have observed water flowing uphill. This cannot be, but without further info and some benchmark test results it is not possible to help.

[juyoung518]

Originally Posted by wkernkamp

You have observed water flowing uphill. This cannot be, but without further info and some benchmark test results it is not possible to help.

Passmark shows slightly low but normal values - CPU mark = 91858, Single thread = 2100, Floating point = 379838.

Cinebench R23 also shows normal values, greatly exceeding the threadripper.

Exact setup is : Dual 7742 / Supermicro H12DSI / 3200mhz samsung 256g

If I use 127 cores (SMT Off), same simulation shows ~4000h remaining.
For 60 cores, 1400-2000h, and for 16 cores, 700-900h.

I have no idea what might be the problem..

[flotus1]

However, today I see that the dual 7742 system is x4 slower than the threadripper in exactly the same settings, with only the core number different (64 for the 7742 system, 20 for threadripper).

Moreover, I see that the simulation speed for the 7742 system is inversely proportional to the core count. 64 cores show 2000h remaining, while when using only 16 cores show 700h (Threadripper shows 400h).

You should probably test the scaling behavior on the TR system as well.
I.e. see what time it reports for e.g. 4,8,20,24 threads. Maybe we see the same trend here, and this is not a hardware issue.

Aside from that: Memory population matters A LOT on dual-socket Epyc systems.
"3200mhz samsung 256g" still leaves a lot of room for interpretation. On an H12DIs motherboard, these should be populated as 16x16GB. Can you confirm that?

[juyoung518]

Originally Posted by flotus1

You should probably test the scaling behavior on the TR system as well.
I.e. see what time it reports for e.g. 4,8,20,24 threads. Maybe we see the same trend here, and this is not a hardware issue.

Aside from that: Memory population matters A LOT on dual-socket Epyc systems.
"3200mhz samsung 256g" still leaves a lot of room for interpretation. On an H12DIs motherboard, these should be populated as 16x16GB. Can you confirm that?

Thank you. I will try to test the behavior.

And yes, the RAM is populated in a 16gb x 16 slot configuration. i ran some more benches and the hardware at least seems fine…

[flotus1]

Quick question: how many nodes does your mesh contain?

[juyoung518]

Originally Posted by flotus1

Quick question: how many nodes does your mesh contain?

The total nodes are about 600k for this model.

[flotus1]

All right, just wanted to make sure this is not a memory capacity problem. Which it isn't.

[GC94]

Core count can be like this
2000 hours
-------
64 cores
In the end makes 31.25 hours.

[wkernkamp]

Originally Posted by GC94

Core count can be like this
2000 hours
-------
64 cores
In the end makes 31.25 hours.

64 x 31.25 =~ 2000


So the estimation is based on the number of rows solved by one processor compared to the total number of rows that need to be solved for the requested number of iterations. In future, you can simply divide the time estimate by the number of processors engaged to get the true time estimate.


The Threadripper does appear to be faster (if you use my estimator). This may be due to the fact that at 16 cores, eight memory channels are not a limitation, so the higher clock of the threadripper then makes a difference. In addition, the problem sizes is smallish so the cache is more effective, further reducing bandwidth issues. It would be nice to learn actual times for the cases that you provided an ANSYS estimate for.