XPost: alt.windows7.general
On 4/28/2024 8:38 AM, Newyana2 wrote:
On 4/28/2024 2:46 AM, R.Wieser wrote:
Paul,
I could always throw MemTest86 at it to make sure.� Thanks.
I just ran it for an hour and did not get any errors.
�� For what it's worth, I recently found OSS Memtest86+, which
seems to be quite a bit faster than MemTest86. Wikipedia also
implies that it's more up to date and more thorough.
The ones here are from Jan 2024.
https://memtest.org/
while the new versions (6 or 7) are multi-core capable,
you don't have to use multiple cores to carry out a test.
Normally, a memory controller is rate limited while driven
in a dedicated manner by just one core. The advantage of
using multiple cores, may be as a means to exercise more
of the CPU while testing. If a CPU waits 100 cycles for a
burst-of-four cache line to come back, it would depend on
what the code was doing, whether the RAM could keep up or not.
Having 32 cores generate cycles, 31 cores wait, doesn't add
much to the test.
It's possible none of the current programs will run on an older machine,
so you have to be prepared to take that chance while testing.
I do not throw old media away here, just because a new version was
released.
The advantage of using a newer one, is that it recognizes
the memory controller (can read out the parameters OK), and
can identify the hardware properly. I used an older one
for quite a number of years, that made a dogs-breakfast out
of the hardware declaration. Which means gritting your
teeth while looking at the screen. This did not stop it from
being a memory tester however.
As for the bandwidth declaration in the upper left corner
while memtesting, in the past, the code made sense. It
attempted to purge the CPU cache, so the code was not
getting some sort of inaccurate reading from that aspect.
Then it would do the bandwidth test.
But what I did notice, is a strange difference between
a 5600G and a 5950X, where the tiny processor had 2x bandwidth
declared as present, compared to the 5950X. This is likely
wrong in some way, but I can't make sense of how the hardware
is able to do this.
*******
As for comparing versions on some "merit" basis, the Windows
memory tester can at times be better than the others. But
since we don't know what is inside the Windows one, it is hard
to say why that might be the case. On my dead E8400/X48 system,
it was able to pick up a (non-stuck-at) problem when four DIMMs
were installed. But no amount of triangulation could identify
an individual stick as responsible. All the test was able to
tell me, in a sense, is that "I had a memory problem". The
other testers gave the memory a pass. Replacing the memory with
new memory at the time (CAS5), passed all testers, so the problem
was real.
No memory tester tests all locations. The E815 reserved locations
(some BIOS call that tells the caller what is reserved), there
are locations that must not be used by non-BIOS entities. The BIOS
code can be running during SMM (System Management Mode), so the
BIOS usage must be respected. SMM can be called thirty times a second,
while Windows is running. If the runtime of SMM is long, it throws
off DPCLAT testing (and invalidates a computer for audio workstation usage).
You can install two DIMMs in single channel mode, one DIMM becomes
the High Stick, the second DIMM is the Low Stick. If you swap the
two sticks, the E815 memory reservation is not symmetric, and so
the "test coverage" of the DIMM, varies according to whether it is
the Low stick or the High stick. By running two tests, and swapping
the DIMMs in single channel mode, you get slightly better coverage.
But with that level of attention to detail, there might still be
around 1MB of untested (only BIOS can use) memory.
The Windows memory tester, does not move itself out of the way.
Whereas the other memory testers, should move themselves out of
the way. The Windows memory tester, is not an attempt to test 100%
of the memory. The other memory testers are like Ivory Snow,
and cover most but not all of a DIMM.
*******
On Windows XP, there is limited Pool Memory. The Pool Memory
may be in usage by the kernel storage routines. If an application
program, on purpose, tries to use and apply pressure to Pool Memory,
the garbage collector for Pool Memory, may not be able to free up
Pool in time for a write operation to complete. This is how I was
able to see a Delayed Write Failure on WinXP. If it was not for
that particular case, I might never have seen such a failure
on Windows. That was a failure to write C: hard drive, not a USB stick.
I have also seen a problem on Windows XP, where after you boot up,
and you start transferring a file, writes would stop after
about 15GB of file transfer. This may have been due to my "memory problem"
with the four DIMMs, but there is no diagnostic information to go on.
Suddenly, you just couldn't do any more big writes. Rebooting and
the pattern would begin again. I was not able to determine if that
was aided by some malware problem, or it was "just" a memory integrity
problem. The motherboard is dead now, so no more test is possible.
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)