[ntp:questions] NTP on local networks

E-Mail Sent to this address will be added to the BlackLists Null at BlackList.Anitech-Systems.invalid
Tue Jul 31 21:08:15 UTC 2012


Will Shackleford wrote:
> We have several computers  with several different
>  operating systems on a local network with no radios and
>  no internet connection.
> The main goal is to keep them synchronized with each other.

 You should be able to do a time island with ntp orpahn mode:
  e.g. I use something similar to this on all PCs / Devices
# ALL (Clients and/or Servers)
tos cohort 1 orphan 11
restrict default limited kod nomodify notrap
restrict 127.0.0.1
restrict source nomodify
keys "/etc/ntp.keys" # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastserver  224.0.1.1
manycastclient  224.0.1.1 key 123 preempt
multicastclient 224.0.1.1 key 123 preempt
broadcastclient


> One frustration I have had is that clients tend to refuse
>  to connect to servers on the network that are "not good enough".
> I assume "not good enough" means too high a stratum
>  although the error messages are not that clear.

 You should be able to tell with:
ntpq -n -c "lpe" -c "las" -c "rv &0" -c "rv &1" -c "rv &2" -c "rv &3" -c "rv &4"
  and the decodes in your html files that come with ntp,
   <http://www.eecis.udel.edu/~mills/ntp/html/decode.html>


> My current solution is to take a laptop to another room
>  with an internet connection, let it sit for an hour and
>  then bring it back to connect the local network where
>  finally the other computers will accept it and synchronize
>  with it.

That is likely the ever increasing dispersion.


> How can I configure a client/peer to always accept a
>  server as "good enough" or atleast always accept the
>  server when no other server can be contacted?

Add prefer for your primary server?
server primary.time-island.nist.gov iburst prefer

 You might also want to increase mindist,
  however too much will likely end up in several
  groups walking away from each other; e.g.

tos mindist 0.020


> Just for my own curiosity, why is just refusing to do
>  what the operator wants the default behavior for
>  clients/peers? Why not always synchronize as well as
>  you can with whichever peers/hosts you can contact?

"operator wants" and ntp commanded to are not equal?

-- 
E-Mail Sent to this address <BlackList at Anitech-Systems.com>
  will be added to the BlackLists.



More information about the questions mailing list