I have a simple design question:

I do have ISDN support in my kernel. I would like to have an accurate
clock on my system, and ISDN delivers a timestamp with every message.
At least here in germany these timestamps are realy good, because they
are synchronized with 'our' official time normal clock.

So I'm thinking about using this timestamps to operate the phase locked
frequency loop included in the kernel when compiling with option NTP.

The (classical) question is: should I hand out the timestamps as a seperate
device, run the standard nntp deamon to use them, which in turn calls the
appropriate kernel functions to adjust the time?

Or should I shortcut this and adjust the time right inside the kernel, without
any device and userland daemon?

I haven't looked at the ntp interface, but I think it should not be that
much kernel bloat, if I use the direct approach.

To calculate the tradeoffs I see two factors:

1) The messages sent by ISDN are not that much. I get about four messages
every time somebody dials in or out the same BRI or closes a connection, I
get many messages if my system uses an ISDN connection itself (of course):
the message size is up to 2k and I have 8k/s bandwidth, so that's not realy
many messages per second.

2) I guess low latency in handling the timestamps will help the phase locked
frequency loop. At least one of my ISDN router systems is a minimal one
(486 with 4MB RAM) and will swap quite often when scheduling nntpd, so I 
would prefer the in-kernel solution (which means I wouldn't be running
nntpd at all on that machine, all its clients are Windows and will use SMB
to synchronize their time).


Does anybody have any comments or hints?
References for further reading (I'm totaly unfamiliar with NTP and time
synchronization in general)? If I should follow the userland approach, is
there some reference implementation for a time-source interface?


Martin