Can we see actual live settings for most hardware (CPU and RAM)?

[OneOfMany07]

The bandwidth for caches and RAM appears tested at runtime, but the rest of the information is from defaults not the current running settings. Is it possible to show current settings instead?

Specifically the expected max turbo speed for the CPU (based on threads setting), and live RAM values (bus speed + latencies).

Currently I see the rated non-turbo CPU speed (4.0GHz vs. my actual 4 core turbo of 4.5GHz or the default 4.2GHz even) and the XMP setting from the SPD (800MHz/1600MHz CAS 9 9 9 49 vs. live 2000Mhz CAS 10 11 11 ...).

For me...my BIOS doesn't show me the RAM latency values it'll use when I set the memory timings to "auto". It lists the XMP defaults, even when I've turned off the XMP profile and manually increased the frequency. CPU-z shows actual runtime values, but it'd be nice to have verification of what I'm testing from inside memtest86+ itself (maybe to include in any saved test results too?)

I'm sure this would be lower priority than a lot of other work, but I wanted to bring up the idea in case it's easy or it impacts other work.

[debrouxl]

Thanks for reaching out.

• since the methods (MSRs, MMIO ranges, etc.) to access IMCs are documented, implementing and testing IMC support foundation, then support for any given single platform, so as to see the real memory settings, is doable, without spending time performing reverse-engineering work. The difficulty and amount of work come from adding support for all relevant IMC models from the past couple decades or so, and of course testing support for every IMC on at least one piece of real hardware which contains that model;
• CPU turbo mode (or EDAC, for receiving and displaying information about corrected errors, ECC support (detection & polling) #92 ) support are affected by the same breadth issue, though the methods to achieve them are documented as well.

So it is indeed possible, but it represents a lot of work, so as you guessed, it's certainly lower priority than a number of other tasks :)
Thinking out loud: once the foundations are there, implementing IMC + EDAC + CPU turbo mode support for any given platform together at the same time would help reducing testing time, but maybe not developer time, at least at first ?

[x86fr]

This is already planned in the code but in the TODO list for now.

memtest86plus/app/display.c

Lines 266 to 284 in 0f89814

	if (false) {
	// Try to get RAM information from IMC (TODO)
	display_spec_mode("IMC: ");
	display_spec_ddr(ram.freq, ram.type, ram.tCL, ram.tCL_dec, ram.tRCD, ram.tRP, ram.tRAS);
	display_mode = DISPLAY_MODE_IMC;
	} else if (ram.freq > 0 && ram.tCL > 0) {
	// If not available, grab max memory specs from SPD
	display_spec_mode("RAM: ");
	if (ram.freq <= 166) {
	display_spec_sdr(ram.freq, ram.type, ram.tCL, ram.tRCD, ram.tRP, ram.tRAS);
	} else {
	display_spec_ddr(ram.freq, ram.type, ram.tCL, ram.tCL_dec, ram.tRCD, ram.tRP, ram.tRAS);
	}
	display_mode = DISPLAY_MODE_SPD;
	} else {
	// If nothing available, fallback to "Using Core" Display
	display_mode = DISPLAY_MODE_NA;
	}
	}

Accessing IMCs controller is complex and I disagree with @debrouxl : more and more registers are undocumented on the public datasheets and requires access to NDA datasheets. Anyway, it is planned for Memtest86+ 6.10, starting with the newer platforms like AM5 and LGA1700. 😀

[debrouxl]

Right... well, NDA datasheets are a form of documentation, but unsuitable for published GPL'ed software such as memtest86+, until the NDA somehow becomes void, yeah :)

[yoshinoyatoko]

SMBIOS Type-17 has one field to tell current dram running freq

[x86fr]

SMBIOS is not a reliable source. You have to check IMC registers to be sure.