Memory tests that run under an OS can't test all of memory, right? So why is this "better?"
Do we just not expect individual bits on RAM chips to go bad anymore so all we care about is testing memory access? What's the point of testing if the bad bit or bits are in the area of memory reserved for the kernel and can't be tested?
rmongiovi wrote: Memory tests that run under an OS can't test all of memory, right? So why is this "better?"
Do we just not expect individual bits on RAM chips to go bad anymore so all we care about is testing memory access? What's the point of testing if the bad bit or bits are in the area of memory reserved for the kernel and can't be tested?
Hey,
Yes apps can, you just have to set an appropriate pagefile.
Max
Cpu : Intel 5930K@4.25ghz@1.2v / Cache @4.25ghz@1.20v Cpu Cooler : Corsair H100i Case : Corsair 780T Memory : G.Skills 32GB DDR4-3200mhz CAS 15-15-15-35-1T@1.370v Motherboard : Asus Rampage V Extreme (BIOS 3504) M2 : Samsung 950 Pro NVME 512gb (Gaming) M2 : SSD1 : OCZ RD400A 128gb (windows) SSD1 : Crucial MX100 512gb (data) Gfx : EVGA Titan X w/ 980 Hybrid Cooling AiO Liquid Cooler PSU : Antec HCP-1000W Monitor : Asus RoG Swift
You can page out other applications, but there's going to be part of the kernel that's locked into memory. At the very least it's obvious that you can't page out the page fault handler.
rmongiovi wrote: You can page out other applications, but there's going to be part of the kernel that's locked into memory. At the very least it's obvious that you can't page out the page fault handler.
It's the additional system load having an OS running while performing a test generates that makes it more stressful than an out of OS test. The standalone version of Memtest is okay for finding faulty memory modules, but not great at weeding out memory instability. And one needs to understand the value of a DRAM cell is finite. At some point all bits will need to be refreshed, so memory gets hit in a variety of ways when there are background processes running concurrently to IO tests (random patterns can induce instability, as can the impact of concurrent bus loads).
I personally don't like Windows based ram tests. I have used memtest86 for years and it has worked well. The new Hammer test is a good addition but takes a long time to run through. If you want to stress test your components use Aida64 or one of the other popular stability tests.
Rampage VI Extreme bios 1503 Core i9 7980XE @ 4.4ghz all cores 64 gb Corsair Vengeance RGB Pro 3600 2x RTX 2080 Ti FE NvLink/SLI 2x Samsung 970 Pro 1tb NVME Corsair AX1600i Corsair 1000D case 1x Dell U3818DW 38" Curved Ultrawide and 2x Dell S2716DG 27" 1ms GSYNC 2560x1440 144 hz Win 10 Pro x64
jrmcdou wrote: I personally don't like Windows based ram tests. I have used memtest86 for years and it has worked well. The new Hammer test is a good addition but takes a long time to run through. If you want to stress test your components use Aida64 or one of the other popular stability tests.
Assuming one is experienced at tuning a system, the Googlestressapp test is good for memory. HCI Memtest is good for hitting cache with memory. I've found other tests such as Memtest86 pale in comparison. Some users may not see that though, as they're not versed in tuning memory sub-timings. Plus there's those that haven't compared a vs b, but are hung up on a given ideal - nor are they capable of using these tools in a valid manner. Seen that happen a lot of times. You have to be able to crawl before you can walk... Memory timings are the most misunderstood and shrouded topic in forums. Things have improved over the years, but I've only met two other users in a decade that have a real clue about memory timings and tuning.
.jpg "Raja"){kind=avatar}
