What is the fudge line for in NTP?

[goldenradium2001]

Can anyone tell me a good definition of what the fudge line is used for in NTP?

Thanks.

 

[Apricot]

1. About NTP

NTP is used to synchronize the time of a computer client or server to another server or a referenced time source such as a radio, a satellite receiver or a modem. It provides client accuracy typically within a ms on a LAN or within 10ms over a WAN relative to a primary server synchronized to Coordinated Universal Time (UTC). Bringing up a NTP primary server requires a radio or satellite receiver or modem.

Time is distributed through a hierarchy of NTP servers, with each server adopting Primary (stratum 1) servers which are at the top of the pile and have access to some external time source, usually a radio clock. A stratum-2 server is one which is currently obtaining time from a stratum-1 server,
a stratum-3 server would get its time from a stratum 2 server and so on. To avoid long lived synchronization loops the number of strata is limited to 15. If your network is isolated and you cannot access other people's servers across the Internet, a radio clock may make a good investment. Otherwise you would configure your server to one of the known primary or secondary NTP servers.

Each client in the synchronization subnet (which also may be a server itself) chooses exactly one of the available servers to synchronize to, usually from among the lowest stratum servers it has access to. Since thhis is not always an optimal configuration, NTP operates under another premise as well; i.e., each server's time should be viewed with a certain amount of distrust. NTP really prefers to have access to several sources of lower stratum time (at least three) since it can thenapply an agreement algorithm to detect insanity on the part of any one of these. Normally, when all servers are in agreement, NTP will choose the best of these in terms of lowest stratum, closest (in terms of network delay) and claimed precisions, along with several other considerations.

Finally, there is the issue of association modes. There are a number of modes to choose from depending on the association between each of the servers. Configuring an association in symmetric-active mode (usually indicated by a peer declaration in the configuration file) indicates to the remote server that one wishes to obtain time from the remote server and that one is also willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected via diverse network paths, which is presently the case for most stratum - 1 and stratum - 2 servers on the internet today. Configuring an association in client mode (usually indicated by a server declaration in the configuration file) indicates that one wishes to obtain time from the remote server, but that one is not willing to provide the time to the remote server. This mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients. Where the requirements in accuracy and reliability are modest, clients can be configured to use broadcast or multicast
modes. Where maximum accuracy and reliability are required, clients and servers operate in either client, server, or symmetric modes.



2. Setting up an NTP server

1. Copy over /etc/inet/ntp.server to /etc/inet/ntp.conf

# cp /etc/inet/ntp.server /etc/inet/ntp.conf

2. Edit ntp.conf file

I have added lots of comments in this file for clarification. Default file does not have many comments.

#----- start of ntp.conf file ---------------------
# @(#)ntp.server 1.4 97/05/05 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.
#
# SEE RFC 1305 ON FOLLOWING CLOCK DEVICES:
# This is the external clock device. The following devices are recognized by xntpd 3.4y:
#
# XType Device Name Description
# -------------------------------------------------------
# 1 (none) LOCAL Undisciplined Local Clock
# 2 trak GPS_TRAK TRAK 8820 GPS Receiver
# 3 pst WWV_PST PSTI/Traconex WWV/WWVH Receiver
# 4 wwvb WWVB_SPEC Spectracom WWVB Receiver
# 5 goes GPS_GOES_TRUE TrueTime GPS/GOES Receivers
# 6 irig IRIG_AUDIO IRIG Audio Decoder
# 7 chu CHU Scratchbuilt CHU Receiver
# 8 refclock- GENERIC Generic Reference Clock Driver
# 9 gps GPS_MX4200 Magnavox MX4200 GPS Receiver
# 10 gps GPS_AS2201 Austron 2201A GPS Receiver
# 11 omega OMEGA_TRUE TrueTime OM-DC OMEGA Receiver
# 12 tpro IRIG_TPRO KSI/Odetics TPRO/S IRIG Interface
# 13 leitch ATOM_LEITCH Leitch CSD 5300 Master Clock Controller
# 14 ees MSF_EES EES M201 MSF Receiver
# 15 gpstm GPS_TRUE TrueTime GPS/TM-TMD Receiver
# 17 datum GPS_DATUM Datum Precision Time System
# 18 acts NIST_ACTS NIST Automated Computer Time Service
# 19 heath WWV_HEATH Heath WWV/WWVH Receiver
# 20 nmea GPS_NMEA Generic NMEA GPS Receiver
# 22 pps ATOM_PPS PPS Clock Discipline
# 23 ptbacts PTB_ACTS PTB Automated Computer Time Service
#
# 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.
#If you are adding a local hardware clock device,
#its driver is identified here by a directive like: server 127.127.XX.0 where 127.127 alerts NTP that this is a local rather than a remote network peer, and XX is a clocktype described in the NTP distribution. The restrict directive in this config file specifies that this host will only talk to the two IP addresses
specified; it won't trust anyone else, and it won't serve time to anyone else.



