2.13 NETWORK TIME PROTOCOL

The time synchronization part of the Time System refers to the specific implementation of the mechanism used by the local machine to keep aligned its own clock with respect to another clock (normally in a different machine) referred as its `time server'.

The time synchronization mechanism used within the VLT project is based on the Network Time Protocol (NTP). In this respect, CCS also provides the ntp module. For workstations this module introduces an application that periodically monitors the time synchronization status of the local clock (ntpLog). For LCUs ntp provides a VxWorks implementation of NTP, that is to say, the required source code to build an NTP daemon for VxWorks.

2.13.2 Basic Concepts

2.13.2.1 Time Synchronisation

The time reference is given by a time server available on the LAN. This time server is part of the Central Time Standard, and receives accurate timing information from the GPS satellite service. The Network Time Protocol is used to synchronize time between workstations with the UTC delivered by the time server.

The implementation of NTP is based on a server/client daemon process named xntpd. The daemon receives the network time from a time source and forwards time request made by other time clients.

Time is distributed using a set of NTP servers ordered in a hierarchical structure. Each level in the hierarchy is identified by a stratum indicating the distance to the reference time. Stratum 1 is the top of the hierarchy having a direct time source e.g. the GPS receiver. The following level of Stratum receives the time from an upper level and provides the time to a lower level, e.g. Stratum 2 receives time from Stratum 1 and provides time to Stratum 3. Inside the VLT project environment a very simple time distribution scheme is used: Stratum 1 is the GPS receiver, Stratum 2 are the Workstations, Stratum 3 are the LCU's. Stratum 16 is a special level used to indicate unsynchronized servers.

The NTP provides mechanisms to obtain the time from several time sources, but these features are presently not used into the VLT project.

Once the system clock is synchronized with the time server, standard Operating System subroutines will return UTC with a reasonable accuracy: ~ 10ms. However, applications shall never request time directly through the Operating System subroutines, but always use the routines provided by the CCS Time System (tims functions).

For more details on the NTP daemon please refer to the man-pages of xntpd(1M) and ntpq(1M). And for further information on NTP itself refer to RFC 1305 (http://sunsite.auc.dk/RFC/rfc/rfc1305.html).

The following sections explains how the time synchronization software is provided for any environment into the VLT project, how the NTP software is installed under several platforms (VxWorks, Solaris and HP-UX), how the NTP daemon is configured and how it could be verified run-time

2.13.3 Software Distribution

For LCUs the NTP daemon is automatically generated during the installation of CCS and afterwards it is loaded and started on the LCU from the ntp.boot file. The NTP source code (embedded into the ntp module) correspond to the public distribution of NTP version 3.1.

The CCS has been validated under the Tornado Operating System even though this version of ntp was made to supports VxWorks 5.2.

For HP machines (OS 10.20, 11.0) and SUN Workstations SUNOS 5.6) NTP it is part of the standard operating system software set and an easy-to-use interface is provided to configure and run it.

2.13.4 Installation

2.13.4.1 Installation on LCU

To get NTP working on an LCU what needs to be done is the configuration of the specific LCU. Since only LCUs not equipped with a TIM board might require time synchronization over NTP, you have to specify the usage of the ntp module via the LCU boot configuration tool: vccConfigLcu. From the panel of this tool the ntp module should be specified as a user module. In this way during booting of the LCU the corresponding actions will be taken in accordance on what is contained in the $VLTROOT/vw/bin/ntp.boot file.

· stack size of the ntpdate task (default value = 30000)

· timeout to wait for the ntpdate completion (seconds, default value = 10)

· priority of the NTP daemon (tNtpd task) (default value = 25)

· delay to wait for tNtpd internal initialization (seconds, default value = 10).

One of the first things that the ntpStart function does is to get the workstation time (by means of a remote `date' command) and set it as new time on the LCU. This assures that at the moment when the local time is set by the ntpdate task (by means of several NTP polls of the actual time from the time server) the local LCU time will be already near to that one in the host workstation. In this way, if the ntpdate fails to setup the time (for example, because the NTP daemon is not yet running on the WS) then the LCU's time will remains as it was first set and this should be almost OK (~2 second).

