-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Memory Bandwdth is Overreported by ~3x on AMD Zen 2 Desktop #527
Comments
Memory traffic measurements on AMD Zen* systems are not reliable. AMD documented that the metric is "approximate" and the system has to be in NPS1 mode. Based on your hwloc topology, your system is in NPS1 mode. Desktop chips are commonly not tested on our side because we don't have those, only server class chips. You get the metric formula by running: But there is definitely something wrong. The kernel reports |
Running update_avx on all cores (6 threads), kernel reports 128 GiB of DRAM traffic, meanwhile likwid-perfctr reports 690 GiB. Strangely, the "average" traffic of 115 GiB seems to be close to the actual traffic.
|
I just tested In your case, I would remove the scaling factor and check results again.
|
I deleted the scaling factor
Another one:
|
As I said, they are not that accurate. I still have no idea why the data volume does not fit. For |
Not single rank, just single channel. Only a single DIMM module is plugged in, so the other integrated memory controller is disabled, as LIKWID correctly reports here. And since memory traffic is calculated by summing both counters on each memory controller, I don't expect two-channel configuration to be more or less accurate than one-channel, but who knows...
Understandable. I didn't expect to get tech support from a community project when even AMD doesn't officially provide any, I just wanted to learn more about this situation from experienced maintainers. |
Well, then it's just lucky that the event name fits. They are not documented, so I made the names up. On my Zen2 test system (2x AMD EPYC 7352), the
but also there, the counts are not really accurate and somewhat similar to your system (
You could try to use the other DIMM slot, maybe that helps. |
I physically moved the DIMM from slot 2 to slot 4, and indeed, now the counter shifted from
|
This issue seems resolved even if the DataFabric unit counts are off. If so, please close the issue. |
Describe the bug
A clear and concise description of what the bug is.
I tried to use likwid-bench to measure memory bandwidth on a AMD Ryzen 5 3500X (Zen 2) desktop system with single-channel DDR4 3200MT/s DIMM. This has a theoretical bandwidth around 20 GB/s. But the "sum" and "max" values reported by
likwid-perfctr -g MEM
is around 60 GB/s.How does the bandwidth calculation really work? How do I correctly interpret this performance counter?
To Reproduce with a LIKWID command
Run:
The benchmark reports than:
But the measured results are:
The "sum" and "max" values reported by
likwid-perfctr -g MEM
is around 60 GB/, around 3x greater than physically possible.Hardware
The hardware topology is:
The text was updated successfully, but these errors were encountered: