This is because of the way events are scheduled.  Basically:

* We take the current time, from the `time' variable, and add the
  offset (in this case, it_value).

* We then subtract this from the current time, and divide by the clock
  tick interval, to get the number of clock ticks to wait.

The problem is that there's a race condition here.  The `time'
variable may be up to one tick (plus a little more because we're
inside splclock()) behind the `real' time.  Whatever the difference is
between the `real' time and `time', the timer will fire this much
before it was supposed to (modulo any scheduling delay).

The only way to really `fix' this is to fetch the current time with
microtime() and schedule the event from that.

This applies not only to setitimer(), but also to other places where
we schedule an event with a particular interval: in nanosleep(2),
select(2), poll(2) and emulations of alarm(2).


[Of course this means that programs measuring interval with
gettimeofday() will generally end up doing 3 microtime()s per
iteration.  Guess we should make sure it's fast...]