Afterwards, the LCU's NTP daemon will keep running also if the host daemon is not yet running. Finally when the host daemon would became available then the synchronization will be reached by the normal behavior of NTP. If the daemon on the ws host is available from the beginning after the LCU has boot, then the ntpdate should succeed and the time will be better aligned (~10ms) when the NTP daemon is spawned.

The above scheme will avoid problems when WS host and LCU are booted at the same time.

The installation of the ntp daemon over workstations requires some additional steps and special privileges.

Note: the ntp module must be loaded after the lcc module, because ntp registers with the message system.

2.13.4.2 Installation on HP-10.20, 11.0 and SUN-OS 5.6 Workstations

On these platforms, ntp is delivered as part of the operating system, and only configuration through the standard system tools is necessary. For a description of the configuration procedure, please refer to the "Combined OS installation manual" [20].

2.13.5 Configuration

2.13.5.1 Daemon Configuration

In both platforms, workstation and LCU, the configuration of the daemon is maintained in the ntp.conf file. Which is an ASCII file and its syntax description could be found into the xntpd man-page (see xntpd(1M)).

The file is read by the daemon at start-up and it defines the internet address of the time server for the local NTP daemon.

For workstations the location of the ntp.conf file is under the /etc directory. While for LCUs the location could be $BOOTHOME or $VLTDATA/config.

Over HP (HP_UX 10.x, 11.0) this file is automatically generated by the System Administration Manager (SAM) tool after the daemon has been configured through the interactive interface of SAM.

Over SUN machines the file is provided as part of the installation step explained in section 2.13.42. Over SUN see the installNtpBin man-page for further explanation.

The lcu part of the ntp module contains a template file for the configuration of the daemon running under VxWorks. The file is located into the lcu part of the module:

During the installation of the ntp module (normally done only once under the CCS standard installation) this template file is taken and modified so that the time server entry is completed with the actual IP address of the machine where the installation has been done. The modified template is then copied to:

This means that all the LCUs booting from the actual workstation will have the same time server (the one from where they boot).

If the requirements of an user are to have a time server different from where the LCU boots then the $VLTDATA/config/ntp.conf file should be edited accordingly. See xntpd(1) about the format of this file. Obviously this modification will affect all the LCUs actually booting from the host where the modification it's about to be done.

In this way, a unique configuration is defined for all the LCUs booting from the same workstation host.

However, the NTP source coded embedded into the VLT ntp module has been modified in such a way, that at start-up the daemon will not only search the configuration file under $VLTDATA/config, but first it will look for an ntp.conf file under the $BOOTHOME directory. In this way, for any LCU application that need a special configuration of the NTP daemon, then this could be possible by modifying the standard ntp.conf file, accordingly with the actual needs, and coping this file to the specific environment directory ($BOOTHOME).

2.13.5.2 Database Configuration

The following is a description of the point in order to help the user understand how it is used by the system.

· xntpd is the point name which contains following attributes:

version string containing current xntpd version

updated string containing last ntpLog update

distance round trip delay to server in sec

timssoffset vector holding the simulation time offset.

The xntpd database point is updated by the process ntpLog. ntpLog queries the xntpd daemon for synchronization information and sets the time mode accordingly, i.e. UTC when synchronized and Local when not.

In order to start the ntpLog process at start-up time of the RTAP environment the following entry must be present in the RtapEnvTable file of the environment:

2.13.6 Verification

At the time when the NTP daemon (xntpd) is already running then it's possible to check how the daemon is working polling its status with the ntpq tool. To do so from the UNIX prompt give the following command:

The "*" before the name of the primary server means that the current WS is synchronized.

Further information can be get using the same ntpq tool with the following parameters:

ntpLog Server process to log synchronization and update database point

ntpq Software tool to query the actual status of a local or remote NTP daemon.