SEO

Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
numerous occasions on which the time has been stepped. Looking at the
few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
-0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
(its now 1:30 pm), it has not changed.

Is this excessive? I cant believe the clock is that unstable. Its not in
an air-condition room, but the machine has an uptime of a few weeks, so
it must be reasonably temperature stable now.

Apr 27 14:08:07 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.228893 s
Apr 28 06:35:55 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.177999 s
Apr 28 06:59:39 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.338394 s
Apr 28 21:22:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.270417 s
Apr 29 02:52:35 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.250878 s
Apr 29 07:09:23 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.129417 s
Apr 29 07:36:45 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.331172 s
Apr 29 21:08:29 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.220048 s
Apr 29 23:09:43 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.261370 s
Apr 30 00:00:50 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.386788 s
Apr 30 17:23:40 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.188325 s
May 1 03:01:27 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) 0.296458 s
May 1 04:29:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.444097 s
May 1 05:00:18 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.635503 s
May 1 05:39:13 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
(step) -0.665786 s


My config file is below. I'm not sure if I would be better picking time
servers close to me.


# ident "@(#)ntp.server 1.6 00/07/17 SMI"
#
# /etc/inet/ntp.server
#
# An example file that could be copied over to /etc/inet/ntp.conf and
# edited; it provides a configuration template for a server that
# listens to an external hardware clock, synchronizes the local clock,
# and announces itself on the NTP multicast net.
#

# This is the external clock device. The following devices are
# recognized by xntpd 3-5.93e:
#
# XType Device RefID Description
# -------------------------------------------------------
# 1 local LCL Undisciplined Local Clock
# 2 trak GPS TRAK 8820 GPS Receiver
# 3 pst WWV PSTI/Traconex WWV/WWVH Receiver
# 4 wwvb WWVB Spectracom WWVB Receiver
# 5 true TRUE TrueTime GPS/GOES Receivers
# 6 irig IRIG IRIG Audio Decoder
# 7 chu CHU Scratchbuilt CHU Receiver
# 8 parse ---- Generic Reference Clock Driver
# 9 mx4200 GPS Magnavox MX4200 GPS Receiver
# 10 as2201 GPS Austron 2201A GPS Receiver
# 11 arbiter GPS Arbiter 1088A/B GPS Receiver
# 12 tpro IRIG KSI/Odetics TPRO/S IRIG Interface
# 13 leitch ATOM Leitch CSD 5300 Master Clock Controller
# 15 * * TrueTime GPS/TM-TMD Receiver
# 17 datum DATM Datum Precision Time System
# 18 acts ACTS NIST Automated Computer Time Service
# 19 heath WWV Heath WWV/WWVH Receiver
# 20 nmea GPS Generic NMEA GPS Receiver
# 22 atom PPS PPS Clock Discipline
# 23 ptb TPTB PTB Automated Computer Time Service
# 24 usno USNO USNO Modem Time Service
# 25 * * TrueTime generic receivers
# 26 hpgps GPS Hewlett Packard 58503A GPS Receiver
# 27 arc MSFa Arcron MSF Receiver
#
# * All TrueTime receivers are now supported by one driver, type 5.
# Types 15 and 25 will be retained only for a limited time and may
# be reassigned in future.
#
# Some of the devices benefit from "fudge" factors. See the xntpd
# documentation.

# Either a peer or server. Replace "XType" with a value from the
# table above.
#server navobs1.oar.net 127.127.8.0 mode 5
#server gnomon.cc.columbia.edu 127.127.8.1 mode 5
#server ntp.colby.edu 127.127.8.2 mode 5
#server clepsydra.dec.com 127.127.8.3 mode 5
#server chronos.cru.fr 127.127.8.4 mode 5

server navobs1.oar.net
server utcnist.colorado.edu
server gnomon.cc.columbia.edu
server ntp.colby.edu
server clepsydra.dec.com
server chronos.cru.fr
server ptbtime1.ptb.de
server ntp.metas.ch

#server 127.127.XType.0 prefer
#server 127.127.8.0 prefer
#fudge 127.127.XType.0 stratum 0

### uncommenting bradcost
#broadcast 224.0.1.1 ttl 4
broadcast 224.0.1.1 ttl 0

#enable auth monitor

driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
logconfig =all

#filegen peerstats file peerstats type day enable
#filegen loopstats file loopstats type day enable
#filegen clockstats file clockstats type day enable

#keys /etc/inet/ntp.keys
#trustedkey 0
#requestkey 0
#controlkey 0

