Network Time Drifting

Articles and Tips: qna

01 Jan 2002

My NetWare 5.x tree has problems with time synchronization. Network time drifts backwards, and some servers are constantly dropping in and out of time synchronization. What can I do to fix this?

Adrift in Denver

Dear Adrift: There are several causes for these behaviors, but with proper configuration and the latest software updates, Novell believes virtually all problems with time synchronization can be fixed. To check your tree's time synchronization status, load the DSREPAIR utility on the Master of [Root] and run a Time Synchronization check from the first menu (this can take some time if you have a large tree).

When the time synchronization check is finished, look at the report. Ignore the Time Is In Sync column (yes/no)-- just look at the Time +/- column. If there are any values that are larger than 2, that server is out of synchronization. (This assumes the Master of [Root] is also the Single or Reference server of the tree; while this is not necessary, it is the most common setup.)

It is normal for time servers, especially Secondaries, to drift out of the standard 2 second time synchronization radius occasionally, but they should come back in within a few minutes. Run another Time Synchronization check after a while and see if they have come back into synchronization.

If you have a server or servers that never seem to get into time synchronization, follow all the tips below:

Apply the latest Support Pack updates. The relevant NetWare updates are nw50sp6a.exe, nw51sp2a.exe or nw51sp3.exe; wsock4f.exe; and the latest Timesync.nlm (5.24l at time of writing, but a newer one is expected shortly).
If your servers use any of the Intel 100-based LAN card drivers, such as hptx.lan, chptx.lan, e100.lan, n100.lan, or ce100b.lan, they must be updated to the ce100b.lan driver version 3.29 (7 Jan. 2001) or later from Intel, or equivalent from the other OEMs. All these cards are based on the same chipset and will work well with the Intel ce100b driver.
Once you have right software versions, you have to check the time synchronization configuration. You must have one and only one Reference or Single time server per tree. With TIMESYNC.NLM version 5.23 and later, there is no reference to the hardware clock any more, so your first decision is whether to run with the server's software clock as the tree reference or use an external NTP source.

NetWare and Directory Services (eDirectory) do not care which way you go on this, only that the tree is in sync with itself.

If you do use an external NTP source, you should only use one. There is no reason to use more for redundancy, as it does not matter if the Reference or Single loses contact with the NTP source intermittently, it will run fine until contact is re-established.

Having more than one time source means they can differ from each other, and TIMESYNC.NLM does not know what to do if they are different. The syntax for the NTP source in Configured Sources is simply:

xx.xx.xx.xx:123

where xx.xx.xx.xx is the IP address of the source. Do not use Domain Name Services (DNS) or Novell Directory Services names as address, as the TIMESYNC.NLM does not perform name resolution very well.

If you choose the Single Reference time server model, all other servers in the tree must be configured as Secondaries. They can be set to take time directly from the Single or another Secondary server as a Configured Source, or they can be set to use Service Advertising (SA). For SA to work, the server must be able to see SAPs (Service Advertising Protocols for IPX) or SLP (Service Location Protocol for IP) from the Single server.

If your connection is across a WAN link, it is best to use Configured Sources. Do not use the :123 suffix in a Configured Source; instead just use the IP address of the desired server.

If you choose the Reference/Primary model, there must be exactly one Reference and two or more Primary servers in your configuration. All Primary servers should have all other Primary servers and the Reference server listed in their Configured Sources (unless there are more than six Primary servers, then this configuration becomes unwieldy).
The Reference server should only list the NTP source as a Configured Source if there is one. If you are using the Reference server's software clock in lieu of an NTP source, the Configured Source should list all Primary servers instead. Never include a server's own address or the loopback address (127.0.0.1) as a Configured Source on any server.
If you have a mixed NetWare 4.x/NetWare 5.x tree, use only NetWare v5.x servers as the Single, Reference or Primary time servers; NetWare 4.x servers can get time from NetWare 5.x servers better than 5.x servers can from 4.x servers. NetWare 4.x servers should have the server name of the Configured Source you specify rather than the IP address, but NetWare 5.x servers should always use IP addresses.

If after trying all of the above tips you still get servers dropping in and out of time synchronization (the yo-yo effect), you can safely ignore this. As long as they come into synchronization as often as they drop out of synchronization (and reasonably soon), no harm will be done. Your problem may be the result of genuine network communications and TIMESYNC and NDS can cope with this just fine.

All that has been described above applies to NetWare servers only. Any other Operating Systems (OS) holding NDS replicas need to be set up to perform their own external time synchronizing. They cannot participate in the NetWare servers' time synchronization method.

Usually you can use the Operating System itself or a third-party utility to get time from the same NTP source as your Single or Reference server. If you are using a NetWare server's software clock as your tree reference, the other OS can be set to get its time from that NetWare server as an NTP source.

In theory TIMESYNC.NLM can act simultaneously as an NTP client and as an NTP source, but I suggest that if you are using an external NTP source, set the other Operating Systems to independently get time from the same external source where the NetWare server is getting its time.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.