NTPSYNC

Synopsis

NTPSYNC [/?] [/BYIP[+|-]] [/SRV_SUPERDOMAINS[+|-]] [/SRV_SELF[+|-]] [/IMPLICIT[+|-]] [/IP6ADDR[+|-]] [/CLIENTIP[+|-]] [/CLIENTPORT[+|-]] [/V[+|-]] [/N[+|-]] server

Description

The NTPSYNC command an NTP client that sends a query to the given server and waits for a response. It adjusts the kernel's system clock based upon the response.

NTPSYNC locates servers from the server string supplied in the normal way, using ntp as the service name, udp as the transport name, and 123 as the well-known port number.

NTPSYNC has the same NTP client as the NTPQRY command, and the latter can be used to diagnose any problems with NTPSYNC.

Note: NTPSYNC makes no attempt to autolocate an appropriate NTP time source. What time source to employ is a decision for the system administrator to make. The factors affecting such a decision are beyond the scope of this documentation, although it should be noted that some cable ISPs have been known to provide NTP time sources as close to their customers as at the Universal Broadband Routers right at the head-end of the cable connection.

Usage model

NTPSYNC is aimed at machines that have a permanent, always-on, connection to Internet, that can thus afford to query an NTP time source. It is designed to be run at regular intervals from a command scheduling service.

It is recommended that NTPSYNC be run once per day, otherwise time corrections can grow into the tens of seconds or even minutes. (As such, it is recommended that one use an NTP time source that will not be overburdened by receiving queries from hundreds of thousands of people once per day. Have consideration for the server operators in picking the server to use.)

NTPSYNC is for keeping the kernel's system clock synchronized to an NTP time source. It does not synchronize any hardware real-time clocks that may exist on a system.

Note: NTPSYNC only sets the kernel's system clock. IBM OS/2 will automatically copy this to the hardware real-time clock, because it assumes that it is running on PC hardware. TAU makes no assumptions about the existence of RTC hardware and so will not. You will need to run an additional utility to update hardware RTC(s) from the kernel system clock on TAU if you want the time from NTPSYNC to propagate to the hardware RTC(s).

NTPSYNC doesn't employ fancy algorithms for correcting a clock without regular access to an NTP time source. NTPSYNC is modelled on the basis that an NTP source is regularly, and cheaply, available — i.e. that NTP service is always on-line. There exist other packages, which do things such as synchronize the kernel clock to the CPU's TSC register (using NTP time sources only as a means of calibrating the update rate of the TSC register), employing such fancy algorithms for systems where NTP service is off-line, or expensive to query on a daily basis. That is not the design model of NTPSYNC.

Example RUN file

This is a RUN file invoking NTPSYNC that is suitable to be scheduled by RUNWHEN from the OS/2 Command Line Utilities version 2.2.

  program %APPS%\JdeBP\IU\bin\NTPSync.exe
  argument NTPSync
  argument /server:time.cableol.net.

RUNWHEN itself can be run as a service under RUNSVC from the OS/2 Command Line Utilities version 2.2. A RUN file for doing that, instructing RUNWHEN to invoke NTPSYNC via the NTPSync.RUN file in the service's configuration directory, every day at 23:00:00, would take the following form:

  chdir %_BOOT%:\Config\Services\%1
  program %APPS%\JdeBP\CLU\bin\RUNWHEN.exe
  argument RUNWHEN
  argument /WEEKDAY:
  argument /HOUR:23 /MINUTE:00 /SECOND:00	NTPSync.run

Command-specific options

/V
Enable verbose mode.
/N
Do everything apart from actually modify the system clock.

The Internet Utilities are © Copyright Jonathan de Boyne Pollard. "Moral" rights are asserted.