[ntp:questions] NTP settings for machine with irregular, short connections to the Net

Steve Kostecke kostecke at ntp.org
Sun Sep 9 18:17:41 UTC 2007


[NOTE: My configuration suggestions are at the bottom of this rather
long article]

On 2007-09-08, Rikishi 42 <fsck_spam at telenet.be> wrote:

> On 2007-09-08, Steve Kostecke <kostecke at ntp.org> wrote:
>
>> Previously, Rikishi 42 <fsck_spam at telenet.be> wrote:
>
>>> The precision desired here is one of human scale, not milliseconds
>>> (or worse).
>>
>> Please define "human scale".
>
> Good enough(tm) for people who have never heard of NTP. :-)

A serious question deserves a better answer than that.

Are we looking for clocks that drift less than 5 seconds per day? 1
second per day? 1 second per month? 1 minute per month?

Depending on the requirements of this application NTP may or may not be
the right solution.

> The main concern is that that the laptop spends to much time adjusting,
> correcting, etc... when it's only got a short time on the ISP.

Please define "too much time" and tell us why you think this is so.

> As mensionned before, short time is a few (anywhere between 1 and 4)
> hours. As the other machines of that LAN can't rely on the continuous
> presence of the laptop, they too need to update quickly.

Please define "update quickly" and tell us why this is necessary.

>> A network connection is not the only way to acquire the time base
>> used by NTP. Other sources include GPS/WWBV/CHU/MSF/DCF77/etc
>> receivers, high quality external oscillators, and even a serial link
>> (using the dumbclock driver).
>
> Spending money is not really an option.

Please explain why this is so. It would also help to have a through
explanation of your application.

As has been mentioned in another article good, inexpensive (i.e.
<USD75-USD100) GPS units are available. I've got one (a Garmin
GPS-18LVC) sitting in my basement. This receiver in combination with a
Soekris 4801 produced a clock which was stable within +- 10
microseconds.

If you're handy with a soldering iron, and the Time Island is located
within range of a radio clock such as MSF/DCF77, the simple radio clock
described at http://www.buzzard.me.uk/jonathan/radioclock.html may be a
good solution.

> What is that latest option? A serial link? To what ?

The dumbclock driver can be used to acquire time stamps via a serial
link from another system or some other source which can emit properly
formatted time stamps at one second intervals. This scheme may be useful
in situations where no network connection is permitted between certain
systems. I only included it because the nature of your application was
unclear.

>> It is also possible, with a bit of work, to manually adjust the clock
>> frequency. Depending on your requirements this may be Good Enough
>> (tm).
>
> It's precision is what it is.

One would assume that it is desireable for one clock second to roughly
equal one real second; roughly on a par with the average quartz wrist
watch.

> The main concern is to sync the clocks between them from time to time,
> with as little fuss as possible.

Then, as has been suggested in another article, rdate may sufficient for
your application. But you will need to designate one system as the
master clock.

> The type of corrections currently active might cause the various
> machines to have different time (compared to the second), because
> their time source is only available for short times.

So you're looking for all clocks to be "on the same second" ? How much
variance is acceptable?

>>> Imagine a laptop, connected to the net only once every few (2-3)
>>> weeks. The connection lasts a few hours, maybe less. It gets it's
>>> time updated from the NTP server from the ISP.
>>
>> Ntpd doesn't merely "update" the laptop's clock to the "correct
>> time".
>
> I know. And - sorry for the blasphemy - that's the main problem.

Let's leave inflamatory words such as blasphemy out of this discussion.

NTP is designed to synchronize clocks with a time base. In the absence
of a legitimate (i.e. disciplined) time base it is possible to utilize
an arbitrary ntpd as an undiciplined time base.

The way that NTP synchronizes a clock to a time base is by increasing
or decreasing the clock oscillator's frequency with in the range of
-500PPM to +500PPM. This is called slewing the clock. In cases where
the clock offset exceeds a certain threshold (which defaults to 128ms),
by stepping the clock directly to an arbitrary time.

It is possible to make ntpd work in other ways. But the priciple of
"be careful of what you wish for" applies.

