Need definition for fudge line in /etc/inet/ntp.conf file 1

[goldenradium2001]

Hi there, can anyone tell me exactly what the fudge line is for in the /etc/inet/ntp.conf file?

Thanks.

 

[Apricot]

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.


Setting up an NTP server

. 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 com-
# mand. 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

regards ph