numbers don't lie ...

[Gary Corcoran]

Mike Meyer wrote:
> In <45099123.4000500 at rcn.com>, Gary Corcoran <gcorcoran at rcn.com> typed:
>> The confusing thing is that I thought 'real' time should be >= 'user' + 'sys'.
>> But here 'user' is much greater than 'real' for both machines!  The sense I
>> got from the other messages in this thread is that 'user' time is somewhat
>> meaningless (i.e. unreliable as a measure) in a multi-CPU and/or hyperthreading
>> environment.  Can you clarify?
> 
> 'real' is wall clock time. 'user' and 'sys' are cpu time. If your
> process gets all of some cpu, then user + sys will be the same as real
> time. It's not possible to get more than all of a cpu, so that's a
> maximum *per cpu*. If you have multiple cpus, the formula you want is
> 'real' * ncpu >= 'user' + 'sys'.

Thanks to all of you for the responses.  The thing that was not clear is
that despite the printed messages, user (and sys) time are *not* measures
of time.  IMO it would be much easier to understand if the message said
that they were so-many cpu-seconds, rather than just seconds.  Then it would
be fairly obvious that in a multiprocessor environment that the real time
could be less than the sum of user + sys.  I know, once you understand
the true meaning of user/sys time it's "obvious", but not to the first-time
multiprocessor observer...  :-)

> I made the comment about freebsd's measure of user time being skewed
> by hyperthreading. That's a bit vague. The problem is that waiting
> caused by hyperthreading will count against the instruction that's
> doing the waiting, which skews them. But as Kris pointed out, there
> are other things that have that property, so this is just one more
> complication when it comes to figuring the performance of modern CPUs.

;-)

Thanks,
Gary