#following three lines are there by default, change them according to your own setup.

server 127.127.XType.0 prefer

fudge 127.127.XType.0 stratum 0

broadcast 224.0.1.1 ttl 4

#three types of time servers
# 1. peer host_address [ key # ] [ version # ] [ prefer ]
# Specifies that local server is to operate in symmetric active mode with
# remote server specified as host_address, i.e.
# local server can be synchronized to the remote server
# 2. server host_address [ key # ] [ version # ] [ prefer ] [ mode] server
# Specifies that the local server is to operate in "client" mode with the remote server named in the command. In this mode the local server can be synchronized to the remote server, but the remote server can never be synchronized to the local server.
# 3. broadcast host_address [ key # ] [ version # ] [ ttl # ]
# Specifies that the local server is to operate in
# broadcast" mode where the local server sends periodic
# broadcast messages to a client population at the
# broadcast/multicast address named in the command
#
# key Indicates that all packets sent to the
# address are to include authentication fields,
# encrypted using the specified key number. The
# range of this number is that of an unsigned
# 32 bit integer. By default, an encryption
# field is not included.
# version Specifies the version number to be used for
# outgoing NTP packets. Versions 1, 2, and 3
# are the choices; version 3 is the default.
# prefer Marks the host as a preferred host. This
# host will be preferred for synchronization
over other comparable hosts.
# for complete listing see man page on xntpd


Sample ntp.conf file for an NTP primary stratum 1 server:
server 127.127.5.0
fudge 127.127.5.0 stratum 1


Sample ntp.conf file for an NTP server in peer mode:
peer ntppeerserver


Sample ntp.conf file for an NTP server in server mode:
server sometimeserver prefer
server sometimeserver
server sometimeserver


# we can always fall back to the local clock.

server 127.127.1.0
fudge 127.127.1.0 stratum 9

Once you have created your ntp.conf file, save it and start the xntpd
daemon.
# /usr/lib/inet/xntpd &

3. Setting up an NTP client

1. Copy over /etc/inet/ntp.client to /etc/inet/ntp.conf
# cp /etc/inet/ntp.client /etc/inet/ntp.conf


Default ntp.client file uses multicast to receive NTP updates. This can be changed to broadcast as well if you wish to limit where the NTP client
can get its updates. (Broadcast packets are not forwarded to other subnets whereas multicast packets are).

#
# /etc/inet/ntp.client
#
# An example file that could be copied over to /etc/inet/ntp.conf; it provides a configuration for a host that passively waits for a server to provide NTP packets on the ntp multicast net.
#

multicastclient 224.0.1.1



2. Start the xntpd daemon
# /usr/lib/inet/xntpd -m &

(We start the xntpd daemon with the -m argument to listen for multicast packets
if you were using broadcast as a method of receiving NTP updates you would use
-b as the argument)

4. Using the ntpdate command


