Memtest86+ takes longer with each pass

[Matt]

Testing a couple 4GB RAM sticks in a laptop.

I ran the test continuously (no stopping or rebooting) for 5 passes
without any errors reported. Here is some data on how long the passes took:

pass 0 --- about 50 minutes
passes 0 to 3 cumulative --- 4 hr 15 min = about 64 min each on average
pass 4 --- 1 hr 41 min.

So it would seem that each pass took longer than the previous one.
Certainly pass 4 took about twice as long as pass 0.

Is this normal? Please explain if so.

If it is not normal, what do you think may be wrong?


Here are a few details. The sticks are the same make and model.
Running one at a time they go at 9312 MB/s, 6-6-6-20, single channel.
The first pass for a single stick is done in about 27 min. I don't have
data for more than one pass of a single stick. Together they go at
14652 MB/s, 9-9-9-24, dual channel.

Thanks.

[Matt]

On 02/18/2012 09:01 PM, Matt wrote:
> Testing a couple 4GB RAM sticks in a laptop.
>
> I ran the test continuously (no stopping or rebooting) for 5 passes
> without any errors reported. Here is some data on how long the passes
> took:
>
> pass 0 --- about 50 minutes
> passes 0 to 3 cumulative --- 4 hr 15 min = about 64 min each on average
> pass 4 --- 1 hr 41 min.

pass 5 --- 3 hr 34 min.

[Paul]

Is the fan running on the laptop ? Any chance it is overheating
and throttling back ?

Dell had a few computing products, with really bad throttle behavior.
Throttling much more than was required by the situation. I think
they're a bit more careful about that now.

Other than that, all I can recommend, is the source code is available
for memtest86+ :-) Years ago, I made a three line change, and recompiled
and rebuilt it. What I did, was add some output to the screen while
it was testing. So if you get desperate, there is that option.
(Yes, I have a weird sense of humor...)

To be honest with you, I don't know what I'd try to read out of the thing,
to debug the problem. Reading the throttle bit, would be one possibility.
The processor temperature is another possibility. Reading the
frequency is a bit more difficult (it might mean comparing a timer
register, to the time of day clock). You could try looking for
code like "Bogomips" on the net, and see if the Bogomips rating
changes with time. But all of this kind of stuff would be painful to do,
from the depths of memtest86+. In my case, I copied some existing cache
speed test code, so didn't actually "invent" anything while I was in
there. At the time, I was just amazed that I could rebuild it successfully.
(Free tools you can get, are things like DJGPP and MinGW. I don't
remember right off hand, what tools it needs to rebuild. The computer
I built it on, is no longer running. It's just "parts" now.)

I don't see a reason why the program itself would slow down. The
runtime environment is pretty special, in that there is no OS
present, no timesharing, no ACPI, and the only way the thing
could throttle, is if the hardware detects overheating. While
some BIOS SMM code might still be running, while the test is running,
would they have the nerve to do thermal management in there ?
I don't know. On desktops, the functionality inside SMM is
pretty limited. Maybe laptops are more extensive ? The cool
thing about SMM, is you can only observe it indirectly
(with things like DPC Latency test).

http://en.wikipedia.org/wiki/System_Management_Mode

SMM would still be running, while memtest86+ is running. Memtest86+
would be preempted, anytime SMM wants to run. Normally, the amount
of code in SMM is limited, as the runtime for the SMM code must be
very short (less than one scheduler "clock tick" on the OS, and also
low enough not to upset realtime multimedia playback or recording).
Look for discussions about dpclat, to find cases where the SMM
wasn't designed right. People who set up home audio workstations
for recording, study stuff like that.

Paul

[Matt]

On 02/19/2012 12:23 AM, Matt wrote:
> On 02/18/2012 09:01 PM, Matt wrote:
>> Testing a couple 4GB RAM sticks in a laptop.
>>
>> I ran the test continuously (no stopping or rebooting) for 5 passes
>> without any errors reported. Here is some data on how long the passes
>> took:
>>
>> pass 0 --- about 50 minutes
>> passes 0 to 3 cumulative --- 4 hr 15 min = about 64 min each on average
>> pass 4 --- 1 hr 41 min.
> pass 5 --- 3 hr 34 min.

passes 0 to 8 cumulative 14 hr 24 min = 96 min each on average
passes 6 to 8 cumulative 4 hr 54 min = 98 min each on average

[Matt]

Thank you, Paul.

Yes, the fan is running, faster than normal and probably full out. I
would sort of expect that though. I don't feel much heat, either on the
case or in the exhausted air. The room temperature is unremarkable, so
it isn't picking up ambient heat.

One thing to mention is that the test seems to spend most of its time
with a reading of 100% as its progress through the pass, so that I
expect it to be done soon. Instead it seems to go on forever with that
reading of 100%. There is a separate progress bar for the particular
test that it is doing within the pass, namely Test #8 [Modulo 20, Random
pattern]. It uses maybe half its time in Test #8.

[Paul]

Matt wrote:

>
>
> Thank you, Paul.
>
> Yes, the fan is running, faster than normal and probably full out. I
> would sort of expect that though. I don't feel much heat, either on the
> case or in the exhausted air. The room temperature is unremarkable, so
> it isn't picking up ambient heat.
>
> One thing to mention is that the test seems to spend most of its time
> with a reading of 100% as its progress through the pass, so that I
> expect it to be done soon. Instead it seems to go on forever with that
> reading of 100%. There is a separate progress bar for the particular
> test that it is doing within the pass, namely Test #8 [Modulo 20, Random
> pattern]. It uses maybe half its time in Test #8.

So maybe the laptop is overcompensating. And using too much throttling
and too much fan, for the conditions.

You would need to add some code to the memtest86+ program, to detect changes
of that nature. Monitor the "throttle" bit, or watch the delta_T
on the CPU temperature measurement. And measure the effect CPU
clock rate at regular intervals, and put the value on the screen,
as a means to detect a change.

However, rather than do that, it would be easier to just boot into the
OS, and use programs in there, to monitor how your laptop responds to
stress, and whether it overreacts or not.

This is an example of a program that detects throttling, probably
using a MSR on the processor.

(Demo)
http://ixbtlabs.com/articles2/cpu/intel-thermal-features-core2.html

(Download - look for RMClock, available as RAR or .exe self-extracting)
http://cpu.rightmark.org/download.shtml

For temps, you can try Speedfan from almico.com . It's not so much
the absolute temperature that matters, as much as seeing the temp
stop rising when the system is under stress (implying more than
the fan is being used for cooling, and throttling the execution rate
is responsible for the rest of the change).

If you need a stressful program, while RMClock, Speedfan, or
CPUZ are running, you can try the Prime95 stress test from
mersenne.org/freesoft. That is also a form of memory tester.
It tests memory and CPU at the same time, but can't test
as high a percentage of the memory as memtest86+ can.

Paul

[Matt]

I did some systematic timings of some runs of Memtest86+ and found that
the timing behavior was deterministic. That is, when starting from
reboot and running several passes, and when that experiment is run
several times, the timings are nearly identical (within a couple
seconds): the first passes take the same amount of time in each
experiment, the second passes take the same time, the third passes take
the same time, etc.

Therefore I am ruling out the possibility that the differences between
first and second passes, second and third passes, etc., come from CPU
throttling.

I suppose it is just some peculiarity, accidental or by design, in the
internals of Memtest86+.

[Ant]

Try asking in its official forum: http://www.memtest.org/#forum
--
"Any spoke will lead the ant to the hub." --unknown
/\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.