From: Johan Hartzenberg (jhartzen@csc.com)
Date: Fri May 02 2003 - 10:55:03 EDT
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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:20 EDT