>>> This laptop is 'brought back' to that isolated LAN, and subsequently
>>> used as NTP reference to synchronise and update the time of the
>>> other machines.
>>
>> Is the laptop actually moved and is it kept running when it is moved?
>
> Yes, it's moved. That's why a laptop is used. The owner of laptop and
> the isolated LAN is a friend who comes by every 23 weeks. The laptop
> is not kept running dureing transport, that's not an option. Besides,
> I've explained the poor precision on laptops. That's an accepted
> given.

Then this is pointless exercise because you aren't really bringing
anything back to the LAN.

>>> Obviously, the time of that laptop will have shifted in between
>>> connections to the Net.
>>
>> That's because the laptop's clock, which is worse than the average
>> wrist watch, is not being provided with a stable time base.
>
> True. But as long as the other machines on that LAN sync to the same
> time as the laptop, any time they detect it, that's fine.

ntpd _can_ do that.

>>> What can be done to get it's time sync'ed as fast as possible,
>>
>> 1. You need to have a drift file that contains an accurate frequency.
>
> Not an option for me, too fussy.

It's a requirement. The drift file is where ntpd stores the correct
frequency for the clock.

> Would know where to get the frequency.

ntpd populates the drift file after it has been synced to a real time
source for on hour. All you have to do is allow the laptop to be
connected to some real time source for the requisite amount of time.
This validity of this freqency value will be increased by ensuring that
the laptop's usage is similar when it is connected to the net and to the
Time Island. Disabling any processer changing will help, too.

> And if I'm correct, that would cover what happens during
> boot/shutdown.

If your OS is configured correctly, the system clock is saved to the
hardware RTC during shut down.

When the system is booted the system clock is set from the RTC and ntpd
will use the frequency value stored in the drift file to keep the system
clock ticking at what was previously calculated as the correct rate.

>> 2. You need to append 'iburst' to the server lines in the laptop's
>> ntp.conf.
>
> We can try that, thanks !

>> 3. When you connect the laptop to the Intenet:
>>
>> 	* stop ntpd
>> 	* run 'ntpd -gq' or 'ntpdate' (deprecated)
>> 	* start ntpd
>>
>> This should give you initial synchronization well within 1 minute.
>
> Can be usefull in desperate situations, but we'd like to avoid doing it
> manualy, for fear of skipping it when we're in a hurry.

This is why we have shell scripts.

> Ambiant environment is equivalent. During transsport, the laptop might
> get colder. But as long as the LAN is sync'ed rapidly and with minimal
> fuss, then the occasional updates from the ISP will keep things within
> humanly acceptable limits.
>
> In other words, the clocks in the LAN may be off, but all by the same.
> value And from time to time, the laptop 'brings home' a correction.

You could also just use the date command on your laptop to manually set
the clock to the time-pips from a SW/AM/FM station (but not while ntpd
is running).

*** Configuration Suggestion

It seems to me that orphan+broadcast mode may give you what you're
looking for.

Operating ntpd in broadcast mode instead of unicast mode will greatly
reduce the amount of time needed for the fixed systems on your LAN to
notice that the laptop has "returned".

Operating the fixed systems on your LAN as an "orphan mesh" will insure
that no matter which systems are running, one will always be chosen as
the master clock.

Here are my suggested configuration files. You may need to adjust the
file paths for your OS. Please note that they come with no warrantee; if
you break anything you get to keep all the pieces.

-------------------------------------8X-------------------------------------
# Laptop /etc/ntp.conf

driftfile /var/lib/ntp/ntp.drift

# Minimal Authentication
keys    /etc/ntp.keys
trustedkey 1

# Broadcast Server for the Isolated LAN
broadcast isolated.LAN.broadcast.address key 1

# Remote time servers (when connected to the Internet)
# This example uses the global pool. You may wish to narrow down the
# scope by using a sub zone. The server lines were deliberately repeated
# to give you more than three time sources.
server 0.pool.ntp.org iburst
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 2.pool.ntp.org iburst

-------------------------------------8X-------------------------------------

# Fixed system /etc/ntp.conf
# All of the fixed systems can use this file.

driftfile /var/lib/ntp/ntp.drift

# Minimal Authentication
keys    /etc/ntp.keys
trustedkey 1 

# Broadcast+Orphan Mode
tos orphan 6
broadcastclient
broadcast isolated.LAN.broadcast.address key 1

-------------------------------------8X-------------------------------------

Create an /etc/ntp.keys file on the laptop and all of the fixed systems 
containing the following line:

1 M your_password

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




More information about the questions mailing list