The ntpdate utility sets the local date and time. To deter-
mine the correct time, it polls the Network Time Protocol
(NTP) servers on the hosts given as arguments. This utility
must be run as root on the local host.It obtains a number
of samples from each of the servers and applies the standard
NTP clock filter and selection algorithms to select the best
of these.

It can be run on a regular basis from cron(1M) as an alter-
native to running a daemon. Doing so once every one to two
hours will result in precise enough timekeeping to avoid
stepping the clock.


If you're are already running the xntpd daemon you can't use the ntpdate command.
Trying to do so will generate the following error :


# ntpdate champ
23 Sep 14:55:52 ntpdate[19780]: the NTP socket is in use, exiting


You must also be root user to run the ntpdate command or you will see an error like this returned :
% ntpdate champ
23 Sep 14:44:36 ntpdate[19743]: bind() fails: Permission denied


When specifying a server with the ntpdate command make sure that your naming services are already up and running so that the name can be translated to an IP address, otherwise you are likely to encounter the following error.
# ntpdate tiger
23 Sep 15:20:43 ntpdate[20041]: no server suitable for synchronization found

In this example we specify the ntp server "jedi" to sync with.
# ntpdate jedi
23 Sep 17:12:21 ntpdate[20963]: adjust time server 129.148.192.147 offset 0.001422 sec


5. Using the ntpq command

ntpq queries NTP servers which implement the recommended
NTP mode 6 control message format, about current state. It
can also request changes in that state. The program can be
run in interactive mode; or it can be controlled using com-
mand line arguments. Requests to read and write arbitrary
variables can be assembled, with raw and pretty-printed out-
put options available. By sending multiple queries to the
server, ntpq can also obtain and print a list of peers in a
common format.


To query an NTP server for a list of its peers:
# ntpq -p jedi

remote refid st t when poll reach delay offset disp
==============================================================================
*eastpager1.East dollar.East.Sun 3 u 97 64 376 2.03 4.564 2.33
LOCAL(0) LOCAL(0) 5 l 19 64 377 0.00 0.000 10.01
NTP.MCAST.NET 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
255.255.255.255 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
+sunswe.Sweden.S carbon.UK.Sun.C 3 u 48 64 377 156.80 6.367 0.41
+canadamail1.Can franc.East.Sun. 3 u 12 64 377 29.48 13.528 29.65
-cosmo.Eng.Sun.C rolex.East.Sun. 2 u 98 128 377 84.08 -1.069 0.87
-centralpager1.C venus.EBay.Sun. 3 u 41 128 377 68.73 -19.219 6.70


remote - is the remote peer
refid - is the host that the peer is synchronizing to
st - stratum number
t - type ie. unicast, mulitcast, or local (- = dont know)
poll - polling interval in secs
reach - reachability register


* in remote indicates currently selected peer
+ means that the host is an acceptable peer for synchronization but not accepted
- not acceptable


6. Some useful debugging

When using "server" mode (association) it is advisible to have at least 3 different servers listed in the ntp.conf file. If the servers that you are
configuring are out on the Internet and you have a Firewall set up, you will want to make sure that there is a rule on the Firewall that allows port 123 NTP traffic in and out from your NTP server.
It will normally take about 5 minutes or more for your NTP server to become synchronized with the time servers listed in the ntp.conf. Until you become synchronized you will not start sending out broadcast/multicast NTP packets
to other NTP clients. Normally these packets are sent every 64secs.

Both xntpd and ntpdate have debug options but be aware that if you use ntpdate -d it will only "go through the motions" and not actually poll the network.


In this example we are using the ntp.client for ntp.conf and have turned on xntpd -d

# /usr/lib/inet/xntpd -d &
20743
# Solaris tick = 10000
kernel vars: tickadj = 625, tick = 10000
adj_precision = 1, tvu_maxslew = 61875, tsf_maxslew = 0.0fd70a37
create_sockets(123)
bind() fd 19, family 2, port 123, addr 00000000, flags=1
bind() fd 20, family 2, port 123, addr 7f000001, flags=0
bind() fd 21, family 2, port 123, addr 8194c097, flags=1
init_io: maxactivefd 21
report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec,
1 event, event_unspec' (0xc010)
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147

