time command bug in next headers?

time command bug in next headers?

[Robert F Tobler]

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/

Re: time command bug in next headers?

[Richard Coleman]

> 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.

times() is part of the POSIX standard, and so should give the greatest
amount of portability for the future.  At one time, the code used
getrusage() for BSD style machines, and times() for SYSV style machines.
The code to do this was very ugly (way too many #define's scattered in
the code).  As part of the POSIX-ification of the code, this was all
rewritten to use times() everywhere.

The best way to fix the problem with the Next's is to just use
some #ifdef's to change the clock tick back to 1/60 (what in the
hell was Next thinking when they changed this).

rc