[ntp:questions] Tricking NTP's driftfile

J. Cochran jdc at smof.fiawol.org
Tue Jun 24 19:38:42 UTC 2008


In article <slrng62hjk.laj.kostecke at stasis.kostecke.net>,
Steve Kostecke  <kostecke at ntp.org> wrote:
>On 2008-06-24, J. Cochran <jdc at smof.fiawol.org> wrote:
>> Steven <sed_facebook at vt.edu> wrote:
>
>> And then for the slave servers,
>> I'd suggest that
>>
>> server 127.127.1.0
>>
>> Also be replaced with 
>>
>> server 127.127.1.0
>> fudge  127.127.1.1 stratum 12
>
>The Undisciplined Local Clock contributes nothing the quality of the
>client systems' clocks and, in fact, can cause problems if
>misconfigured.
>
>The Undisciplined Local Clock is _not_ a "back-up"; it is merely a hack
>which allows an ntpd to pretend to be synced even when no real time
>sources are reachable.

I know that, you know that. But in the OPs case, he really isn't
concerned with having accurate time that's attributable to an authorative
source. He merely wants an isolated network of several macros to all
have a consistent time between them. You may have noticed that he's
*already* using an undiscoplined local clock. My suggestion is to
simply reduce the polling time to reduce his initial startup time
(which he's complaining about) and to fudge the stratum to a high enough
number that *if* for some reason his unconnected network finds itself
on the public internet, then no one will accidently use him as a time
reference. Yet, a low enough stratum that he's not going to have issues
with exceeding stratum 15.

Yes, making a recommendation to the OP that he should get a couple
of GPS receivers (the Garmen 18 LVC is a nice one) and that he should
then use the PPS interface, etc., etc., etc. to make a NTP server that's
accurate to within a few micro seconds and is attributable to a 
national time standard would also solve his problem. However, given
his requirements, it would be more than a little overkill.




More information about the questions mailing list