(129.148.192.147 is the host "jedi&quot

And at the same time we started snooping the ntp client on port 123 (ntp)
we are expecting to see either multicast or broadcast NTP packets.

# snoop -d le0 port 123
Using device /dev/le (promiscuous mode)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:15 1999)
champ -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:46 1999)
jedi -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:49 1999)
jedi -> BROADCAST NTP broadcast (Thu Sep 23 16:42:50 1999)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:19 1999)
champ -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:50 1999)
jedi -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:53 1999)
jedi -> BROADCAST NTP broadcast (Thu Sep 23 16:43:54 1999)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:44:23 1999)




7. Known Bugs

4060650 xntpd loops continuously burning cpu and leaking memory rendering
m/c unuseable

4097366 external clock hardware isn't supported by xntpd

4192098 xntpd does not synchronize with "c011 sync_alarm" on a few Ultra 5 systems

4130698 ntp installation / upgrade instructions for Solaris 2.6

4061948 SPARC only: 2.5.1 SUNWxntp Package Is Incompatible With Solaris 2.6
(E10k systems only)


8. Additional resources for NTP

NTP and other clock synchronization products

http://www.eecis.udel.edu/~ntp

NTP RFCs

http://www.con.wesleyan.edu/~triemer/network/ntp/ntp_tcp.html

 

[Apricot]

Reference clock addresses are of the form 127.127.Type.Unit where Type is an integer denoting the clock type and Unit indicates the type-specific unit number. You configure reference clocks by using a server statement in the configuration file where the HostAddress is the clock address. The key, version and ttl options are not used for reference clock support.

Reference clock support provides the fudge command, which configures reference clocks in special ways. This command has the following format:

fudge 127.127.Type.Unit [ time1 Seconds ] [ time2 Seconds ] [ stratum Integer ] [ refid Integer ] [ flag1 0 | 1 ] [ flag2 0 | 1 ] [ flag3 0 | 1 ] [ flag4 0 | 1 ]

The time1 and time2 options are in fixed point seconds and used in some clock drivers as calibration constants

 

[Apricot]

fudge 127.127.t.u [ time1 secs ] [ time2 secs ] [ value1 int ] [ value2 int ] [ flag1 0|1 ] [ flag2 0|1 ]

There are two times (whose values are specified in fixed point seconds), two integral values and two binary flags available for customizing the operation of a clock. The interpretation of these values, and whether they are used at all, is a function of the needs of the particular clock driver.

Xntpd on Unix machines currently supports several different types of clock hardware plus a special pseudo-clock used for backup or when no other clock source is available. In the case of most of the clock drivers, support for a 1-pps precision timing signal is available as described in the pps.txt file in the doc directory of the xntp3 distribution. The clock drivers, and the addresses used to configure them, are described following: 127.127.1.u - Local synchronization clock driver

This driver doesn't support an actual clock, but rather allows the server to synchronize to its own clock, in essence to free run without its stratum increasing to infinity. This can be used to run an isolated NTP synchronization network where no standard time source is available, by allowing a free running clock to appear as if it has external synchronization to other servers. By running the local clock at an elevated stratum it can also be used to prevent a server's stratum from rising above a fixed value, this allowing a synchronization subnet to synchonize to a single local server for periods when connectivity to the primary servers is lost.

The unit number of the clock (the least significant octet in the address) must lie in the range 0 through 15 inclusive and is used as the stratum the local clock will run at. Note that the server, when synchronized to the local clock, will advertise a stratum one greater than the clock peer's stratum. More than one local clock may be configured (indeed all 16 units may be active at once), though this hardly seems useful.

The local clock driver uses only the fudge time1 parameter. This parameter provides read and write access to the local clock drift compensation register. This value, which actually provides a fine resolution speed adjustment for the local clock, is settable but will remain unchanged from any set value when the clock is free running without external synchronization. The fudge time1 parameter thus provides a way to manually adjust the speed of the clock to maintain reasonable synchronization with, say, a voice time announcement. It is actually more useful to manipulate this value with the xntpdc(8) program.

