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