Time
Services
User’s Manual
By
Roberto Alberdeston
Juan Vivanco
Dr.Zalewski
Real Time Systems
-
Introduction
The goal of this manual is to describe the services provided by our module, show the administrator how to setup the Time Server, and show the user how to configure his/her component to make use of our services.
-
Definitions
ATCS:
Air Traffic
Control System
NTP: Network Time Protocol
WCC: Wake up call. This is a signal sent by
the time server to a client indicating
that a specific action must be taken by the client.
GPS: Global Positioning Service
UTC: Coordinated Universal Time
WAN: Wide Area Network
LAN: Local Area Network
Daemon: A program that is not invoked
explicitly, but lies dormant waiting for some condition to occur.
Relative Time: a measured time period
Absolute Time: actual date time as measured by UTC
Sleep () – this is a server command. It is used
to make a client component “wait” or stop some processing for a period of time
Wakeup () - this is a server command. It is used
to make a client component exit a sleep or wait state.
Alarms – this are signals that are sent to the
client components when specific events are triggered. The alarm signal itself
might trigger another event.
-
References
1) Zalewski,
Janus, Air Traffic Control System Software Requirements Specification,
Dept. of Electrical and Computer Engineering University of Central Florida,
Revision 3, February 15, 1998
2) Stephen R.
Schach Classical and Object Oriented Software Engineering Mc-Graw Hill 1998 Fourth Edition
3) The official
NTP web site www.ntp.org
Installation
1)
Administrator’s Installation:
First, we need to go to http://www.eecis.udel.edu/~ntp/ and download the ntp-4.1.0 version for Solaris Operating Systems.
You need to login into your systems as root so you will have privileges to install the software plus any needed packages.
The file will be downloaded to the root directory and it could be run from there. The file needs to be uncompressed by using the command ‘tar’, and then run the executable file the program to be installed.
The configuration file is called /etc/ntp.conf. This is an ASCII file using the usual comment and white space conventions.
A working configuration file might look like this:
#Peer configuration for host whimsy
#(Expected to operate at stratum 2)
server rackety.udel.edu
server umdl.umd.edu
server lilben.tn.cornell.edu
driftfile /etc/ntp.drift
Servers must have permission granted otherwise the local time from the machine if an error is presented. There are public NTP servers that can be found at this site. These would be servers of stratum 2; if stratum 1 servers were needed; special permission from their administrators is required.
Out of the 3 servers, it will get the most accurate time of the three.
Local time daemon is located at sbin/ while NTP’s is at usr/local/bin
For this daemon to run automatically at booting time of the machine; we need to enable it at level 2 (in file sr2.d).
When configured using the server keyword, this host can receive synchronization from any of the listed servers, but can never provide synchronization to them. This host can provide synchronization to dependent clients, which do not have to be listed in the configuration file. Ntpd includes a monitoring feature.
Driftfile declaration: one of the things the NTP daemon does when it is first started is to compute the error in the intrinsic frequency of the clock on the computer it is running on. The driftfile declaration indicates to the daemon the name of a file where it may store the current value of the frequency error so that, if the daemon is stopped and restarted, it can reinitialize itself to the previous estimate and avoid the day’s worth of time it will take to recomputed the frequency estimate.
The nptd implements a traffic monitoring facility, which records the source address and a minimal amount of other information from each packet, which is received by the server. This feature is normally enabled, but can be disabled if desired using the configuration file entry:
#Disable monitoring feature
disable monitor
The recorded information can be displayed using ntpdc query program.
Debugging Check List:
If the ntpq or ntpdc programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:
1) Verify the etc/services file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.
2) Check the system log for ntpd messages about configuration errors, name-lookup failures or initialization problems.
3) Verify using ‘ping’ or other utility that packets actually do make the round trip between the client and server. Verify using nslookup or other utility that the DNS server names do exist and resolve to valid Internet addresses.
4) Using the ntpdc program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.
5) If both the sent and received counters do increment, but the ‘reach’ values in the pe billboard with ntpq continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the flash variable as discussed above and on the ntpq page.
6) If the ‘reach’ values in the ‘pe’ billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn’t happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server population.
7) If all else fails, see the FAQ and/or discussion briefings at Network Time Synchronization Project site mentioned at the beginning.
2) Client’s Installation:
All modules using the time services
should do the following to access our timeserver:
In the client
code of your module, do the following:
TYPE:
Org.omg.CORBA.ORB
orb = org.omg.CORBA.init(args,null);
-
This will initialize the ORB
THEN
TYPE:
Tracker.Time
timeService = Tracker.TimeHelper.bind(orb, “timeServer”);
- Bind to the Count
ObjectTracker.TimeHelper.bind
Command issued
by client : Wake up
Inputs: - a integer that represents the delay in
millisecond that client would wait before receiving wake up call.
Output:
It will cause a certain component to “wake up” from a waiting state.
Format:
Wakeup (delay)
Command
issued by client: Gettime
Inputs: - No required inputs
Output:
The function will return a long integer that represent the absolute time and
date. The integer looks like this:
20010423182345142
Format:
Gettime()
Command issued
by client: Convert
Inputs: - The received lon integer from the
gettime() function call.
Output:
- The output will be formatted version oof the long integer time number and it
will look like this:
2001:
04 : 23 : 18 : 23 :45 : 142
YEAR
: month : day : hour : min : sec : milsec
Format:
Gettime(long int TIME)
EXAMPLE: Client Program
package Tracker;
import java.io.*;
import java.util.*;
public class Client{
public static void main(String args[])
{
try{
System.out.println("Initializing the ORB");
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// Bind to the Count Object
System.out.println("Binding to Time Object");
Tracker.Time timeService = Tracker.TimeHelper.bind
(orb, "timeServer");
//get time from server
System.out.println(timeService.getTime());
} catch(org.omg.CORBA.SystemException e)
{ System.err.println("System Exception");
System.err.println(e);
}
}
}
Instructions on how to run the program:
1. Assume server is running on the remote machine
2. Compile idl file: idl2java Tracker.idl
(it creates Tracker directory with all files in it.)
3. Compile all files in Tracker directory, including client code:
javac *.java
4. Run client from upper directory as:
vbj Tracker.Client
The results will look as follows:
The time in long is 975689103707
Timing Diagram
Time Server Response NTP server response NTP Time Services Client request NTP Server Wake up Call
Time Server
Client
SYSTEM ARCHITECTURE