ATT Unix millisec clock

Guy Harris guy at auspex.auspex.com
Thu Aug 30 08:20:38 AEST 1990


>a) something like a profiler with millisecond resolution to time
>   how long a C-function takes to execute.
>   BTW, thanks to all of you who replied suggesting the times() system
>   call. He uses that now, though something that has a better resolution
>   would be more useful.

Not all systems *provide* a better resolution.  Systems with BSD-style
"gettimeofday()" may offer a field that's the "microsecond" part of a
time, but most of them don't keep that field correct to the microsecond.
In a lot of systems, what you see from "times()" is what you get....

>b) a sleep() call with millisecond or tenth of second resolution.

There are tricks you can pull with "poll()".  In fact...

>   Curses has a napms() function that supposedly does exactly that,

...the "napms()" function in S5R3.1 (and probably in the S5R3.2 the
original poster mentioned) uses that very technique.  The call is:

	(void) poll((struct pollfd *)0, 0L, ms);

as it appears in the S5R3.1 "curses"; "ms" is the number of milliseconds
to sleep.  ("select()" is used on other systems in a similar fashion.)

>   but I'm told it is unreliable (i.e. doesn't really nap milliseconds,
>   but 1 / HZ seconds).

If so, it's for the same reason I mentioned under a), namely that you
don't *get* millisecond resolution from all systems; you tend to get
1/HZ resolution.  (Lots of UNIX systems handle time by setting up the
hardware to interrupt them once every 1/HZ seconds, and bumping a
counter in the interrupt routine.  Some may be more sophisticated, but
not all are.)



More information about the Comp.unix.questions mailing list