Hello,

I am new to NTP. I have a windows server and linux clients.

My server is win2003 setup with meinberg's 
ntp-4.2.0b@20051016-1.1417-o-win32-setup.exe

The clients are all Fedora Core 4 linux, Fedora ntp version is 
ntp-4.2.0.a.20040617-8

I've setup the ntp.conf on the server with :

driftfile "C:\Program Files\NTP\etc\ntp.drift"
server 127.127.1.0 prefer
fudge 127.127.1.1 stratum 8 refid NIST
disable auth

per the document at :

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html

Also I have verified that the "-g" option is in the win32 service startup.

Here are my questions:

1) The service on the win2003 box takes 2-3 minutes to drop from stratum 
16 to stratum 9. The linux boxes won't sync to stratum 16, so I have to 
wait several minutes between booting the server and the clients. Is 
there a way to make the win32 box sync faster?

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 
restarted, with another wait of 2-3 minutes to drop from stratum 16 to 
stratum 9, then reboot the linux clients. Is there a way to configure 
the linux NTP daemons to sync to the server even though the server has aged?

3) Are IRIG sync'd rackmount NTP servers commonly available? I plan on 
putting one in the lab and leaving it on all the time as a possible 
solution (but see the next question...)

4) True NIST-traceable time is not important to me, relative time is. 
I've heard about some plans for an "orphan mode" NTP server 
configuration. Is this in the meinberg exe and/or are there plans to 
release such a capability at some point?

Any other comments or suggestions are welcome.

Thanks in advance,
John

"Skunk Worx" <skunkworx@verizon.net> wrote in message 
news:d9cff.18234$rO4.9489@trnddc05...
> Hello,
>
> I am new to NTP. I have a windows server and linux clients.
>
> My server is win2003 setup with meinberg's 
> ntp-4.2.0b@20051016-1.1417-o-win32-setup.exe
>
> The clients are all Fedora Core 4 linux, Fedora ntp version is 
> ntp-4.2.0.a.20040617-8
>
> I've setup the ntp.conf on the server with :
>
> driftfile "C:\Program Files\NTP\etc\ntp.drift"
> server 127.127.1.0 prefer
> fudge 127.127.1.1 stratum 8 refid NIST
> disable auth
>
> per the document at :
>
> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
>
> Also I have verified that the "-g" option is in the win32 service startup.
>
> Here are my questions:
>
> 1) The service on the win2003 box takes 2-3 minutes to drop from stratum 
> 16 to stratum 9. The linux boxes won't sync to stratum 16, so I have to 
> wait several minutes between booting the server and the clients. Is there 
> a way to make the win32 box sync faster?

Try using iburst option... It will then sync quickly.
server mytimeserver.com iburst

>
> 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 
> restarted, with another wait of 2-3 minutes to drop from stratum 16 to 
> stratum 9, then reboot the linux clients. Is there a way to configure the 
> linux NTP daemons to sync to the server even though the server has aged?
>

Try use iburst option for clients as well.

> 3) Are IRIG sync'd rackmount NTP servers commonly available? I plan on 
> putting one in the lab and leaving it on all the time as a possible 
> solution (but see the next question...)
>
> 4) True NIST-traceable time is not important to me, relative time is. I've 
> heard about some plans for an "orphan mode" NTP server configuration. Is 
> this in the meinberg exe and/or are there plans to release such a 
> capability at some point?
>
> Any other comments or suggestions are welcome.
>
> Thanks in advance,
> John 

On 2005-11-18, Skunk Worx <skunkworx@verizon.net> wrote:

> My server is win2003 setup with meinberg's 
> ntp-4.2.0b@20051016-1.1417-o-win32-setup.exe
>
> The clients are all Fedora Core 4 linux, Fedora ntp version is 
> ntp-4.2.0.a.20040617-8
>
> I've setup the ntp.conf on the server with :
>
> driftfile "C:\Program Files\NTP\etc\ntp.drift"
> server 127.127.1.0 prefer
> fudge 127.127.1.1 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.

> 1) The service on the win2003 box takes 2-3 minutes to drop from stratum 
> 16 to stratum 9. The linux boxes won't sync to stratum 16, so I have to 
> wait several minutes between booting the server and the clients. Is 
> there a way to make the win32 box sync faster?

No.

> 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 
> restarted,

You would be better off making one of your linux systems the
"undisciplined local master ntpd" and "syncing" your win2003 to it.