Dave wrote:
> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
> numerous occasions on which the time has been stepped. Looking at the
> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
> (its now 1:30 pm), it has not changed.
>
> Is this excessive? I cant believe the clock is that unstable. Its not in
> an air-condition room, but the machine has an uptime of a few weeks, so
> it must be reasonably temperature stable now.
>
> Apr 27 14:08:07 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.228893 s
> Apr 28 06:35:55 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.177999 s
> Apr 28 06:59:39 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.338394 s
> Apr 28 21:22:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.270417 s
> Apr 29 02:52:35 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.250878 s
> Apr 29 07:09:23 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.129417 s
> Apr 29 07:36:45 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.331172 s
> Apr 29 21:08:29 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.220048 s
> Apr 29 23:09:43 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.261370 s
> Apr 30 00:00:50 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.386788 s
> Apr 30 17:23:40 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.188325 s
> May 1 03:01:27 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) 0.296458 s
> May 1 04:29:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.444097 s
> May 1 05:00:18 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.635503 s
> May 1 05:39:13 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
> (step) -0.665786 s
>
>
> My config file is below. I'm not sure if I would be better picking time
> servers close to me.

I am, and you would be! See below.
>
>
<snip>
> server navobs1.oar.net
> server utcnist.colorado.edu
> server gnomon.cc.columbia.edu
> server ntp.colby.edu
> server clepsydra.dec.com
> server chronos.cru.fr
> server ptbtime1.ptb.de
> server ntp.metas.ch
<snip>

You seem to have achieved extreme geographical diversity; IOW you are
using servers located all over the planet!

Servers that are closest to you, in net space; e.g. those with the
lowest value of delay are usually the best choices. Delay is important
because the maximum uncertainty in transmitting time from client to
server is less than or equal to one half of the round trip delay.

All of those servers should have a very good idea of what time it is!
By the time your request packet and the reply have been bounced all over
the planet, the uncertainty is too large for best performance.

Four servers are the minimum for a robust configuration. The magic
numbers are four, five, and seven; protecting you, respectively, from
the failure of one, two, or three servers. Note that "failure" includes
both not responding at all and responding with an incorrect time. It
may be worth noting that the last NTP Survey found several servers
responding to NTP queries without even knowing the correct year!!

I'd suggest picking four servers close to you in net space and running
with those. If you can find five servers close to you, there is no harm
in using all five.

If you feel you need seven, please consider setting up your own stratum
one server using a GPS timing receiver and making it available for
general use.

Dave wrote:
> server navobs1.oar.net
> server utcnist.colorado.edu
> server gnomon.cc.columbia.edu
> server ntp.colby.edu
> server clepsydra.dec.com
> server chronos.cru.fr
> server ptbtime1.ptb.de
> server ntp.metas.ch

If you don't have reliable servers nearby, try ntp.org pool servers near you
http://support.ntp.org/bin/view/Servers/NTPPoolServers

e.g.

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server europe.pool.ntp.org

On 2008-05-01, Dave <foo@coo.com> wrote:

> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
> numerous occasions on which the time has been stepped. Looking at the
> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
> (its now 1:30 pm), it has not changed.

Random jumps like this can be caused by clock hopping.

> My config file is below. I'm not sure if I would be better picking time
> servers close to me.
>
>
> # ident "@(#)ntp.server 1.6 00/07/17 SMI"
> #
> # /etc/inet/ntp.server
> #
> # An example file that could be copied over to /etc/inet/ntp.conf and

BTW: The comment lines (the ones which start with '#') made your article
unnecessarily difficult to read.

> server navobs1.oar.net
> server utcnist.colorado.edu
> server gnomon.cc.columbia.edu
> server ntp.colby.edu
> server clepsydra.dec.com
> server chronos.cru.fr
> server ptbtime1.ptb.de
> server ntp.metas.ch

I'd start by selecting the nearest server to you and using just that.
You should quickly be able to see if this cures your random time jumps.

When it is time to add more time servers, you'll have to decide if the
pool is "good enough" for your purposes.

> broadcast 224.0.1.1 ttl 0

Are you actually operating a multicast server?

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

Richard B. Gilbert wrote:

>> My config file is below. I'm not sure if I would be better picking
>> time servers close to me.
>
> I am, and you would be! See below.
>>
>>
> <snip>
>> server navobs1.oar.net
>> server utcnist.colorado.edu
>> server gnomon.cc.columbia.edu
>> server ntp.colby.edu
>> server clepsydra.dec.com
>> server chronos.cru.fr
>> server ptbtime1.ptb.de
>> server ntp.metas.ch
> <snip>
>
> You seem to have achieved extreme geographical diversity; IOW you are
> using servers located all over the planet!
>
> Servers that are closest to you, in net space; e.g. those with the
> lowest value of delay are usually the best choices. Delay is important
> because the maximum uncertainty in transmitting time from client to
> server is less than or equal to one half of the round trip delay.

I'll change the servers.

I do actually have a Rubidium source, which gives a 1 pps output and can
be locked to GPS. But I cant be bothered to do all that to just have the
time. I dont need sub-second accuracy, but I obviously want to avoid big
jumps like this. I'll pick some closer servers.