127.127.3.u - Precision Standard Time/Traconex 1010/1020 WWV/H Receiver

This driver can be used with a PST/Traconex Time Source 1010 or 1020 WWV/WWVH Synchronized Clock connected via a serial port. Up to four units, with unit numbers in the range 0 through 3, can be configured. The driver assumes the serial port device name is /dev/pst%d (i.e. unit 1, at 127.127.3.1, opens the clock at /dev/pst1) and that the clock is configured for 9600-baud operation.

The fudge time1 and time2 parameters are configured directly into the receiver as nominal propagation delays when synchronized to WWV and WWVH, respectively; the internal DIPswitches ordinarily used for that purpose are disabled. The default values are 0.0075 and 0.0265 seconds, respectively, which are about right for Toronto. Values for other locations can be calculated using the propdelay program in the util directory of the xntp3 distribution or equivalent means described in the user's manual.

The fudge value1 parameter can be used to set the stratum at which the peer operates. The default is 0, which is correct if you want the clock to be considered for synchonization whenever it is operating, though higher values may be assigned if you only want the clock to provide backup service when all other primary sources have failed. The value2 parameter is set to the number of minutes which the daemon will allow the clock to go without synchronization before it starts disbelieving it. The default is 20, which is suitable if you have good quality backup NTP peers. If your network is isolated or your network connections are poor it might be advantageous to increase this value substantially.

The fudge flag1 can be used to modifiy the averaging algorithm used to smooth the clock indications. Ordinarily, the algorithm picks the median of a set of samples, which is appropriate under conditions of poor to fair radio propagation conditions. If the clock is located relatively close to the WWV or WWVH transmitters, setting this flag will cause the algorithm to average the set of samples, which can reduce the residual jitter and improve accuracy.

The fudge flag2 can be used to force the driver to send to the clock the commands required to reprogram the current WWV and WWVH fudge delays into it. This is normally done only when the values are to be changed, such as during inital setup and calibration. Setting the (otherwise undocumented) fudge flag3 will cause the driver to reset the clock. The latter two flags are generally useful primarily for debugging.

127.127.4.u - Spectracom 8170 and Netclock/2 WWVB Synchronized Clocks

This driver can be used with a Spectracom 8170 or Netclock/2 WWVB Synchronized Clock connected via a serial port. Up to four units, with unit numbers in the range 0 through 3, can be configured. The driver assumes the serial port device name is /dev/wwvb%d (i.e., unit 1 at 127.127.4.1 opens the clock at /dev/wwvb1) and that the clock is configured for 9600-baud operation.

The fudge time1 parameter can be used to compensate for inherent latencies in the serial port hardware and operating system. The value, which defaults to zero, is in addition to the value programmed by the propagation switches on the receiver. The fudge value1 parameter can be used to specify the stratum of the clock in the same way described above for the WWV/WWVH clock 127.127.3.u. 127.127.5.u - Kinemetrics/TrueTime Timing Receivers

This driver can be used with at least two models of Kinemetrics/TrueTime Timing Receivers, the 468-DC MK III GOES Synchronized Clock and GPS-DC MK III GPS Synchronized Clock and very likely others in the same model family that use the same timecode formats. The clocks are connected via a serial port. Up to four units, with unit numbers in the range 0 through 3, can be configured. The driver assumes the serial port device name is /dev/goes%d (i.e., unit 1 at 127.127.5.1 opens the clock at /dev/goes1) and that the clock is configured for 9600-baud operation.

The fudge time1 parameter can be used to compensate for inherent latencies in the serial port hardware and operating system in the same way as described above for the WWVB clock 127.127.4.u. The fudge value1 parameter can be used to specify the stratum of the clock in the same way described above for the WWV/WWVH clock 127.127.3.u.