[ntp:questions] Re: win32 undisciplined local clock sync time

Skunk Worx skunkworx at verizon.net
Fri Nov 18 16:37:56 UTC 2005

Steve Kostecke wrote:
> On 2005-11-18, Skunk Worx <skunkworx at verizon.net> wrote:
>>My server is win2003 setup with meinberg's 
>>ntp-4.2.0b at 20051016-1.1417-o-win32-setup.exe
>>The clients are all Fedora Core 4 linux, Fedora ntp version is 
>>I've setup the ntp.conf on the server with :
>>driftfile "C:\Program Files\NTP\etc\ntp.drift"
>>server prefer
>>fudge stratum 8 refid NIST
>>disable auth
> ntpd is intended to be used in conjunction with a source of time.
> The undisciplined local clock (127.127.1.x) is not appropriate for this
> purpose.

Yes it is. This is an isolated test environment, and I am following the 
NTP documents, adhering to the warnings, and insuring I affect no one else.

>>2) If I reboot the linux clients after a couple of days I get a "too 
>>long without sync" message, and the service on the win2003 box has to be 
> You would be better off making one of your linux systems the
> "undisciplined local master ntpd" and "syncing" your win2003 to it.

It's not an option. The win32 server is brought up first, the windows 
and linux clients second. It's not my choice, just the way the lab is 
configured. They are reluctant to add any more 24/7 machines.

>>with another wait of 2-3 minutes to drop from stratum 16 to stratum 9,
>>then reboot the linux clients.
> Restarting ntpd on the linux systems should be sufficient.

Not in this case. The linux clients are headless and autonomous, and do 
handshaking during initialization to determine their roles. Relative 
time is used for a few diagnostics as part of the handshaking. No common 
time (for me) means fix it and reboot the linux boxes.

Although I can just edit the the init script and loop forever with 
warnings until the stratum drops...this is definitely an option.

>>3) Are IRIG sync'd rackmount NTP servers commonly available?
> Have you thought about adding an IRIG PCI card to the system hosting
> your "local master ntpd" ?

I have but am concerned due to what I've read on the web. Apparently 
some of these cards can take far longer to sync than the 3-5 minutes I'm 
seeing now. I have a requirement that the lab can be brought up in X 
minutes, with a minimum of 24/7 machines powered up. So wherever I can 
save a minute of startup time helps. Thanks for the links.

>>4) True NIST-traceable time is not important to me,
> Then why are you telling your undisciplined local clock to use "NIST"
> as its ref-id?

This was taken directly from the NTP documents for using an 
undisciplined local time source (for testing, etc.) :


>>relative time is.
> Keep in mind that your "time island" will drift unless you provide a
> stable time reference.

In this case it doesn't matter at all. The time just needs to be common 
among the linux clients before they hit rc.local. ntpdate is run before 
ntpd starts, courtesy of step-tickers.


More information about the questions mailing list