3

I have a Rasberry PI like hardware which has a basic linux operating system and only one program running called "Main_Prog".

Every time I run a performance test again Main_Prog I get a less than 1% performance fluctuation. This is perfectly acceptable.

When I kill Main_Prog using the kill command, and re-start Main_Prog, the performance changes up to 8%. Further performance tests will vary less than 1% around this fluctuation.

Example

So for example if Main_Prog at first ran at 100 calls/sec and varied between 99-101 calls/sec.

I then did a "kill" command against Main_Prog and restarted using "./Main_Prog &". I then run a performance test and now Main_Prog is running 105 calls/sec with 104-106 calls/sec fluctuation. It will continue to run 104-106 calls/sec until I kill the Main_Prog and start it.

Any idea how to prevent fluctuation or what is happening? Remember, it is VERY consistent. No other programs running on operating system.

Cœur
  • 37,241
  • 25
  • 195
  • 267
slowmo
  • 81
  • 7

1 Answers1

6

Your temporary fluctuation might be related to the page cache. I would not bother (the change is insignificant). See also http://www.linuxatemyram.com/

You might prefill the page cache, e.g. by running some wc Main_Prog before running ./Main_Prog

And you probably still do have some other executable programs & processes on your Raspberry Pi (check with top or ps auxw). I guess that /sbin/init is still running at pid 1. And probably your shell is running too.

It is quite unusual to have a Linux system with only one process. To get that, you should replace /sbin/init with your program, and I really don't recommend that, especially if you don't know Linux very well.

Since there are several processes running in your box, and because the kernel scheduler is preempting tasks at arbitrary moment, its behavior is not entirely reproducible, and that explains the observed fluctuation.

Read also more about real-time scheduling, setpriority(2), sched_setscheduler(2), pthread_setschedparam(3), readahead(2), mlock(2), madvise(2), posix_fadvise(2)

If you are mostly interested in benchmarking, the sensible way is to repeat the same benchmark several times (e.g. 4 to 15 times) and either take the minimum, or the maximum, or the average.

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Yes you are correct that it is not one process. It seems there are about 10 - 20 needed processes that I assume the OS needs to be able to run. I did not replace /sbin/init. Yes, you are right the % change is very small. Though, I would like it to be the same results just for consistency. – slowmo Dec 14 '15 at 12:53
  • @slowmo - just measure how much each call takes and let the threat sleep for the excess time before the next one – dtech Dec 14 '15 at 13:03
  • WOW!! The "wc Main_Prog" actually works! It is now running at its best fluctuation consistently. So now I need to make sure I run "wc Main_Prog" every time I want to kill/restart Main_Prog. – slowmo Dec 14 '15 at 13:41
  • I'd also like to point out that page caching clearing might be a more correct answer! Doing "echo 3 > /proc/sys/vm/drop_caches" yielded more consistent results. – slowmo Dec 14 '15 at 15:19