On Nov 13, 12:18 am, Steve Kostecke <koste...@ntp.org> wrote: > On 2010-11-12, Harry <simonsha...@gmail.com> wrote: > > > On Nov 10, 9:36 pm, Steve Kostecke <koste...@ntp.org> wrote: > > >> Which associations are you attempting to "secure"? LAN client to LAN > >> server? LAN server to remote time server? > > > "LAN server to remote time server." So, this LAN host will be a client > > of the remote time server but will act as a local time server to other > > hosts on the LAN. > > OK. > > I have to question the wisdom of using only one remote time server. > > As has been stated elsewhere you're better off using a large enough set > of remote time servers (i.e. 4 or more) to allow NTP to detect and > discard "false-tickers" (bad clocks). Multiple time sources also provide > you with redundancy in the event of server failure/connectivity issues. > > If this is a case of regulatory compliance then you really ought to have > the budget to solve the problem correctly (with GPS-synced NTP > applicances). > > -- > Steve Kostecke <koste...@ntp.org> > NTP Public Services Project -http://support.ntp.org/
Steve, appreciate your response. My ntp.conf looks like this right now. server 0.asia.pool.ntp.org server 1.asia.pool.ntp.org server 2.asia.pool.ntp.org I assume, then, that adding a couple more entries should address the "4 or more" tip of yours and provide me a stable and accurate time... enough to not necessitate the need for an MD5 authentication. Chuck Swiger in a parallel incarnation of this question (sorry about that!) has shared his wonderful insight on the similarity between (non- maliciously) false and (maliciously) rogue tickers. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
