Nonsensical Run Times and Throughputs

Skip to first unread message

Phillip Karls

Jul 7, 2020, 12:08:52 PM7/7/20
to stressapptest-discuss
Hi there,

I'm on an ARM system with a mainline Linux kernel (v5.5.8). For some reason I get strange results when running stressapptest:
2020/07/07-13:22:36(UTC) Log: Commandline - /root/stressapptest -s 10 -f /mnt/file1.txt -f /mnt/file2.txt -M 250
2020/07/07-13:22:36(UTC) Stats: SAT revision 1.0.9_autoconf, 32 bit binary
2020/07/07-13:22:36(UTC) Log: Fri Jun  7 17:59:48 BST 2019 from open source release
2020/07/07-13:22:36(UTC) Log: 1 nodes, 4 cpus.
2020/07/07-13:22:36(UTC) Log: Defaulting to 4 copy threads
2020/07/07-13:22:36(UTC) Log: Flooring memory allocation to multiple of 4: 248MB
2020/07/07-13:22:36(UTC) Log: Prefer plain malloc memory allocation.
2020/07/07-13:22:36(UTC) Log: Using mmap() allocation at 0xa6e00000.
2020/07/07-13:22:36(UTC) Stats: Starting SAT, 248M, 10 seconds
2020/07/07-13:22:37(UTC) Log: region number 1 exceeds region count 1
2020/07/07-13:22:37(UTC) Log: Region mask: 0x1
2020/07/07-13:22:47(UTC) Stats: Found 0 hardware incidents
2020/07/07-13:22:47(UTC) Stats: Completed: 16650.00M in 503326.56s 0.03MB/s, with 0 hardware incidents, 0 errors
2020/07/07-13:22:47(UTC) Stats: Memory Copy: 16106.00M at 1607.22MB/s
2020/07/07-13:22:47(UTC) Stats: File Copy: 544.00M at 27.10MB/s
2020/07/07-13:22:47(UTC) Stats: Net Copy: 0.00M at 0.00MB/s
2020/07/07-13:22:47(UTC) Stats: Data Check: 0.00M at 0.00MB/s
2020/07/07-13:22:47(UTC) Stats: Invert Data: 0.00M at 0.00MB/s
2020/07/07-13:22:47(UTC) Stats: Disk: 0.00M at 0.00MB/s
2020/07/07-13:22:47(UTC) Status: PASS - please verify no corrected errors

Notice the run time is 503326.56s (instead of ~10 seconds) and the file copy throughput seems to be calculated incorrectly (27.10MB/s vs 544MB over ~10s).

Every once in a while, I get a result that makes sense, but most of the time it looks like the above.

Has anyone seen this behavior before? Any pointers would be greatly appreciated.



Nick Sanders

Jul 8, 2020, 1:37:53 PM7/8/20
I have not seen this before. It sounds like thread runtime is not being calculated correctly. If you are compiling stressapptest,
you can add printouts to these calculations, I've attached a patch that does this. 

stressapptest timings are based on gettimeofday() in:

However, gettimeofday seems to have been deprecated since stressapptest was written, so you might check if your kernel
still supports this, or if something is changing your clocks during the run.


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
To view this discussion on the web visit
Reply all
Reply to author
0 new messages