Path: utzoo!attcan!uunet!mcsun!ukc!strath-cs!baird!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.sys.sequent
Subject: Re: Timing parallel programs on Symmetry
Message-ID: <JIM.90Jul2125340@baird.cs.strath.ac.uk>
Date: 2 Jul 90 11:53:40 GMT
References: <63900005@uxa.cso.uiuc.edu> <63900006@uxa.cso.uiuc.edu>
	<112093@linus.mitre.org>
Sender: jim@cs.strath.ac.uk
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
Lines: 62
In-reply-to: sokol@starbase's message of 29 Jun 90 12:20:32 GMT

In article <112093@linus.mitre.org> sokol@starbase (Lisa Sokol) writes:

   We have also been having timing problems using Lisp on a Symmetry.
   When multiple processes compete for the same processors, user time appears
   to also include both user time and system time.  The only instance
   in which user time appears to be accurate is if one has sole use of
   the machine.

   Has anyone found a way to run multiple processes and get the user
   timing function to just include user time?

Your query raises some interesting questions, though it is somewhat
confusing. 

The UNIX time command reports three times for a process.

1) User time
	This is the amount of time that the process executes in
	user mode: i.e. the time the process takes executing code
	other than system calls

2) System time
	This is the time that the process takes executing system
	calls. It may also include time servicing interrupts and
	possibly context switching on behalf of other processes.

3) Elapsed time
	The total time taken by the process to execute. This is the
	sum of the user and system time plus any time that the process
	was idle - swapped out, waiting for I/O or possibly waiting
	for access to the CPU.

The only time that is reproducible is the user time: the other two
will depend on external factors such as the system load and interrupt
rate that may vary as the process is repeatedly executed. These can
be minimised or eliminated by dedicating a whole machine to timing a
particular process. Even then, there may still be minor variations.

The kernel maintains the user and system times for each process. The
system clock interrupts many times a second (100 times a second on a
Sequent) and the current running process 'charged' with a clock tick.
If the process was in kernel mode, the system time is incremented. If
it was in user mode, the user time gets incremented. When the process
terminates, the time command picks up the user and system time using
the wait3() system call. The elapsed time is worked out by taking the
difference between the time of day immediately before the command was
executed and after it terminates. The time of day is usually taken
from another clock, the time-of-day clock.

Although the system and user times have the precision of the system's
real time clock, they may not be that accurate. In theory, a process
could give up the CPU just before the real time clock interrupts,
causing the process' tick to get charged to another process. [In
practice this behaviour should even itself out over time.] Another
possibility is that the system loses clock ticks because clock
interrupts get disabled, so processes can get 'free' CPU time. Since
the elapsed time is usually taken from the time of day clock, it will
be as (in)accurate as that clock happens to be.

Hope this explains things.

		Jim