[ntp:questions] Re: Correcting my time servers clock drift on AlphaES40s / Tru64

David L. Mills mills at udel.edu
Wed Oct 26 03:17:13 UTC 2005


Guys,

Two options you might not find obvious. First, consider using ACTS or 
USNO modem time. Telephone calls are cheap these days and the modem line 
can be shared, as is my office phone now. The rate settles back to 36 
hours between calls.

Second, be the first victim on the block to try NTP orphan mode, now in 
the latest code for test. If interested, drop me a note or visit latest 
documentation on the net. See the tos command.

Dave

Brian T. Brunner wrote:
> This sounds like a job for "NTP For Dummies(tm)", which is the type of
> job my needs call for.
> 
> You (Brett) don't need the systems to be on UTC as much as you need them 
> to be together.  Keeping several machines together is a pleasant side-effect 
> of a working NTP setup, but is not a design objective of NTP.
> 
> Options: 1: Can you get a GPS time receiver? They're in the neighborhood 
> of $100 and will serve time as a "ref clock", the machine it's on (?Terrance?)
> is then a stratum 1 time server, Phillip looks to Terrance as its time server, 
> and all is well.
> 
> Options 2: Can Terrance and Philip look to "outside" networked machines?
> If so they can be configured to get fairly good time from public servers,
> and all is well.
> 
> Option 3: Skip ntp altogether, some human has the job of giving Terrance
> a good-enough time (via reading /dev/wrist/timex and setting system time)
> and Phillip needs a cron job to read Terrance's time on say an hourly basis.
> 
> Option 4: (the one you're using now) use ntp on phillip to get time from 
> ntpd on Terrance, with Terrance reading it's system clock.
> 
> Which of these is your best fit solution?
> 
> Brian Brunner
> brian.t.brunner at gai-tronics.com
> (610)796-5838
> 
> 
>>>>David Woolley <david at djwhome.demon.co.uk> 10/25/05 04:19AM >>>
> 
> In article <1130206120.552423.243120 at g14g2000cwa.googlegroups.com>,
> brett.sander at tenix.com wrote:
> 
> 
>>and asked why we had the current configuration.  He said that he wanted
>>the servers to stay in sync and acknowledged that the time would float
>>(his main point was to keep them in sync).  Our network/server/system
> 
> 
> In that case, you need to create a clear server hierarchy, not to peer,
> or you need to use a protocol, like timed, that is intended for this 
> usage.
> 
> 
>>According to the man pages peer has the following description:
> 
> 
> Your man pages claim conformance to version 3 of the protocol, and the
> RFC, but you are clearly running version 4 of the protocol, for which there
> is not yet a public specification.  Your supplier has probably simply retained
> the man pages from the previous version.  (Personally I strongly disagree
> with the policy of dropping man pages, but Dave Mills is a rather strong
> willed person.)
> 
> 
>>"This command specifies that the local server is to operate in
>>"symmetric active" mode with the remote server host_address.  In this
>>mode,the local server can be synchronized to the remote server and, in
>>addition, the remote server can be synchronized by the local server.
>>This is useful in a network of servers where, depending on various
>>failure scenarios, either the local or remote server host may be the
>>better source of time"
> 
> 
> A fundamental assumption in NTP is that all machines are synchronised
> to true time, so switching from source to source will still access a
> correct time, but possibly with different error bounds.  Trying to peer
> systems that use the local software clock simply results in unstable
> behaviour because neither reference clock tracks true time.  If you have
> multiple machines with a local clock as their source, they need to be
> in a hierarchy so that one particular clock is always the dominant one
> if it is accessible.  However, this is not a supported use of NTP, unless
> the top of the hierarchy is synchronized to true time.
> 
> You will need to set the root clock before starting the main protocol.
> 
> 
>>To my understanding, with our current setup, when terrance starts xntpd
>>it checks its peers for their times.  Then it changes its time to match
>>it (please correct me if I am wrong). Does it check both peers?(in our
>>current setup with both phillip and 127.127.1.1 as peers)
> 
> 
> If the configuration takes, in spite of the misuse of peer, the local
> clock is a server of last resort unless you use "prefer".
> 
> 
>>In the setup below, when terrance starts xntpd, it checks the server
>>(its local clock) and then changes its time to meet it (I assume).
> 
> 
> It's time is always the same as that of its local clock, so it can never
> change its local clock to be match its local clock!!!!
> 
> 
>>Does it then check phillip's time? What does it do if phillips time is
>>different?
> 
> 
> If you enabled it to look, by prefering the local clock, it would get 
> confused because it would almost certainly have two clock with non
> overlapping error bounds.  It may well reject both of them.  Actually,
> I think it may ignore the peer in that case, because it isn't preferred
> and because its stratum number is larger.
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org 
> https://lists.ntp.isc.org/mailman/listinfo/questions
> *******************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept
> for the presence of computer viruses.
> 
> www.hubbell.com - Hubbell Incorporated
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list