Re: FreeBSD handles leapsecond correctly

Matthew Dillon wrote:
>: Luigi Rizzo wrote:
[ ... ]
>:> on a related topic, any comments on this one ?
>:> Is this code that we could use ?
>:> 
>:> 	http://www.dragonflybsd.org/docs/nanosleep/
>:
>:I ported the tvtohz change from Dragonfly back to 4.10 and 5-STABLE here:
>:
>:http://www.pkix.net/~chuck/timer/
>:
>:...so anyone who wants to experiment can try it out.  :-)
[ ... ]
> 
>     It isn't so much tvtohz that's the issue, but the fact that the
>     nanosleep() system call has really coarse hz-based resolution.  That's
>     been fixed in DragonFly and I would recommend that it be fixed in
>     FreeBSD too.   After all, there isn't much of a point having a system
>     call called 'nanosleep' whos time resolution is coarse-grained and
>     non-deterministic from computer to computer (based on how hz was
>     configured).

Agreed.  The changes I'd copied back basicly correct the issue of nanosleep() 
waiting an extra tick, so they cut the average latency seen by something trying 
to wakeup at an exact point from about 1.5 * HZ to about 0.5 * HZ, but they 
don't give it finer-grained timing.

>     Since you seem to be depending on fine-resolution timers more and 
>     more in recent kernels, you should consider porting our SYSTIMER API
>     to virtualize one-shot and periodic-timers.  Look at kern/kern_systimer.c
>     in the DragonFly source.  The code is fairly well abstracted, operates
>     on a per-cpu basis, and even though you don't have generic IPI messaging
>     I think you could port it without too much trouble. 
> 
>     If you port it and start using it you will quickly find that you can't
>     live without it.  e.g. take a look at how we implement network POLLING for
>     an example of its use.  The polling rate can be set to anything at
>     any time, regardless of 'hz'.  Same goes for interrupt rate limiting,
>     various scheduler timers, and a number of other things.  All the things
>     that should be divorced from 'hz' have been.

Out of curiosity, what is DragonFly doing with the network timing counters (ie, 
TCPOPT_TIMESTAMP and the stuff in <netinet/tcp_timer.h>), has that been 
seperated from HZ too?

I'm pretty sure that setting:

#define TCPTV_MSL       ( 30*hz)                /* max seg lifetime (hah!) */

...with HZ=1000 or more is not entirely correct.  :-)  Not when it started with 
the TTL in hops being equated to one hop per second...

-- 
-Chuck