> 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.

>Is there a way to configure the linux NTP daemons to sync to the server
>even though the server has aged?

Not AFAIK.

> 3) Are IRIG sync'd rackmount NTP servers commonly available?

Here's one: http://www.ese-web.com/299.htm

http://www.google.com/search?q=IRIG+rackmount+ntp+server for links to
more...

Have you thought about adding an IRIG PCI card to the system hosting
your "local master ntpd" ?

Here are some links:

http://www.meinberg.de/english/products/tcr510pci.htm
http://www.ese-web.com/273pci.htm
http://www.symmttm.com/products_bus_level_timing.asp

> 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?

> relative time is.

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

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke wrote:
> On 2005-11-18, Skunk Worx <skunkworx@verizon.net> wrote:
> 
> 
>>My server is win2003 setup with meinberg's 
>>ntp-4.2.0b@20051016-1.1417-o-win32-setup.exe
>>
>>The clients are all Fedora Core 4 linux, Fedora ntp version is 
>>ntp-4.2.0.a.20040617-8
>>
>>I've setup the ntp.conf on the server with :
>>
>>driftfile "C:\Program Files\NTP\etc\ntp.drift"
>>server 127.127.1.0 prefer
>>fudge 127.127.1.1 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 
>>restarted,
> 
> 
> 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.) :

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html

> 
>>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.

Thanks,
John

"Skunk Worx" <skunkworx@verizon.net> wrote in message
news:Ernff.39$9P5.18@trnddc09...
> Steve Kostecke wrote:
[...]
>> 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.

(Some) people here have a way of getting religious about what NTP
should be made to do and what is (horrified face) "inappropriate".

NTP can do several things for you. Some of these things _are_ lost
without proper reference clocks. Like the length of a second; it will
vary with the temperature around a local clock oscillator. There are
people who genuinely don't care about this, and other people who
genuinely don't grasp that.


[...]
>> 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.) :
>
> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html

Go back and read it better. You may be following the docs as stated
above, but you did this without understanding them.

That page explains how you could synchronise a local clock to NIST
using means outside NTP. _Then_ it would be reasonable to fudge its
refid to NIST. Not if you simply let it run free.

Groetjes,
Maarten Wiltink

TJ Horlacher wrote:
> "Skunk Worx" <skunkworx@verizon.net> wrote in message 
> news:d9cff.18234$rO4.9489@trnddc05...
> 
>>I am new to NTP. I have a windows server and linux clients.
>>
>>My server is win2003 setup with meinberg's 
>>ntp-4.2.0b@20051016-1.1417-o-win32-setup.exe
>>
>>I've setup the ntp.conf on the server with :
>>
>>driftfile "C:\Program Files\NTP\etc\ntp.drift"
>>server 127.127.1.0 prefer
>>fudge 127.127.1.1 stratum 8 refid NIST
>>disable auth
>>
>>per the document at :
>>
>>http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
>>
>>Also I have verified that the "-g" option is in the win32 service startup.
>>
>>Here are my questions:
>>
>>1) The service on the win2003 box takes 2-3 minutes to drop from stratum 
>>16 to stratum 9. The linux boxes won't sync to stratum 16, so I have to 
>>wait several minutes between booting the server and the clients. Is there 
>>a way to make the win32 box sync faster?
> 
> 
> Try using iburst option... It will then sync quickly.
> server mytimeserver.com iburst
> 

iburst didn't make any difference on the server. It's still 3-5 minutes 
to sync up to the local hardware oscillator.

For now I am hacking past this with a bash script on the clients. It 
uses ntpq and grabs the "clock=" value, then massages it into a "date" 
command to set the local date/time.

In the longer term, I found that the trak systems timeclocks in the labs 
have a NTP server plugin card available. We are investigating this now.

Our data stream is timestamped externally, no code is supposed to use 
client time for anything related to data, so the client system time is 
not very  critical--only used for things like file timestamps, startup 
tests, remote logging, etc.

Thanks,
John

John,

iburst will only help of the "destination" machine is in "state 4", which
means the ntpd on the destination machine is sync'd and has a known good
drift value.

The very first time ntpd is started on a machine this can take anywhere from
an hour to a day or more.

Once a good drift value is obtained (and assuming the platform can keep time
"well enough"), a restart should get to state 4 in about 11 seconds or so.

H