[Feature request] RAM frequency / timings reading

[keybreak]

Is your feature request related to a problem? Please describe.
I would really love to see actual RAM timings readings, not SPD or XMP.

Describe the solution you'd like

It would be really cool if CPU-X can be first in this department, for some reason there is still no reliable way to get this information in Linux....

[TheTumultuousUnicornOfDarkness]

I would really love to see actual RAM timings readings, not SPD or XMP.

Me too. In fact, I have this idea in my head for a few years, but unfortunately, this has not been implemented...

It would be really cool if CPU-X can be first in this department, for some reason there is still no reliable way to get this information in Linux....

And here we go: how to get this information in Linux?
I know these values can be exposed by EEPROM module (under /sys/bus/i2c/drivers/eeprom). That is how decode-dimms from i2c-tools works.
But reading eeprom files is very slow, and sometimes acpi_enforce_resources=lax is required as boot parameter, and this option can cause potential hardware damage.
For me, this solution is not viable for end-user. 😞

[keybreak]

Even under those circumstances for one of my machines i couldn't still get any info with all those modules and requirements met though...

For me, this solution is not viable for end-user. 😞

Yeah, can't disagree...
This situation is seriously creepy, as Linux has such a vibrant technically driven community, and we still can't get proper RAM readings in 2019?! 🚀

Have you tried to feature request Kernel devs or something of that nature?
I really wonder what are the reasons, maybe it's some security stuff...
That's really awkward to see that we can read pretty much all CPU / GPU information and almost nothing on RAM...

and this option can cause potential hardware damage

Wow....Can you get some sources where damage is done?

P.S. Thanks for all your work, CPU-X is best of it's kind! 👍

[TheTumultuousUnicornOfDarkness]

This situation is seriously creepy, as Linux has such a vibrant technically driven community, and we still can't get proper RAM readings in 2019?!

I agree.

Have you tried to feature request Kernel devs or something of that nature?

No (and I will not).

Wow....Can you get some sources where damage is done?

Sorry; instability is more adequate than damage.
From kernel doc:

	acpi_enforce_resources=	[ACPI]
			{ strict | lax | no }
			Check for resource conflicts between native drivers
			and ACPI OperationRegions (SystemIO and SystemMemory
			only). IO ports and memory declared in ACPI might be
			used by the ACPI subsystem in arbitrary AML code and
			can interfere with legacy drivers.
			strict (default): access to resources claimed by ACPI
			is denied; legacy drivers trying to access reserved
			resources will fail to bind to device using them.
			lax: access to resources claimed by ACPI is allowed;
			legacy drivers trying to access reserved resources
			will bind successfully but a warning message is logged.
			no: ACPI OperationRegions are not marked as reserved,
			no further checks are performed.

[keybreak]

@x0rg

No (and I will not).

I'am not forcing on anything, but just wonder why?
It seems to be the only solution for properly getting hardware information at least for future Kernels...

[TheTumultuousUnicornOfDarkness]

I'm sorry, I just realized that I misread your first post; I was talking about SPD. The acpi_enforce_resources=lax parameters concers SPD.
About SPD, I am not interested to developed such feature, because it does not reflect actual RAM frequency/timings.
These values never change and can be read in some BIOS/UEFI setup:

And decode-dimms can still be used to get these values under Linux, like that:

---=== Timings at Standard Speeds ===---
tCL-tRCD-tRP-tRAS as DDR3-1600                   11-11-11-28
tCL-tRCD-tRP-tRAS as DDR3-1333                   9-9-9-24
tCL-tRCD-tRP-tRAS as DDR3-1066                   7-7-7-19
tCL-tRCD-tRP-tRAS as DDR3-800                    6-6-6-14

But it does not reflect actual parameters: my DDR3 is overclocked to 2133MHz with 12-13-13-24 timings.

CPU-X can report the configured frequency, as you can see on this screenshot:

This data is provided by SMBIOS and can be read with dmidecode -t memory.

It is the only thing supported by CPU-X at the moment.

---

About real timings, after a lot of research, I can not find a way to get them: they are not provided by SMBIOS nor SPD.
So, to answer your last question (sorry for the delay 😬), I will not ask to kernel developers because I don't know myself where these data are stored.
I am very curious to know how they did in CPU-Z (unfortunately, it is a closed source software, so they will not reveal such information), and this feature can be useful.

Anyway, I have no idea how to do that, so I prefer to close this issue because I can not make promises that I am unable to complete, sorry.

[keybreak]

@x0rg
Yep, we both interested in real ones, SPD is easy 😄

Well...Fair enough, if accidentally i'll come across hacker able to reverse CPU-Z and figure out how - i'll make sure to let you know 👍

[keybreak]

@x0rg
btw, this guys also seems to have secret:
https://www.hwinfo.com/

Maybe try contact them, if not already 😃

[TheTumultuousUnicornOfDarkness]

I think you confuse HWiNFO (Windows, closed source) with openSUSE's hwinfo (Linux, GPLv2).
Unfortunately, the last one does not gather memory timings.

[mavelli]

i am following the thread and used cpu-z a few times now while playing around with my timings (2700x ryzen on x470 asrock with 4x16gb 3200 sticks not officially "supported" by amd is tricky and each BIOS update changes things).

did you consider pmbw ( https://panthema.net/2013/pmbw/ )?

[TheTumultuousUnicornOfDarkness]

@mavelli It does not read RAM timings, it does performance tests.
pmbw is based on Zack Smith's bandwidth, and bandwidth is already used in CPU-X to provide CPU caches bandwidth.