MemTest displaying incorrect memory speed

[stevebow]

Using MemTest86 V11.1, it appears that the incorrect RAM Configuration info is being displayed on the System Info page.

I have 4 x 4GB DDR3 DIMMs with timing characteristics of 9-9-9-27 @800MHz. These timings are confirmed by CPU-Z on its Timings tab (as well as shown on the SPD tab in Timing Table #4 "XMP-1600"). While troubleshooting this problem, I have also changed the DRAM timings in the UEFI setup from Auto to manual 9-9-9-27 timings.

However, what is being shown by MemTest86 for Ram Configuration is "DDR3 800MT/s x2 Channel / 9-41-41-109".
I would be expecting "DDR3 1600MT/s x2 Channel / 9-9-9-27".

I've only just started using MemTest86 and am not overy familiar with it, and am using its default configuration.

Am I missing something, or is there an issue here with MemTest86 V11.1 perhaps? I've been looking through the documentation but can't seem to find an answer so far.

[David (PassMark)]

We only recently (in the last 12months) added the display of the currently active memory configuration. Most of the development effort was on getting it right for DDR4 and DDR5.
Not much testing was done on DDR3 systems as they are now around 15 years old.

But if you can post the debug log, we can take a look
https://www.memtest86.com/tech_debug-logs.html

[stevebow]

Just to add that the the following is in the log at various places:

2024-12-04 10:31:40 - poll_timings_e3haswell - [Ch 0] TC_PRE=15866D29 TC_CAS=00005509 (9-41-41-109)
2024-12-04 10:31:40 - poll_timings_e3haswell - [Ch 1] TC_PRE=15866D29 TC_CAS=00005509 (9-41-41-109)
2024-12-04 10:31:40 - poll_timings_e3haswell - MC_BIOS_REQ=00000006 (REQ_DATA=6, REQ_TYPE=0)
2024-12-04 10:31:40 - poll_timings_e3haswell - MC_BIOS_DATA=00000006 (MC_FREQ=6, MC_FREQ_TYPE=0)
2024-12-04 10:31:40 - get_mem_ctrl_timings - [0-0-0] 800 MT/s (9-41-41-109)
2024-12-04 10:31:40 - Current mem timings: 800 MT/s (9-41-41-109)

This is pretty odd.

[stevebow]

But if you can post the debug log, we can take a look
https://www.memtest86.com/tech_debug-logs.html

I won't be able to do it right now as I'm in the middle of a full backup for that PC(...), will post later or tomorrow. Thanks.

[stevebow]

Hi David,

I've attached the requested logfile. I booted into MT (V11.1), went to the Config screen, then immediately exited. I hope it helps.

[keith]

Thanks for the logs.

Can you give this build a try:
https://www.passmark.com/temp/memtes...-11.1.1004.zip

[stevebow]

Hi Keith,

Yes, that appears to have fixed the issue. Build 1004 is now showing "DDR3 1600MT/s x2 Channel / 9-9-9-27", as expected. Thanks very much for the quick response.

Was this simply a display issue? In other words, were tests done with the current public version showing "DDR3 800MT/s x2 Channel / 9-41-41-109" valid?

[David (PassMark)]

The data from the memory controller wasn't being interpreted / displayed correctly.

Memtest86 never changes the BIOS settings.
So during testing the BIOS settings will always be used.

[stevebow]

Ok, I'll redo the tests. Thanks to both for your help.

[Frank_Lin]

Hello, I have the same question, but not DDR3 it's DDR4, can you help me resolving this issue, thank you.

[Richard (PassMark)]

I have the same question, but not DDR3 it's DDR4, can you help me resolving this issue, thank you.

If you can post the debug log, we can take a look
https://www.memtest86.com/tech_debug-logs.html

[Frank_Lin]

Hi Richard, please refer to the attachment, I have used the MemTest86 V11.1 Free Build: 1004 (64-bit), it can resolving the DDR3 issue, but i try the DDR4 intel NB platform (HP 15s-du4020TX、HP Pavilion - 15-cs3043tx、HP15S-FQ2007TU、HP Notebook 14s-dq1010tu) the RAM configuration always Incorrect, i used the MemTest86 V11.1 Pro also too.

[keith]

Thanks for the logs.

MemTest86 is supposedly reporting the current frequency, which can vary dynamically via SAGV. So you might see a different speed under a higher memory workload.

We'll look into how to display this information more clearer.

As background: Intel give this awful description to go along with their awful SAGV acronym.

SAGV (System Agent Geyserville) is a way by which they SoC can dynamically scale the work point (V/F), by applying DVFS (Dynamic Voltage Frequency Scaling) based on memory bandwidth utilization and/or the latency requirement of the various workloads for better energy efficiency at System-Agent. Pcode heuristics are in charge of providing request for Qclock work points by periodically evaluating the utilization of the memory and IA stalls.

[Frank_Lin]

Okay, thank for your help. I hope you can this improve the problem.