SUMMARY: CPU time

Thank you everybody.

The reason why the Execution times vary is due to "fluctuations" in the
amount of memory access needed, which is a factor of the amount of "other
work" the system needs to do.  (The above calculation is both CPU and
Memory intensive).  In addition, having a CPU dedicated to the process
improves the execution times because less CPU cache filling/flushing
activity needs to be done, and this activity is "charged" to the process'
user time too.

Thanx to Jay Lessert for a quick and concise answer.  Thanx also to Grant
McKechnie, Rich Teer, Darren Dunham and Hendrik Visage who all gave me good
answers.

Below is my original posting.

  _Johan




|---------+--------------------------->
|         |           Johan           |
|         |           Hartzenberg/GIS/|
|         |           CSC             |
|         |           @CSC            |
|         |           Sent by:        |
|         |           sunmanagers-boun|
|         |           ces             |
|         |                           |
|         |                           |
|         |           02/05/2003 04:55|
|         |           PM              |
|         |                           |
|---------+--------------------------->
  >------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                  |
  |        To:      sunmanagers@sunmanagers.org                                                                      |
  |        cc:                                                                                                       |
  |        Subject: CPU time                                                                                         |
  >------------------------------------------------------------------------------------------------------------------|




Hi gurus,

I hope someone here can explain to me the real meaning of "User Time".

I am interested in how CPU-time works, so I am using a mathematical
calculation which I run like this.

echo 2999^2999|timex bc>/dev/null

Ignore the sys and real time because this is dependant on other stuff, such
as IO.  The test input values were chosen to generate results within a
useful range, and since dc is not multi-threaded, nr of CPUs should make no
difference.  The tests are being run on Solaris 8 in 64-bit mode on a
system with 2 400 MHz ULTRA SPARC II CPUs.


Firstly, In my mind, re-running this test multiple times should always
produce the same result for User-time since there is only one way in which
bc (and dc) will calculate 2999^2999.  However, the results vary by more
than half a second, depending on how it is run.  The average user time I
get is about 8.3 second, and the results vary from about 8.09 to 8.5
seconds for UserTime.


These are the tests.  I expected the Real time to vary but not the user
time.  However, the user time varied and the results are listed below.
With no psrsets:        8.13-8.28
On dedicated psrset:    8.09-8.16
On Free CPU:            8.22-8.43
One CPU taken offline:  8.39-8.49

The first set of tests are done with no processor sets and both CPUs
online.

The second set of tests are done with the shell tied to a processor set
(and nothing else running in that processor set)

The third set of tests were done on the free CPU (eg with nothing running
one the CPU in the defined processor set)

And the last test is done after taking one of the two CPUs offline.

System load varied depending on how the tests were being run, but generally
stayed in the region from 0.8 to 1.5

Can anybody explain why user-time is not fixed, and why does it vary
depending on how the CPUs are allocated?

Thanx,
  _Johan

P.S> I also tested the dedicated psrset with echo 2999^2999|timex psrset -e
1 bc>/dev/null - eg binding only the bc (and subsequent dc), leaving
everything else to run on the other processor.  This did not affect the
results noticably, in fact it may have been slower rather than quicker.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers