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.
> 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.
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.
>> 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.
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).
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.
> 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
>> 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.
> 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.
>>> 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.
> 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).
> 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
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.
> 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.
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.
>> 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.
> 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
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+.
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.
