Understanding the upside/downside to arguments

[Jonathan]

Hi! I've been using SAT for some time now and find it a useful stresstest for memory overclocking. So far I've been running it quite basic with a set runtime of 1-2 hours with the -W argument and a pause-delay > runtime (I found the test would often get stuck during the pauses). On a modern Intel-based system it was some quirks, it seems to respond well to errors caused by a lack of dram and system agent voltage. It is however not sensitive to errors caused by a lack of VCCIO (memory controller and cache voltage) and as such needs to be complemented with some other test.

Would there be any changes in this regard if I were to play around with the C, m and i thread arguments? Assuming a 10 core 20 thread processor, how does the test allocate these threads on its own and what is the gain of changing stuff around?

[Nick Sanders]

-C is used as a thermal load, it's not a test in the sense that it doesn't have any failure condition.

-i runs a traditional memory inversion test and isn't very stressful. Its running time will displace more stressful -m threads and reduce overall test coverage. So it's not good to run unless you want this particular test case (not common)

stressapptest does find many errors with memory controllers, as the test itself is designed to find errors at the interface between memory controller and DRAM. But low voltage may cause internal memory controller errors which wouldn't be covered. What errors are you seeing?

stressapptest doesn't have much test coverage for cache, and "-W" specifically bypasses cache. You could potentially run it with a small enough memory allocation that it could be cache resident, and not use "-W", and have some cache coverage. But a cache focused test would probably be better.

For voltage issues, the pause is intended to use a step load to find these problems, so using that is your best bet on testing.

It looks like someone found the issue on pause hangs, which are caused by a change in pthreads functionality since stressapptest was written. I'll upload a fix.

On Mon, Jul 27, 2020 at 11:01 PM Jonathan <jonathan...@gmail.com> wrote:

Hi! I've been using SAT for some time now and find it a useful stresstest for memory overclocking. So far I've been running it quite basic with a set runtime of 1-2 hours with the -W argument and a pause-delay > runtime (I found the test would often get stuck during the pauses). On a modern Intel-based system it was some quirks, it seems to respond well to errors caused by a lack of dram and system agent voltage. It is however not sensitive to errors caused by a lack of VCCIO (memory controller and cache voltage) and as such needs to be complemented with some other test.

Would there be any changes in this regard if I were to play around with the C, m and i thread arguments? Assuming a 10 core 20 thread processor, how does the test allocate these threads on its own and what is the gain of changing stuff around?

--

---
You received this message because you are subscribed to the Google Groups "stressapptest-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stressapptest-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stressapptest-discuss/1d0d0734-6e1b-49f4-901c-f752efffdde1o%40googlegroups.com.

[Jonathan]

Thanks for the quick reponse!

Well it's not so much that stressapptest finds errors, it's more so that other commonly used (within the overclocking community) memory stressing software such as Karhu RAM Test and TestMem5 (with a specific config) will detect errors specifically tied to a lack of IO Voltage, while stressapptest doesn't. Karhu and TM5 don't specifically reveal exactly what type of errors these are or how they are produced, I just know that they're tied to this voltage rail specifically which is defined as the Processor I/O Power Rail. It's been relatively easy to narrow it down to this specific voltage since I've had setups that are stable in stressapptest error in other software and seeing them respond to increasing IO voltage only.

The way you explained the W argument makes me suspect that the cause lies there. I'm not sure how the other software I mentioned deal with cache (Karhu actually has a cpu cache option that is recommended to be enabled) but since the IO voltage rail affects both the cache and memory controller it makes sense that bypassing the cache completely makes the test easier to pass without errors. It still responds really well to dram and system agent voltages. I'll play around with not using the W argument to see how that affects things from an IO voltage perspective. If it does have the desired impact, it's actually a great feature to be able to switch between since it aids in troubleshooting specific voltages which is fantastic from an overclockers point of view. Doing a quick comparison I noticed that the memory copy rate (MB/s) goes down by quite a significant amount (nearly a third slower) - not sure how this will impact error detection, time will tell. It still seems to cause the same DRAM power draw.

Thanks for the pause hang fix!

On Tuesday, July 28, 2020 at 6:35:57 PM UTC+2, Nick wrote:

-C is used as a thermal load, it's not a test in the sense that it doesn't have any failure condition.

-i runs a traditional memory inversion test and isn't very stressful. Its running time will displace more stressful -m threads and reduce overall test coverage. So it's not good to run unless you want this particular test case (not common)

stressapptest does find many errors with memory controllers, as the test itself is designed to find errors at the interface between memory controller and DRAM. But low voltage may cause internal memory controller errors which wouldn't be covered. What errors are you seeing?

stressapptest doesn't have much test coverage for cache, and "-W" specifically bypasses cache. You could potentially run it with a small enough memory allocation that it could be cache resident, and not use "-W", and have some cache coverage. But a cache focused test would probably be better.

For voltage issues, the pause is intended to use a step load to find these problems, so using that is your best bet on testing.

It looks like someone found the issue on pause hangs, which are caused by a change in pthreads functionality since stressapptest was written. I'll upload a fix.

On Mon, Jul 27, 2020 at 11:01 PM Jonathan <jonatha...@gmail.com> wrote:

Hi! I've been using SAT for some time now and find it a useful stresstest for memory overclocking. So far I've been running it quite basic with a set runtime of 1-2 hours with the -W argument and a pause-delay > runtime (I found the test would often get stuck during the pauses). On a modern Intel-based system it was some quirks, it seems to respond well to errors caused by a lack of dram and system agent voltage. It is however not sensitive to errors caused by a lack of VCCIO (memory controller and cache voltage) and as such needs to be complemented with some other test.

Would there be any changes in this regard if I were to play around with the C, m and i thread arguments? Assuming a 10 core 20 thread processor, how does the test allocate these threads on its own and what is the gain of changing stuff around?

--

---
You received this message because you are subscribed to the Google Groups "stressapptest-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stressapptest-discuss+unsub...@googlegroups.com.