In article <200408312344.45657.ianzag@megasignal.com>,
	ianzag@megasignal.com (Ian Zagorskih) writes:
> 
> NetBSD IANZAG 2.0G NetBSD 2.0G (IANZAG) #1: Thu Aug 26 02:11:03 NOVST 2004  
> ianzag@IANZAG:/usr/src/sys/arch/i386/compile/IANZAG i386
> 
> According to POSIX docs at 
> http://www.opengroup.org/onlinepubs/009695399/functions/timer_getoverrun.html
> 
> ---cut---
> The timer_gettime() function shall store the amount of time until the 
> specified timer, timerid, expires and the reload value of the timer into the 
> space pointed to by the value argument. The it_value member of this structure 
> shall contain the amount of time before the timer expires, or zero if the 
> timer is disarmed.
> ---cut---
> 
> Same as NetBSD man pages says:
> 
> ---cut---
> The timer_settime() sets the next expiration time of the timer with id timerid 
> to the it_value specified in the tim argument.  If the value is 0, the timer 
> is disarmed.
> ---cut---
 
> Obviously, doing this way we'r lossing nanosecond part and 1 ns becomes 0 us 
> -> timer isn't armed. From my point of view this violates POSIX way :)
> 
> Any ideas/comments ?
> 
> ps: Just porting some own old code and found that timer isn't armed while it's 
> expected to..

Those quotes doesn't answer the key question, but going further:

  Time values that are between two consecutive non-negative integer
  multiples of the resolution of the specified timer shall be rounded up
  to the larger multiple of the resolution. Quantization error shall not
  cause the timer to expire earlier than the rounded time value.

Now, hzto() takes great care to round up, but the nano-second is lost
before getting there in TIMESPEC_TO_TIMEVAL(). Should TS...TV always
round up? It seems, with the present state of affairs, that any number
of timers in the kernel could be firing slightly too early. There's no
harm, ever, in a timer firing nanoseconds late (or later), is there?


Frederick