I am in the UK.

Dave wrote:
> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
> numerous occasions on which the time has been stepped. Looking at the
> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
> (its now 1:30 pm), it has not changed.

Positive and negative steps which approximately balance each other
indicate a heavily loaded link with variable and asymmetric propagation
delays. Apart from local servers, or your Rubidium PPS, or reducing the
traffic, the other solutions are to apply and get the ISP to apply
traffic shaping to prioritise NTP traffic, or to use the tinker huff and
puff option, noting the health warnings attached to it.

David Woolley wrote:
> Dave wrote:
>> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
>> numerous occasions on which the time has been stepped. Looking at the
>> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
>> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
>> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since
>> then (its now 1:30 pm), it has not changed.
>
> Positive and negative steps which approximately balance each other
> indicate a heavily loaded link with variable and asymmetric propagation
> delays. Apart from local servers, or your Rubidium PPS, or reducing the
> traffic, the other solutions are to apply and get the ISP to apply
> traffic shaping to prioritise NTP traffic, or to use the tinker huff and
> puff option, noting the health warnings attached to it.


I've changed to local servers as suggested

server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org


broadcast 224.0.1.1 ttl 0


statistics loopstats
statistics peerstats
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
logconfig =all


and it has made no significnat difference. (I've just added the lines

statistics loopstats
statistics peerstats

but these were not in the config file when I collected this data.

May 6 06:11:09 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.224887 s
May 6 06:38:22 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.669705 s
May 6 07:18:42 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.253622 s
May 6 07:47:00 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.405924 s
May 6 08:39:43 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) -0.277034 s
May 6 09:13:53 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.144278 s
May 6 11:10:18 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.487560 s
May 6 13:58:14 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) 0.150888 s
May 6 15:02:22 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) -0.243454 s
May 6 16:03:35 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) -0.284934 s
May 6 21:35:00 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) -0.369864 s
May 6 22:39:50 kestrel xntpd[3604]: [ID 774427 daemon.notice] time
reset (step) -0.396888 s


After added the lines

statistics loopstats
statistics peerstats

I stopped and started the deamon (I guess refreshing might do), and get:

May 7 08:35:14 kestrel ntpdate[24721]: [ID 558275 daemon.notice] adjust
time server 78.129.142.80 offset -0.002180 sec

Dave wrote:
> David Woolley wrote:
>> Dave wrote:
>>> Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
>>> numerous occasions on which the time has been stepped. Looking at the
>>> few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
>>> AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
>>> -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since
>>> then (its now 1:30 pm), it has not changed.
>>
>> Positive and negative steps which approximately balance each other
>> indicate a heavily loaded link with variable and asymmetric
>> propagation delays. Apart from local servers, or your Rubidium PPS,
>> or reducing the traffic, the other solutions are to apply and get the
>> ISP to apply traffic shaping to prioritise NTP traffic, or to use the
>> tinker huff and puff option, noting the health warnings attached to it.
>
>
> I've changed to local servers as suggested
>
> server 0.uk.pool.ntp.org
> server 1.uk.pool.ntp.org
> server 2.uk.pool.ntp.org
> server 3.uk.pool.ntp.org

I meant to add that perhaps an overloaded network is the problem. The
machine only has a 256 kb/s uplink (1024 kb/s downlink), and is used as
a web server for a small number of little used domains. Perhaps this is
putting too much strain on it. I occasionally download large files (like
iso images of Solaris), so I'll check if things get worst next time I do
that.

Dave wrote:
> David Woolley wrote:
ositive and negative steps which approximately balance each other
>> indicate a heavily loaded link with variable and asymmetric
>> propagation delays. Apart from local servers, or your Rubidium PPS,
>> or reducing the traffic, the other solutions are to apply and get the
>> ISP to apply traffic shaping to prioritise NTP traffic, or to use the
>> tinker huff and puff option, noting the health warnings attached to it.
>
>
> I've changed to local servers as suggested

That wasn't my suggestion. The usual location of the problem with
balanced positive and negative steps is the link to your ISP, so using
UK servers wouldn't make a difference.

You've actually got runs of positive and negative steps, which is
worrying. Normally pure runs of postive steps indicate a lost interrupt
problem. Runs in a consistent direction and of similar size and
interval generally indicate that something else is trying to discipline
the clock. Alternating steps in positive and negative directions tends
to indicate an overloaded, asymmetric link, but if you have a severe
problem you tend to have the server rejected (which is why the problem
is less common with analogue modems), rather than accumulating a large
correction.

Missed interrupts may be a problem if runs last long enough for ntpd to
adapt to the new, effective, frequency.

>
> server 0.uk.pool.ntp.org
> server 1.uk.pool.ntp.org
> server 2.uk.pool.ntp.org
> server 3.uk.pool.ntp.org
>