how to calculate/come up the number of thread to run?

[paopao]

for my ARM platform, if I use -m 10, run ok.
If run -m 20, it will fail immediately.
My question, how to calculate/come up the number of thread to run?

[Nick Sanders]

It should not fail with -m 20. Can you post the actual failure? 

Typically you might want 1 thread per core, which is the default for stressapptest if you don't specify "-m". 

No matter how many busy threads you start, you can only execute one per core at a time, so past that, more threads launched just means more threads sleeping.

--

---
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.
For more options, visit https://groups.google.com/d/optout.

[Yvan Tian]

I have a similar question with Paopao.

Are the reading threads, invert threads and cpu stress threads running at the same time when I configure the number of threads at a suitable value?

Is there any way to calculate the number of thread to run so that the memory will be at full bandwidth, Disk I/O will also be at full bandwidth and the usage of CPU is 100% at the same time?

If we start one thread per core when memory copying or writing blocks to disk, will some of the threads be suspended and as a result the memory couldn't get full stress? or some computing threads will be suspended so that the processor couldn't get full stress from sat?

As in my case, I run sat with the following command, do you have any tuning advice?

 stressapptest -M 10636.94843 -m 48 -i 48 -c 48 -W --read-block-size 1024000 --write-block-size 1024000 --read-threshold 100000 --write-threshold 100000 --segment-size 10240000000 --blocks-per-segment 32 -s 1800 -d /dev/sdb1  -l runlog

And configuration of our system:

CPU: 1x E5-2650 v4 (24-core, 2 Threads per Core)

Mem: 1x 16G DDR4 2400MHz

Disk:  1x 2.0 TB 7200RPM SATA

[Nick Sanders]

On Fri, Nov 9, 2018 at 3:59 AM Yvan Tian <tian...@gmail.com> wrote:

Are the reading threads, invert threads and cpu stress threads running at the same time when I configure the number of threads at a suitable value?

No, all of these are less stressful than the default and will displace more meaningful workloads.

 

Is there any way to calculate the number of thread to run so that the memory will be at full bandwidth, Disk I/O will also be at full bandwidth and the usage of CPU is 100% at the same time?

This is somewhat system dependent, but often the best is one memory copy thread per core/hyperthread, and 2 file copy threads per block device. You can increase/decrease and check power consumption or IO bandwidth to tune to maximize whatever parameter you want maximized. 

  

If we start one thread per core when memory copying or writing blocks to disk, will some of the threads be suspended and as a result the memory couldn't get full stress? or some computing threads will be suspended so that the processor couldn't get full stress from sat?

Yes, in your command below most of the threads will be suspended most of the time. Less stressful threads such as invert, check, or disk will run more often than the more stressful memory copy threads.

 

As in my case, I run sat with the following command, do you have any tuning advice?

 stressapptest -M 10636.94843 -m 48 -i 48 -c 48 -W --read-block-size 1024000 --write-block-size 1024000 --read-threshold 100000 --write-threshold 100000 --segment-size 10240000000 --blocks-per-segment 32 -s 1800 -d /dev/sdb1  -l runlog

Don't use this command as a stress test. 

try instead:

stressapptest -W -f /mount/sdb-fs/file1 -f /mount/sdb-fs/file2 -s 1800 -l runlog

 

And configuration of our system:

CPU: 1x E5-2650 v4 (24-core, 2 Threads per Core)

Mem: 1x 16G DDR4 2400MHz

Disk:  1x 2.0 TB 7200RPM SATA

--

[Tian Yuwan]

Many thanks for your careful reply. Then I have a few other questions:

- Is it enough to check whether the disk are reliable if I remove the "-d" option? If so, what are the options "-d" and "--read--block-size/--write--block-size" combined together with "--write-threshold/--read--threshold"  designed to validate?

- According to your advice, " one memory copy thread per core/hyperthread, and 2 file copy threads per block device" is often the best choice for a system under test and thus the command "stressapptest -W -f /mount/sdb-fs/file1 -f /mount/sdb-fs/file2 -s 1800 -l runlog" is suitable for my configuration.  Does the default setting of "-m" also work for a server system configured with different CPUs and memory such as SUT2 upgraded from the default configuration of SUT1?  

->  Default Configuration(SUT1):

CPU:  1x Intel Xeon E5-2650 v4 (24 cores per chip, 2 Threads per Core)

MEM: 1x 16G DDR4 2400MHz

Disk:   1x 16G DDR4 2400MHz

-> Upgraded Configuration(SUT2):

CPU:  2x Intel Xeon Platinum 8180 (28 cores per chip, 2 Threads per Core)

MEM: 16x 16G DDR4 2666MHz

Disk:   1x 16G DDR4 2400MHz

Thanks,

Yvan Tian

[Nick Sanders]

The default number of memory copy threads will be set to the detected number of runnable cores/hyper threads.

Stresapptest isn't well suited as a rotating storage media test so if you want to do that, you'd need a different tool.

[Yvan Tian]

Why "-d" is not well suited for disk testing? Is there any bug in the function WriteBlocktoDisk()?


在 2018年11月13日星期二 UTC+8上午12:58:41，Nick写道：

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

For more options, visit https://groups.google.com/d/optout.

--

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

For more options, visit https://groups.google.com/d/optout.

--

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

For more options, visit https://groups.google.com/d/optout.

在 2018年11月13日星期二 UTC+8上午12:58:41，Nick写道：

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

For more options, visit https://groups.google.com/d/optout.

--

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

For more options, visit https://groups.google.com/d/optout.

--

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

[Nick Sanders]

On Mon, Nov 12, 2018 at 11:54 PM Yvan Tian <tian...@gmail.com> wrote:

Why "-d" is not well suited for disk testing? Is there any bug in the function WriteBlocktoDisk()?

We ran it on a bunch of disks and it wasn't particularly effective at finding problems.