[ntp:questions] Re: is there a way to "lock" the drift frequency
Craig.e.johnston at boeing.com
Tue Nov 18 16:50:04 UTC 2003
hmurray at suespammers.org (Hal Murray) wrote in message news:<vrjbk7o4mvl1f at corp.supernews.com>...
> >Over the years, I've expected someone to fork a version of NTP that
> >has been tweaked to satisfy the "small LAN" community, with no joy to
> >date. This hypothetical version of NTP (say Local NTP), would be
> >tailored for small switched networks characterized by fast/symmetric
> >delays, plenty of bandwidth, a directly connected high stratum server,
> >and strict requirements for fast initial convergence (assuming known
> >drift) and narrow offset margins (forward steps always acceptable).
> >Here, the server is always trusted (within reason), the network is
> >very reliable, and any errors or discontinuities are assumed to be
> >caused by the host (again within reason).
> >Still waiting for that someone (smarter than me),
> I'd put my effort in either of two other directions.
> First would be fixing the lost interrupts on your system(s).
Well yes of course this would be ideal, but is simply impractical. I
run many types of machines, with many types of processors, running
many types of OS's. They *all* exhibit this behavior (missed
I have the source for some of these OS's, but not most. For those I do
have source for, the problems can sometimes be traced to vendor
supplied object-only modules for a boards I must use. Until the recent
versions of Linux w/ low-latency & preemptable patches, there were
many places where interrupts were held off for too long (there are
still a few). So even when it is theoretically possible to fix the
missed interrupt (i.e. I have the source), it is extremely difficult
to track these things down much less fix them. I'm not about to start
mucking around in the Linux virtual memory code, nor do I have the
skill/time to fix every potential kernel module in the system.
Even if I did fix all the problems, now I have to maintain my own
kernel & modules, and distribute them along with my app's. For my
Sun's, Alpha's, SGI's, and PowerPC boxes, I'm just out of luck.
I feel that this is what NTP was developed to do. All these machines
have horribly drifting RTC clocks feeding huge monolithic kernels
running dozens of apps interfacing with a myriad of hardware. NTP sits
quietly in the background keeping things sane. It does 95% of what I
need it to do, with a slightly different mindset it would be perfect.
> The other approach would be to use the cycle counter rather
> than counting interrupts. Previous discussions indicate
> that this gets hard in multi-processor systems. It might make
> an interesting compile-time option for the kernel - safe to
> use it if the SMP option is off.
Now your talking! I've played with the nanokernel in the PPSkit for
i386 Linux that does exactly this. Unfortunately, just as you said, it
doesn't work for SMP which is what all my Linux boxes are. I also
have not been able to patch in both this and the High-Res Timers patch
at the same time (which I need). I'll revisit this when 2.6 is out, as
the HRT patch is integrated. I'm still out of luck for all my other
systems w/o source & w/o TSC's.
More information about the questions