MemTest86 improvements

[birdie]

Issue 1:

In version 10.6 you've changed how memory information is shown during the test and it's gotten worse.

AFAIK you used to show RAM clocks and timings which was great.

Now you show:

RAM Config: DDR4 3600MT/s / x2 Channel / The first module ID string

Here's what I absolutely don't like about it:

* There's a ton of extra unneeded spaces
* There's a ton of unneeded words ("RAM Config", "/s", etc.)
* You show the ID string for the first module while all modules could be different (including even different OEMs)

Please change it to:

DDR4 3600MHz 16GB x 4, x2 channel, CL19 (and even more timings if you can read/parse this info, e.g. 19-19-19-50-1T)

I.e. there's no need to say "RAM Config", "/s" (it's obvious it's per second), and show the first module ID.

Issue 2:

I don't like how RAM temperature is shown as 0C, when there's no temperature sensor. Please change it to N/A, or RAM Temp: not supported.

Issue 3:

Would be great if you attempted to measure RAM throughput at least five times and show the best result in the end. Why? Because I can run the test several times and each time throughput would be slightly different. The same applies to L1/L2/L3 cache speeds.

Issue 4:

The F12 (make screenshot) shortcut doesn't work during the test. Is this intentional? Could you make it possible?

Issue 5:

Would be great if you changed how HTML files with benchmark results are generated. For some reasons you save them in the UTF-16 encoding with Windows line ends. Would be great if you used UTF-8 or plain ASCII with Unix line ends instead.

Issue 6:

I first talked about it over three years ago and it's still not resolved. MemTest86 loading speed is terribly low, specially when it's placed on the USB flash drive. I don't know if UEFI API has anything to put/copy the entire binary into RAM in a single operation but right now MemTest86 is seemingly loaded bit by bit, without using read-ahead or DMA.

When you start it, it measures certain things (six or seven operations) and the disk activity LED fires up for each one of them.

[David (PassMark)]

#1
Screen space is very limited. Information displayed in V10.6 is indeed different, but only on some platforms.
What is displayed depends on what information is available from the memory controller (MC) & if the MC is one we 'know' about. If we can't get information about the current active RAM config from the MC then we display SPD data instead via the SMBus. But sometimes SPD or the SMBus isn't available and then we might display SMBIOS data, or nothing. But SPD data isn't the current config. It is just the specifications for the RAM, not what is actually used. So we need to try and differentiate the different cases. If you see the text "RAM Config" then you are seeing data from the memory controller and not the SPD data (which was what we displayed in older releases).
Your suggestion also doesn't work if for example you have mismatched sticks (e.g. DDR4 3600MHz 16GB x 2 + 3600MHz 8GB x 4)
I think people like to see the RAM model name if it is available.
Removing the spaces doesn't help readability & adding commas doesn't help fit in more text.

#2
We'll check if this is possible. There might be cases where the 0C data is returned by the RAM stick and looks valid, even when there is no sensor.

#3
We don't want to slow down the startup process by doing a 5x longer benchmark. You can go into benchmark mode and run tests many times if required.

#4
I suspect it is. The main window can operate in several different modes and it is text based (e.g. you can use it from a serial port console, without a monitor connected).
I'll check.

#5
We support many languages, not just English. So plain ASCII is not an option. MemTest86 runs directly on UEFI BIOS and UEFI BIOS is UTF-16.
UTF-8 is technically possible, but every bit of text would need to be converted before output. All browsers support UTF-16, so it shouldn't matter.
Windows is also native UTF-16.

#6
Seems OK to us on modern hardware with a brand name USB3 drive.
Some USB2 drives (or USB3 drives in USB2 ports) can be very slow however. It can also be slow if you have lots of lots of RAM sticks. It can take a minute or two to collect SPD data if you have for example 32 RAM sticks. This is because the SMBus is low bandwidth and can't be used in parallel. If you think it is very slow post a debug log and we can which step is slow

[keith]

Issue 2:

I don't like how RAM temperature is shown as 0C, when there's no temperature sensor. Please change it to N/A, or RAM Temp: not supported.

"N/A" is shown when there is no temperature sensor. Otherwise, MemTest86 thinks it was able to read valid temperature data (maybe mistakenly). In this case, please send a copy of the MemTest86 log under EFI\BOOT\ of the USB flash drive.

Issue 4:

The F12 (make screenshot) shortcut doesn't work during the test. Is this intentional? Could you make it possible?

Theoretically it is possible but it is operating in console mode (rather than graphics mode in the main menu). So there is an additional bit of effort to manually render this to an image file. We'll look into implementing this when we have the chance.

[Syntax2001]

Theoretically it is possible but it is operating in console mode (rather than graphics mode in the main menu). So there is an additional bit of effort to manually render this to an image file. We'll look into implementing this when we have the chance.

Why not save the "screenshot" as a simple text file (perhaps in UTF-16 encoding) that contains the content of the screen (of course, without colors)?
When one opens the file in a text editor -- using a font with fixed size -- it will look like the original screen (of course, without colors).

[David (PassMark)]

Yes, it is technically possible.
But you can also just use the existing HTML test report. Which contains pretty much the same information and more.

Example below.