Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: setitimer
Message-ID: <10253@mimsy.UUCP>
Date: 19 Jan 88 16:06:39 GMT
References: <4672@watdragon.waterloo.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

In article <4672@watdragon.waterloo.edu> tcjones@watdragon.waterloo.edu
(Crocodile Dundee) writes:
>... the figures I get seem very inconsistent. Does anyone know what
>happens if a timer expires and you do not have the CPU at the time?

It depends on the kind of timer.  Of course, the only kind that
expires when your process is not running is the real timer, but
the others could expire just before your process is switched out.
The real timer keeps ticking, reloaded from its it_interval.

>What if another timer then expires before you get the CPU?

You get a single interrupt, just like the Vax hardware clock.

>What sort of resolution can one reasonably expect?

No better than the basic kernel clock, which runs at `HZ' hertz.

>I never seem to get anything better than 100ths of seconds accuracy.
>I am on a VAX 8650 under BSD4.3

4.3BSD runs with HZ=100.  There are some provisions for an alternate
profiling clock, but I have never had a chance to experiment with
it, and it does not affect the real and virtual interval timers,
at least.

gettimeofday(), however, provides more resolution in 4.3BSD, by
reading the interval count register and inferring microseconds to
add to its ten-millisecond current time value.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris