time command bug in next headers?

[Robert F Tobler <rft@raven.cg.tuwien.ac.at>]

I am working on an i686-next-nextstep3.3 system. I have noticed that the  
system time as reported by is different from the times I get using the  
'getrusage' system call.  I tracked the problem down to the fact that the  
Nextstep headers seem to lie about the value of CLK_TCK.  They tell zsh,  
CLK_TCK is 64, but the man pages and comparison with the times reported by  
'getrusage' say its 60.

I have checked on my m68k-next-nextstep3.3 system, and this exhibits the same  
problem.  On both machines I compiled zsh using gcc, therefore it might also  
be a problem with gcc's handling of system headers, but I don't think so since  
the header file in question (bsd/time.h) is only marginally modified by gcc  
(#undef NULL is inserted somewhere).

If somebody else has also noticed this problem on Nextstep systems (e.g by  
setting REPORTTIME=1 and timing command with /bin/time as well; you'll then  
get both timings and see the difference), I'd request you ignore the Nextstep  
headers and set the value of clktck in jobs.c to 60. (#ifdef NeXT).

Now. in a similar vein I have a few questions: there are a number of  
different system call interfaces for getting the user and system time of the  
process:
	times(...)
	vtimes(....)
	getrusage(...)

What are the advantages and disadvantages of all these interfaces with respect
to portability, overhead, and time resolution?  On Nextstep at least it seems  
as if the getrusage(...) interface has a resolution of 1/100 of a second  
whereas times only has 1/60 sec resolution.

------------------------------------------------------------------------
  Robert F. Tobler                 -  tel:+43(1)58801-4585,fax:5874932
  Institute of Computer Graphics   -  mailto:rft@cg.tuwien.ac.at
  Vienna University of Technology  -  http://www.cg.tuwien.ac.at/~rft/