[ntp:questions] WiFi & NTP.

Joseph Gwinn joegwinn at comcast.net
Fri Aug 31 13:32:26 UTC 2007


In article <20070831031051.597CD4500C at ptavv.es.net>,
 oberman at es.net (Kevin Oberman) wrote:

> > 
> > Kevin Oberman wrote:
> > >>From: "Richard B. Gilbert" <rgilbert88 at comcast.net>
> > >>Date: Thu, 30 Aug 2007 10:45:01 -0400
> > >>Sender: questions-bounces+oberman=es.net at lists.ntp.org
> > >>
> > >>
> > >>Maarten Wiltink wrote:
> > >>
> > >>>"Guy" <gdelavil at ens.insa-rennes.fr> wrote in message
> > >>>news:1188474891.630591.247300 at k79g2000hse.googlegroups.com...
> > >>>
> > >>>
> > >>>
> > >>>>Something important I forgot to mention is that my goal is not to
> > >>>>have the most precise absolute time but to have the smallest offset
> > >>>>as possible on a local network and using a WiFi connection.
> > >>>>
> > >>>>So I declared one of my devices as an NTP server and the other as a
> > >>>>client (syncing to a single time source as a matter of fact).
> > >>>
> > >>>
> > >>>The 'problem' with that is that you are then at the mercy of the
> > >>>stability of your server. The stability of the crystal that ultimately
> > >>>drives a local clock reference isn't great, it's quite temperature-
> > >>>dependent.
> > >>>
> > >>>On the other hand, it _is_ quite predictable - people have produced
> > >>>graphs where it is clearly visible when the airconditioning in the
> > >>>server room started up, or when doors and windows were opened.
> > >>>
> > >>>The lesson as I read it is to make sure your server has a stable
> > >>>environment. If the motherboard temperature is constant, so will be
> > >>>the crystal speed. However, you are surrounded here by some rather
> > >>>hardcore geeks, who read the lesson differently as requiring that you
> > >>>have the One True Time, and stability will naturally follow from it.
> > >>>
> > >>>Groetjes,
> > >>>Maarten Wiltink
> > >>>
> > >>>
> > >>
> > >>Let's hear it for "The One True Time"!
> > > 
> > > 
> > > And which time is that? UTC, GMT, TAI, ...?
> > 
> > UTC!
> > 
> > > 
> > > I hate leap seconds!!!
> > 
> > Leap seconds do not affect my daily existence.  My computer takes care 
> > of them.
> 
> Sorry, but that is beyond the capability of computers. It takes astronomers 
> to 
> determine when one is needed and humans to teach the computers and other 
> equipment. Only your 'one true time', UTC has this problem. GMT continuously 
> adjusts (also ugly) and TAI makes no attempt to stay in sync with the earth.
> 
> Note that GPS has no concept of the leap second There is a mechanism for 
> handling this, but at some level, it requires human intervention. NTP is nice 
> because it means that YOU don't personally have to deal with them, but some 
> of 
> us do and it is a royal pain. After the last one it was over a month before 
> all of the CDMA and GPS systems I sync against to adjust their times, so I 
> had 
> to adjust my stratum 1s twice, once after the second was inserted and then, 
> one at a time as the carriers got around to them.
> 
> It is all made worse because POSIX does not do leap seconds. To do it right, 
> a system as to be able to run one 61 second minute and POSIX makes this 
> impossible, so there is no really accurate way of making most computers do 
> leap seconds. Assuming your stratum 1s are properly handling leap seconds, 
> NTP has to drift the time, so it is off by quite a bit for quite a while.

The core requirements for POSIX time is to support file timestamps, and 
thus file versioning such as that done by make.  This has to work in a 
totally isolated computer, one with no access to GPS or phone lines or 
radios or to the astronomical data required for UTC or UT1.  So POSIX 
time is basically a form of TAI, at least in theory, although the 
standard is silent on the connection.

In practice, many people set their GPS receivers to emit UTC (versus GPS 
System Time), and let their computers follow that time using NTP.  The 
only problem with this is the gyrations subsequent to a leap second. 

Where these gyrations cannot be tolerated, one approach is to set the 
GPS receivers to emit GPS System Time, and make UTC as needed where 
needed in application code, the bulk of the system using GPS System Time 
(which is explicitly a form of TAI).

Joe Gwinn




More information about the questions mailing list