|
HP OpenVMS Systems Documentation |
|
The OpenVMS Frequently Asked Questions (FAQ)
4.1.1.2 Alpha hardware time-keeping details...4.1.1.2.1 Battery-Backed Watch (BB_WATCH) ChipThis is battery backed up hardware timing circuitry used to keep the correct time of year during rebooting, power failures, and system shutdown. This clock keeps track of date and time in 24 hour binary format.The BB_WATCH time is used to initialize the running system time during bootstrap, and the BB_WATCH time is read when the SET TIME command is issued with no parameters; when the running system time is reset to the value stored in the BB_WATCH. The running system time is written into the BB_WATCH when the SET TIME command is issued with a parameter. The specification for maximum clock drift in the Alpha hardware clock is 50 parts per million (ppm), that is less than ±0.000050 seconds of drift per second, less than ±0.000050 days of drift per day, or less than ±0.000050 years of drift per year, etc. (eg: An error of one second over a day-long interval is roughly 11ppm, or 1000000/(24*60*60).) Put another way, this is .005%, which is around 130 seconds per month or 26 minutes per year.
The software-maintained system time can drift more than this, primarily
due to other system activity. Typical causes of drift include extensive
high-IPL code (soft memory errors, heavy activity at device IPLs, etc)
that are causing the processing of the clock interrupts to be blocked.
Unlike the VAX, the Alpha hardware clock tracks the full date and time, not just the time of year. This means it is possible to boot from the CD-ROM media without entering the time at the CD-ROM bootstrap. (This provided that the time and date have been initialized, of course.)
IA-64 (Itanium) hardware time-keeping details to be added...
Because the VAX Time Of Year (TOY) has a resolution of 497 days, the VAX system time is stored using both the TOY and the OpenVMS VAX system image SYS.EXE. Because of the use of the combination of the TOY and SYS.EXE, you need to issue a SET TIME command (with the time parameter specified) at least once between January 1st and about April 11th of each year, and whenever you change system images (due to booting another OpenVMS VAX system, booting the standalone BACKUP image, an ECO that replaces SYS.EXE, etc). The SET TIME command (with the current time as a parameter) is automatically issued during various standard OpenVMS procedures such as SHUTDOWN, and it can also obviously be issued directly by a suitably privileged user. Issuing the SET TIME command (with a parameter) resets the value stored in the TOY, and (if necessary) also updates the portion of the time (the current year) saved in the SYS.EXE system image.
This VAX TOY limit is the reason why OpenVMS VAX installation kits and
standalone BACKUP explicitly prompt for the time during bootstrap, and
why the time value can "get weird" if the system crashes outside the
497 day window (if no SET TIME was issued to update the saved values),
and why the time value can "get weird" if a different
SYS$SYSTEM:SYS.EXE is used (alternate system disk, standalone BACKUP,
etc).
VAX systems maintain an interval clock, and a hardware clock. The VAX hardware clock is called the TOY ("Time Of Year") clock. The register associated with the clock is called the TODR ("Time Of Day Register"). The TOY clock---as used---stores time relative to January first of the current year, starting at at 00:00:00.00. It is a 100 Hz, 32-bit counter, incremented every 10ms, and thus has a capacity of circa 497 days. OpenVMS (on the VAX platform) stores system date information---and in particular, the current year---in the system image, SYS$SYSTEM:SYS.EXE. The TOY is used, in conjunction with the base date that is stored and retrieved from the system image, to initialize the interval clock value that is stored in EXE$GQ_SYSTIME. Once the interval clock is loaded into the running system as part of the system bootstrap, the system does not typically reference the TOY again, unless a SET TIME (with no parameters) is issued. The interval clock value is updated by a periodic IPL22 or IPL24 (depending on the specific implementation) interrupt. (When these interrupts are blocked as a result of the activity of higher-IPL code---such as extensive driver interrupt activity or a hardware error or a correctable (soft) memory error---the clock will "loose" time, and the time value reported to the user with appear to have slowed down.) When SET TIME is issued with no parameters, the TOY clock is loaded into the system clock; the running system clock is set to the time stored in the TOY clock. This assumes the TOY clock is more accurate than the system clock, as is normally the case.
On most (all?) VAX systems, the battery that is associated with the TOY
clock can be disconnected and replaced if (when) it fails---TOY clock
failures are quite commonly caused by a failed nickel-cadmium (NiCd) or
lithium battery, or by a failed Dallas chip.
To help keep more accurate system time or to keep your system clocks synchronized, TCP/IP Services NTP, DECnet-Plus DTSS (sometimes known as DECdtss), DCE DTS, and other techniques are commonly used. If you do not or cannot have IP access to one of the available time-base servers on the Internet, then you could use dial-up access to NIST or other authoritative site, or you can use a direct connection to a local authorative clock. There exists code around that processes the digital (ie: binary) format time that is available via a modem call into the NIST clock (the Automated Computer Telephone Service (ACTS) service), and code that grabs the time off a GPS receiver digital link, or a receiver (effectively a radio and a codec) that processes the time signals from radio stations WWV, WWVH, WWVB, or similar. Processing the serial or hardware time protocols often involves little more than reading from an EIA232 (RS232) serial line from the receiver, something that is possible from most any language. Information on correctly drifting the OpenVMS system clock to match the time-base time is available within the logic of at least one OpenVMS Freeware package. (See Section 4.3 for a few potential hardware options.) One example of acquring a time-base through local integrated hardware involves the IRIG time format (IRIG-A, -B, -G), a binary signal containing the current time in hours, minutes, seconds and days since the start of the current year. IRIG can also contain the time of day as the number of seconds since midnight. HP Custom Systems and third-party vendors have variously offered IRIG-based reader/generator modules for OpenVMS systems. One of the easiest approaches is a network-based GPS or other similar receiver. Basically, this is a network server box that provides an NTP server with the necessary hardware for external synchronization. In addition to the antenna and the receiver and processing components, these devices provide a network interface (NIC) and support for an NTP time server, and applications including the NTP support within TCP/IP Services and within various third-party IP stacks can then be used to synchronize with the the NTP information provided by time-base receivers. No other host software is required, and no host configuration steps and no host software beyond NTP are required. (See Section 4.3 for a few potential hardware options.) Differing time servers (DECnet-Plus DTSS, DCE DTS, NTP, etc) do not coexist particularly well, particularly if you try to use all these together on the same node. Please pick and use just one. (If needed, you can sometimes configure one package to acquire its timebase from another protocol, but one and only one time server package should have direct control over the management of and drifting of the local OpenVMS system time. In the specific case of DECnet-Plus DTSS, older product versions and versions V7.3 and later provide a provider module, a module which permits DTSS to acquire its time from NTP. For details on this, please see the comments in the module DTSS$NTP_PROVIDER.C.) Unlike DECnet-Plus, TCP/IP Services NTP is not capable of connecting to a time-base other than the network time base or the local system clock. Third-party and open source NTP implementations are available for OpenVMS, as well. Useful URLs:
4.3 External time-base hardware?Here are a few possibilities for providers of a GPS-based receiver with an embedded NTP server, strictly culled from the first few pages of a Google search. Availability, pricing, OpenVMS compatibility and other factors are not known. For a direct-connected (local, non-IP, non-NTP) link, there are serial options available. Google finds Spectracom Corporation has a NetClock that could be used here, based on a quick look---I do not know if there is OpenVMS host software, but that would be possible to write for the ASCII data stream that the device supports. (Such coding requires knowledge of serial I/O, character processing, and knowledge of the clock drift API mechanisms in OpenVMS---there exists Freeware tools that could be used to learn how to tie into the clock drifting mechanisms of OpenVMS.) http://www.spectracomcorp.com/
Information on, and experiences or recommendations for or against these
or other similar devices is welcome.
Your system time is skewed across your cluster members, and the cluster member performing the queue management tasks has a system time set later than the system time of the member running the batch job. This behaviour is most noticable when using SUBMIT/AFTER=TOMORROW and similar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such is often recommended as a way to avoid this. The combination time value specified should be larger than the maximum expected time skew. In the example shown, the maximum cluster clock skew is assumed less than 1:00.
You can also maintain your system times in better synchronization, with
available tools described in Section 4.2 and elsewhere.
Memory errors, hardware problems, or most anything operating at or above IPL 22 or IPL 24 (clock IPL is system family dependent; code executing at or above the clock IPL will block the processing of clock interrupts), can cause the loss of system time. Clock drift can also be caused by normal (thermal) clock variations and even by the expected level of clock drift. When clock interrupts are blocked as a result of the activity of high-IPL code---such as extensive driver interrupt activity or a hardware error or a correctable (soft) memory error---the clock will "loose" time, and the time value reported to the user with appear to have slowed down. Correctable memory errors can be a common cause of system time loss, in other words. Heavy PCI bus traffic can also cause lost time. One bug in this area involved the behaviour of certain graphics controllers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm 3D10T effectively stalling the PCI bus. See Section 5.16 for details on the ELSA GLoria Synergy controller, and make certain you have the current GRAPHICS ECO kit installed. Clock drift can also be (deliberately) caused by the activity of the DTSS or NTP packages.
Also see Section 4.1.1.2.1, Section 4.1.1, and Section 4.3.4.
You can resynchronize system time using DCL commands such as SET TIME and SET TIME/CLUSTER, but these commands can and obviously will cause the current system time to be set backwards when the specified time predates the current system time. This time-resetting operation can cause application problems, and can adversely effect applications using absolute timers, applications that assume time values will always be unique and ascending values, and applications. Setting the time backwards by values of even an hour has caused various run-time problems for applications and layered products. For this reason, this technique was not considered supported during the Year 2000 (Y2K) testing; a system or cluster reboot was strongly recommended as the correct means to avoid these problems. Application programmers are encouraged to use the time-related and TDF-related events that are available with the $set_system_event system service, and/or to use UTC or similar time, as these techniques can permit the application to better survive retrograde clock events. (There is an ECO to repair problems seen in the DECnet-Plus support for generating TDF events from DTSS, and this applies to V7.3 (expected to be in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and V7.3-2 (expected to be in ECO1 and later). Apply the most current DECnet-Plus ECO kits for these OpenVMS releases, for best TDF event support from DECnet-Plus.)
See Section 4.3.4 and Section 4.3.1.
With DECdts and TCP/IP Services NTP, the system time value is "drifted" (rather than changed), to avoid the obvious problems that would arise with "negative time changes". The same basic clock drifting technique is used by most (all?) time servers operating on OpenVMS, typically using the support for this provided directly within OpenVMS. An example of the technique used (on OpenVMS VAX) to drift the system time is the SETCLOCK tool on the OpenVMS Freeware. For information on the use of the EXE$GL_TIMEADJUST and EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see OpenVMS AXP Internal and Data Structures, located on page 348. For those areas which switch between daylight saving time (DST) and standard time, the time value is not drifted. The time is adjusted by the entire interval. This procedure is inherent in the definition of the switch between DST and standard time. (Do look at either not switching to daylight time, or (better) using UTC as your time-base, if this change-over is not feasible for your environment.)
See Section 4.3.4 and Section 4.3.3.
An NTP time provider provides its idea of the current time to NTP clients via the NTP protocol. Most systems are NTP clients, but... NTP has a heirarchy of layers, called strata. The further away from the actual NTP time source (Internet time servers are at stratum 1), the lower the strata (and the larger the number assigned the statum). NTP explicity configured at stratum one provides time to NTP operating at lower strata, and the provided time is acquired based on the local system time or via some locally-accessible external time source. NTP at other (lower) strata both receive time from higher strata and can provide time to lower strata, and automatically adjust the local stratum. The highest stratum is one, and the lowest available stratum is fifteen. The TCP/IP Services NTP package can operate at any stratum, and can be configured as a peer, as a client, or as a broadcast server. NTP can also provide time to a DECnet-Plus DTSS network, see Section 4.2. With TCP/IP Services V5.0 and later, the only supported reference clock is the LCL (local system clock). If your system has an excellent clock or if the system time is being controlled by some other time service or peripheral (such as DTSS services, GPS services, a cesium clock, a GPIB controller or other similar time-related peripheral), you can configure NTP to use the system clock as its reference source. This will mimic the master-clock functionality, and will configre NTP as a stratum 1 time server. To do this, enter the following commands in TCPIP$NTP.CONF:
For local-master functionality, the commands are very similiar. Use:
The difference between these two is the stratum, and the omission of the prefer keyword. Specifying a higher stratum allows the node to act as a backup NTP server, or potentially as the sole time server on an isolated network. The server will become active only when all other normal synchronization sources are unavailable. The use of "prefer" causes NTP to always use the specified clock as the time synchronization source. With the TCP/IP Services versions prior to V5.0, the NTP management is rather more primitive. To configure the local OpenVMS system from an NTP client to an NTP server (on TCP/IP Services versions prior to V5.0), add the following line to the sys$specific:[ucx$ntp]ucx$ntp.conf file:
Also, for TCP/IP Services prior to V5.0, see the NTP template file:
Note that NTP does not provide for a Daylight Saving Time (DST) switch-over, that switch must arise from the timezone rules on the local system and/or from the SYS$EXAMPLES:DAYLIGHT_SAVINGS procedure. (Further, there is a known bug in SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM in V7.3, please obtain the available ECO kit.) For current TCP/IP Services and related OpenVMS documentation, please see: 4.4 Managing Timezones, Timekeeping, UTC, and Daylight Saving Time?You will want to use the command procedure:
to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF settings, though it may or may not configure the TDF and the timezone rules needed or used by other software packages. Please do NOT directly invoke the following command procedures:
TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone support. Earlier versions use a TDF mechanism and timezone database that is internal to the TCP/IP Services package. Also on the earlier versions, the TDF must be manually configured within TCP/IP Services, in addition to the OpenVMS configuration of the TDF. DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone support, and displays its timezone prompts using UTC$TIME_SETUP.COM. Earlier versions use a TDF TDF mechanism, timezone database, and automatic switch-over that is internal to the DECnet-Plus package. Also on earlier versions, the TDF must be configured within the DECnet-Plus DECdtss package, in addition to the OpenVMS configuration of the TDF. Application code using HP C (formerly Compaq C, formerly DEC C) will use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS releases prior to V7.0, or when the preprocessor declaration _VMS_V6_SOURCE is declared. DCE DTS TDF management details to be determined. In OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx, etc), the TDF value is written to SYS$BASE_IMAGE.EXE. With OpenVMS Alpha V7.0 and later and with OpenVMS VAX V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DAT contains the TDF. This means that OpenVMS Alpha systems will need to have the TDF value reset manually---usually within SYSTARTUP_VMS.COM---on reboots prior to V7.0. During OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT to acquire the TDF for use in the system global cell EXE$GQ_TDF. This is done to ensure that the system boots with a valid TDF (a value which may be zero). The UTC system services get the TDF from this cell. These services, as well as the HP C RTL, must have a valid TDF. (Prior to OpenVMS V7.3, if either DECnet-Plus or DECnet/VAX Extensions is configured and run, the image DTSS$SET_TIMEZONE.EXE is invoked and can override the TDF and timezone rule settings from SYSINIT or from UTC$TIME_SETUP.COM--- this image runs even if DTSS is disabled. If the settings do not match (due to inconsistencies in timezone specification in UTC$TIME_SETUP.COM and NET$CONFIGURE.COM), DTSS will reset the values to match its definitions.) Prior to OpenVMS V7.3, daylight saving time (DST) switchover is handled automatically only when DCE DTS or DECnet-Plus DTSS is in use. In V7.3, OpenVMS can be configured to automatically switch over to daylight time, and also generates an event that interested applications can use to detect the switch-over between standard time and daylight time. The manual switchover between daylight time and standard time is correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure procedure.
If you switch the TDF or DST setting, you will also want to restart or reconfigure any time-sensitive applications (those not using the time differential factor (TDF) change event available in V7.3 and later). Examples of these applications can include the need to restart the NFS client and NTP. (In the case of NTP, will want to try to "drift" the time (see Section 4.2 and see Section 4.3.4), and will find that the DST switch-over will exceed the NTP-defined maximum threshold allowed for drifting. Hence the NTP restart is presently required.)
|