Novell is now a part of Micro Focus

Time Synchronization in NetWare 4.x

Articles and Tips: article

STEPHEN WINN
Senior Software Engineer
NetWare Products Division

01 Nov 1993


This AppNote discusses time synchronization, a feature which provides a means of synchronizing time across NetWare 4.x servers. It can be configured to provide centralized control of network time, to allow synchronization with external time signals, and to compensate for PC clock drift. With proper planning and configuration, this feature can offer a stable, accurate, flexible means of time synchronization. This AppNote covers basic network time concepts and details the differences between the four types of time servers. It also gives configuration guidelines and some troubleshooting tips for diagnosing time-related problems.

Related AppNotes Apr 93 "An Introduction to NetWare Directory Services" Apr 93 "Planning a NetWare 4.0 Directory Tree"

Introduction

NetWare 4.x incorporates several new time-related features that form the basis for time synchronization. Most of these features are internal to the operating system and provide mechanisms to adjust and compensate for the rate of the software clock. In addition, the operating system provides support for Universal Time Coordinated (UTC) time, the worldwide time standard coordinated to the zero meridian (0E of longitude, also known as Greenwich Mean Time).

Time synchronization ensures that all servers in a Directory tree report the same time. Such synchronization is important because NetWare Directory Services (NDS) requires time stamps to establish the order of events and record real-world time values.

This AppNote first explains how time is calculated in NetWare. It then delves into time synchronization fundamentals, describes the different types of time servers, and illuminates some advanced time synchronization concepts. It offers guidelines for configuring the TIMESYNC NetWare Loadable Module (NLM), as well as for setting up time source servers and troubleshooting time-related problems. The information is directed toward administrators of multiserver NetWare 4.x networks.

Note: Throughout this document, the standard format used for times and time offsets is [+|-] HH:MM:SS. In practice, only the significant portion of the time need be specified (+7:0:0 is the same as 7). Also, though examples show the colon as a time separator, the actual character used as the time separator is determined by the country information for each server. In most instances in NetWare 4.x, input and output routines dealing with dates and times are language enabled to use the locally preferred format and characters.

Calculating Time in NetWare

To determine the "correct" time, two time-related features are highly visible and must be maintained on each NetWare server: time zone information and daylight savings time information.

Time Zone Information

Time zone information is provided by the time zone string maintained on each NetWare 4.x server. The time zone string provides three critical pieces of information that are used in the operating system and provided to NLMs running on the server:

  • The abbreviation for the local time zone name

  • The offset of the local time zone from UTC

  • The abbreviation for the local time zone name to be used during daylight savings time

To understand the format of the time zone string, look at the string required in Provo, Utah:

MST7MDT

The normal time zone abbreviation comes first (in this case "MST" for Mountain Standard Time). The actual characters and length are irrelevant, except that the abbreviation must not contain characters that indicate the start of the time zone offset (+, -, a colon, or a numeric character).

The daylight savings time abbreviation (in this case "MDT" for Mountain Daylight Time) is similar to the normal time zone abbreviation. However, it carries the added information that daylight savings time will be in effect at some time during the year. In many areas of the United States, clocks are advanced one hour during the summer for daylight savings. Other locations implement DST differently.

The time zone offset ("7" in the above example) is positioned immediately after the normal time zone abbreviation. In NetWare 4.x, it is implemented as a positive or negative offset in seconds. That is, the syntax is an optional plus or minus sign followed by an hour, minute, and second designation, as shown below:

[+|B]HH:MM:SS

Any unnecessary portion of the offset may be omitted. Thus, the seven-hour offset in our example could also have been written in any of these forms:

+07:00:00    07:0:0
+7:0:0       7:0:0
+7:0         7:0

When determining whether the sign on the offset should be plus or minus, remember this rule: the offset is the amount of time that must be added to convert normal local time to UTC time. As a formula:

UTC = local time + time zone offset

This calculation method was chosen so that the normal default in the United States (and generally any area west of zero meridian) does not require a minus sign. The minus sign applies in areas east of zero meridian. Thus, most European time zones require the use of the minus sign, indicating that UTC time is behind local time.

For developers, a significant difference between NetWare 4.x and earlier versions is that in NetWare 4.x the time zone string is actually used in time calculations. In previous versions of NetWare, the string could be set and changed, but it had no real effect. The CLIB NLM interpreted the time zone string when it loaded, but it ignored any changes made to the string after CLIB had initialized. In NetWare 4.x, the string is interpreted each time it is changed and it affects time calculations, including calls in CLIB.

Note: The normal time zone abbreviation is supplied to NLMs through CLIB as tzname[0] after a call to tzset.

The daylight savings time abbreviation is supplied to NLMs through CLIB as tzname[1] after a call to tzset. In addition, when the daylight savings time abbreviation is present, the variable daylight is true after the call to tzset. If the abbreviation is missing, daylight is false and tzname[1] should not be used.

Daylight Savings Time SET Parameters

NetWare 4.x supports information about daylight savings time for most of the world. The information is controlled by several SET parameters, as described in Figure 1.

Figure 1: SET parameters that control daylight savings time information in NetWare 4.x.


Parameter
Default
Explanation

SET Daylight Savings Time Offset=

+1:0:0

An offset, in seconds,added to local time at the beginning of daylight savings time. A change causes UTC to be recalculated from local time.

SET Start ofDaylight Savings Time=SET End of Daylight Savings Time=

None

Specifies datesor rules for dates when daylight savings time starts or ends.

SET Daylight Savings Time Status=

OFF. Can be On or Off.

The status may be changed at any time. Doing so does not change the local time, but it does causeUTC to be recalculated.

SET New Timewith Daylight Savings Time Status=

OFF. Can be On or Off.

This commandnot only changes the daylight savings timestatus but also adjusts the local time bythe daylight savings time offset. This effectivelyleaves UTC unchanged.

The preferred method of setting the daylight savings time status is through the use of the "SET Start of Daylight Savings Time=" and "SET End of Daylight Savings Time=" commands. These commands are placed in the AUTOEXEC.NCF file during system initialization, and they can be modified using a text editor if necessary.

Note that there are two ways to indicate when DST should start or end:

  • Specify an exact date (the change to daylight savings time only occurs once)

  • Specify a rule for calculating the dates (the operating system recalculates the next change and automatically schedules it for the next year)

See the NetWare documentation for more information about these SET commands.

When changing daylight savings time information manually on a server, be aware that you may cause UTC time to be recalculated from local time. The "SET New Time with Daylight Savings Time Status=" command is intended expressly to avoid the recalculation of UTC time and force local time to be recalculated instead. Use this command to change the daylight savings time status on a system that is otherwise correct and in time synchronization with the network.

Warning: Attempting to accomplish the same thing by changing local time and then changing the daylight savings time status will result in loss of time synchronization and will probably cause a significant synchronization problem.

Calculating UTC Time from Local Time

In general, whenever any time, time zone, or daylight savings time information is changed on a server, UTC time is recalculated from the then-current local time. Since local time can be set directly from the server console, the time calculation always assumes that local time is correct.

The relationship between local time information and UTC time is controlled by the following equation:

UTC = local time + time zone offset - daylight savings time offset

Note that the daylight savings time offset only applies when DST is in effect.

Changing any information on the right-hand side of this equation causes UTC time to be recalculated. When time synchronization is active, you should be extremely cautious about changing local time information! Time synchronization can actually work against your efforts to correct misconfigured local time. The proper way to reconfigure local time is explained later in the "Troubleshooting Time Synchronization Problems" section.

Displaying OS Time Information

If you need to see what the current UTC time, local time, time zone, and daylight savings time information are, they will be displayed on the server console in response to the TIME or SET TIME console commands.

Time Synchronization Fundamentals

Time synchronization attempts to maintain the same UTC time on all servers. Time synchronization deals only with UTC time on the server and does not directly employ any other operating system time information. However, changing UTC time does indirectly change local time in order to maintain the time relationships mentioned earlier:

UTC = local time + time zone offset - daylight savings time offset

Part of the installation process for time synchronization is the designation of one or more servers on the network as time sources. Time synchronization corrects the drift between the clocks in the time source servers in order to synchronize the UTC clock in each time source. UTC is then propagated to the rest of the network from the time sources.

Time synchronization does not attempt to provide correct time of day to the servers. It simply tries to keep the UTC clocks in synchronization. However, with proper management, time synchronization can be used to provide accurate time of day to all servers on the network. Depending upon the accuracy required, correct time of day may be fed into the network in several different ways, ranging from a network administrator checking the server time against a wristwatch, to attaching modems or radio clocks to set the time from national time signals.

Third-party products are available to update server time from external sources. Examples are listed at the end of this AppNote.

In the absence of external time signals, time synchronization will at least ensure that all servers on the network agree on a common time-within a configurable, predictable, maximum margin of error.

Why Is Time Synchronization Necessary?

Time synchronization was implemented in NetWare 4.x specifically to solve a problem faced by the Directory Services database. The database used by Directory Services is distributed around the network. When users or other objects are added to the Directory, the addition is first made in some local copy of the database. From there, it is propagated throughout the network to other copies of the database. If the same object is modified in two different local copies of the database, or modified twice in the same local copy, the order in which the modifications were made must be preserved to correctly propagate the changes. (Adding a user object and then deleting it has a different effect than deleting a user object and then adding it.)

One simple method to ensure the correct ordering of Directory events is to stamp each event with a time stamp derived from a common source. A time stamp is a unique code that identifies an event and associates it with a time. Time stamps are particularly important when NDS partitions are replicated. A user might delete an object and then re-create it, for example, and the Directory has to recall the proper order of those events. Otherwise, the Directory might try to create the object and then delete it.

While it would be possible to designate one server on the network as the source of all time stamps, such an arrangement would be impractical. Communication with that server might fail or be too slow to be effective. In addition, having only one source of time stamps would be counterproductive when the database itself is widely distributed.

A more practical method of obtaining time stamps is to simply use the time from the internal clock on a local server. UTC time is preferred for such time stamps, since it does not vary geographically. As we've seen, UTC time can be calculated from local time, given information about the local time zone and daylight savings time.

However, because it is difficult to set and maintain even local time accurately, there must be some communication between all servers on the network to periodically correct errors on individual servers. This is where time synchronization comes in. Time synchronization provides an automatic method of adjusting all of the clocks on the network so that each NetWare server can provide an accurate UTC time (and, as a side effect, provide accurate local time as well).

Even without the need to provide time stamps for Directory Services, it is useful to synchronize the time between all servers on the network. NetWare also includes date and time information when directories and files are created, modified, archived, and so on. Backup systems and other programs often rely on these times being accurate. In the past, maintaining the time on several servers has been a sort of administrative nightmare. In NetWare 4.x, time synchronization solves that problem.

How Does Time Synchronization Work?

Time synchronization operates by speeding up or slowing down the apparent tick rate of the hardware clock on each server. UTC time is maintained as a software clock that is updated during each hardware clock interrupt. On an IBM AT or clone, the hardware clock interrupts about 18 times a second, or approximately once every 55 milliseconds. So at each interrupt, 55 milliseconds is normally added to the UTC software clock. Time synchronization changes the apparent tick rate by adjusting the number of milliseconds added to the software clock.

A NetWare Loadable Module called TIMESYNC.NLM contains all of the time synchronization functionality. This module is automatically loaded whenever a NetWare 4.x server is booted. Time synchronization is active whenever the TIMESYNC NLM is loaded.

Every server on which time synchronization is active shares a fundamental synchronization algorithm, described in the following pseudocode:

loop forever /*a polling loop or polling interval*/
{
   Find a time source.

   Exchange time information with the time source.

   Adjust the time information to account for 
   transmission delays.

   Calculate the discrepancy between the local UTC clock 
   and that of the time source. 
  
   Modify the tick rate to correct this discrepancy
   during the next sleep interval (but do not ever cause 
   the clock to tick backwards). 
   
   Go to sleep for a while.
   
}

Types of Time Servers

Within the bounds of this algorithm, time synchronization may be configured in four different ways, leading to four types of servers:

  • Secondary

  • Primary

  • Reference

  • Single Reference

The function of Secondary servers is distinctly different from the function of Primary, Reference, and Single Reference servers. Consequently, the four server types are frequently divided into two groups and spoken of as either "secondary" servers or "primary" servers. Because of the dual use of the term primary server, it is preferable to use the term "time sources" to refer to the group of primary servers (Primary, Reference, and Single Reference servers).

Each time-synchronized server performs three fundamental functions:

  • Provide UTC time to any NLM or client workstation that requests it

  • Provide status information indicating whether the UTC time is synchronized

  • Adjust its internal clock rate to correct for drift and maintain UTC synchronization

When a server determines that its internal UTC clock is within a maximum error interval (called the synchronization radius) of what the time sources agree is network time, the server raises a synchronization flag in its status information. When this flag is raised (set to TRUE), the server is indicating that the internal UTC time qualifies to be exchanged as a time stamp with other servers on the network that also have their synchronization flags raised. This condition, known as being "network synchronized," provides a reasonable assurance that the UTC time on the server does not differ from the time on other synchronized servers by more than a predictable error.

Note: Keep in mind that time synchronization is a condition of long-term trust. Since information takes some time to propagate around the network and is only checked intermittently, there is no way to guarantee that the synchronization status on a server is correct at any given instant. However, over a long period of time (and barring outside interference), the synchronization status will be highly reliable. The net result is that applications requiring strictly synchronized time stamps must still allow for the possibility of error (outside the predicted maximum error) and provide ways to detect or recover from such errors.

Note that time synchronization is a passive activity on the network. Each server is responsible for its own synchronization. Servers are not told what time it is - they must ask. This makes installation and configuration of time synchronization much easier.

What Is the Difference Between Server Types?

As mentioned above, the four types of time servers can be generally classified as either secondary servers or time sources. Secondary servers and time sources differ in their intended use and in their method of synchronization.

  • Secondary servers obtain the time from one time source and remain synchronized with that time source at all times.

  • Time sources act as a group to determine the correct network time and to provide that time to secondary servers.

These distinctions affect the way in which the servers find a time source with which to synchronize and the way in which they correct their internal clocks.

Most time synchronization documentation describes the differences between server types by starting with Single Reference servers and ending with Secondary servers. However, the differences are easier to understand if presented in the opposite order. Keep in mind that each server type is a refinement of the previous type, and that there really isn't that much difference between the internal synchronization algorithm in any type.

Secondary Servers

Servers are Secondary servers by default, and most servers on a network will be Secondary servers. A Secondary server attempts to remain synchronized with (or "follow") one other server, normally a time source. Which time source it follows may be determined either through the use of NetWare's Service Advertising Protocol (SAP) or through custom configuration information.

When a Secondary server discovers a discrepancy between its time and the time it gets from the time source, it attempts to correct the entire error (100 percent adjustment) during the next polling interval. A Secondary server raises its own synchroni-zation flag when the error is less than the synchronization radius and the server it is following is also synchronized.

Primary Servers

Servers in the time source group are responsible for determining what the official network time is. To do this, every time source (Primary, Reference, or Single Reference) must contact all other time sources during each polling loop and calculate the average time reported by members of the group. In this respect, time sources differ from Secondary servers, which only contact one time source.

This is an important difference. When configuring the network, you need to remember that each time source must be able to reach every other time source. Time sources must not be cut off from one another through the use of restrictive routers, for example.

Primary servers in particular provide several services on the network:

  • They participate in voting to determine the correct network time and compensate for clock drift and errors. (Secondary servers do not participate in this voting.)

  • They provide a distributed source of official time across the network so that Secondary servers have local sources of time. This is especially useful on large networks to avoid unnecessary traffic on some LAN or WAN segments.

  • They provide redundancy on the network so that if one time source fails or becomes unavailable, alternative sources are available.

After polling all other time sources, a Primary server determines any discrepancy between its local clock and the calculated network time. The Primary server then adjusts its internal clock by one-half of the error (50 percent adjustment) during the next polling loop. If the total error is less than the synchronization radius, the server raises its synchronization flag (independently of the synchronization status of other servers).

The reason a Primary server corrects only one-half the calculated error during each polling loop is to avoid oscillations and ensure convergence. To understand this, consider the oversimplified case of only two primary servers, P1 and P2. P1 thinks that the correct time is 1:00 and server P2 thinks it is 2:00. If P1 and P2 polled each other nearly simultaneously, each would think that it was one hour in error - P1 one hour behind P2 and P2 one hour ahead of P1. If each applied a 100 percent correction during the next polling loop (P1 attempting to gain an hour and P2 attempting to lose an hour), they would have simply switched places at the end of that polling loop, with P1 now one hour ahead of P2. Thus endless oscillation might occur. By correcting only one-half the error during each polling loop, the servers converge to a common time rather than oscillating back and forth.

Knowledgeable or clever readers will see that this case is terribly contrived and that Primary servers wouldn't actually do what was just described. But don't get hung up on the details - it's enough to know that the oscillation problem exists and that the 50 percent correction serves to dampen the oscillation and aid convergence.

Reference Servers

If a network contains only Primary servers as time sources, a particular problem arises: it is very difficult to actually set the network time. Setting the time on any Primary server simply causes that server to believe that it is not synchronized to the network, and it will begin to correct the error.

Again, an oversimplified case will illustrate the point. Suppose servers P1 and P2 are synchronized at 1:00, and you manually set the time on P1 to 2:00. Server P1 then believes that it is out of synchronization and begins an attempt to lose time. Server P2, on the other hand, will conclude that it must gain time, and the two servers will try to converge to 1:30. In this respect, time synchronization actually fights your efforts to change time on any particular server.

The Reference server solves the problem of setting network time. A Reference server is simply a Primary server that refuses to adjust its clock. In fact, a Reference server acts just like a Primary server up to the point of adjusting the clock. It polls other time sources, calculates network time, and indicates synchronization status just like a Primary server, but then refuses to apply any adjustment to its internal clock. As a result, when the time is set on a Reference server, other time sources will be forced to converge to that time. The Reference server will not be pulled toward the other time sources.

Because a Reference server does not adjust its internal clock, it provides a point at which you can feed in an accurate time-of-day signal that will be propagated throughout the network. Commercial products such as radio clocks or modem devices may be used to set the time on a Reference server, with the assurance that the Reference server will not be caused to drift artificially by the time synchronization algorithm itself.

Important: Since Reference servers do not adjust their clocks, two Reference servers will never synchronize to each other.

The question is always asked, "Can there be two Reference servers on the network?" The simple answer is no. The truthful answer is that there can be, but some external force must synchronize each of them independently.

Single Reference Server

The next special case that arises is when there is only one time source on the network. (This would be the case for a small network with only one server, for example.) Since there are no other time sources to talk to, what type of server should it be? If it is a Secondary server, a Primary server, or a Reference server, it will not be able to raise its synchronization flag because there is no server that will confirm that its internal clock is correct.

Servers cannot unilaterally decide that they are synchronized just because they can't find a time source. Imagine the problems that would cause for applications such as Directory Services that require synchronized time stamps! If a server is not synchronized, it must not be able to lie about it simply because it has temporarily lost contact with other servers and could not discover that it was not synchronized.

The Single Reference server solves this problem. A Single Reference server is just a Reference server that has been given special permission to raise its synchronization flag. The Single Reference server has been told that there are no other time sources on the network that could possibly disagree with it. Hence, it is okay to assume that the Single Reference server is always synchronized to network time.

Important: It is incorrect to have a Single Reference server on a network if either a Primary or Reference server is also present. If this were the case, the Single Reference server has no way to report that it is out of synchronization with other time sources and it would be forced to lie.

To summarize, time sources differ from secondary servers in three key respects:

  • Time sources vote with all other time sources rather than just following one time source.

  • Time sources set their synchronization status based on their deviation from the calculated network time and without regard to the status of the other time sources they polled.

  • Time sources correct only one-half of the clock error during each polling loop.

The chart in Figure 2 lists what we have discussed so far about the different types of time servers.

Figure 2: Summary of time synchronization server types.


ServerType
TimeSource
Description
Gets TimeFrom
AdjustsClock
Gives TimeTo

Secondary

No

Default configuration (most servers will be Secondary servers)

Attempts only to remain synchronized with one time source

Does not participatein voting.

Single ReferenceorReferenceorPrimary

Yes(100%correction per polling interval)

Clients only

Primary

Yes

Polls all other time sources and votesto determine correct network time and compensatefor clock errors

Sets synchronization statusbased on its deviation from calculated network time,without regard to status of other time sources polled

Reference

Yes(50%correction per polling interval)

Secondary andclients

Reference

Yes

Justlike Primary, except that itdoes not adjust its internal clock

Provides a central point of time control for the entirenetwork

Hardware ClockorExternalSource

No

Primary,

Secondary,and clients

Single Reference

Yes

Just like Reference, except it hasbeen given special permission to always claimto be synchronized

Cannot coexist with Primary or Reference servers

Hardware ClockorExternalSource

No

Secondary and clients

Figure 3 shows an example of the recommended time synchronization setup for a medium-sized network. Note the use of a Reference server as the central point for setting time. The Primary servers and the Reference server poll each other to determine network time. The rest of the servers are Secondary servers that each follow a Primary server to remain time synchronized. (The intent here is to show physical wiring of the servers, not necessarily polling paths.)

Figure 3: Time synchronization setup in a medium-sized network using Reference, Primary, and Secondary servers.

Advanced Time Synchronization Concepts

By now, you should have a good feel for the fundamentals of time synchronization and be familiar with the four possible server configurations. This section presents some more advanced concepts pertaining to the server types, the network load generated by time synchronization traffic, and adding new servers in a time-synchronized network. Understanding these concepts will help you make better use of some time synchronization features.

Subtle Differences Between Server Types

Although time synchronization allows four different configurations for servers, the differences between them are small. Yet it is useful to understand three subtle differences between the various server types so you can properly configure servers on your network.

  • By default, time sources advertise their presence on the network using SAP.

    Secondary servers do not advertise their presence.

    (Through a custom configuration, you can disable the use of SAP for time synchronization-see below.)

  • Time sources will not allow themselves to follow Secondary servers. They consider this a configuration error and will reject any synchronization information received from a Secondary server.

    Secondary servers can be configured to follow other Secondary servers, even though this is not the ideal configuration (see below).

  • The hardware clock configuration option causes Reference and Single Reference servers to set the UTC software clock from their hardware clocks during each polling loop. (This is a sort of cheap substitute for an external time source when a radio clock or modem time source is not available.)

    Primary and Secondary servers set the hardware clock from the software clock during each polling loop.

With these differences in mind, the following points answer several "what if" questions about time synchronization.

Does a Primary server ever act like a Secondary?

Except for the fact that Secondary servers poll only one server and apply 100 percent error correction, they aren't that different from Primary servers. When Primary servers use SAP to announce their presence and find other time sources, they are unique and different from Secondary servers. But if service advertising is disabled and Primary servers are custom-configured, they are almost identical to Secondary servers. In fact, in this situation the main difference is in the eye of the beholder.

If a Primary server is never included in the polling algorithm of any other Primary server, it does not in fact participate in the determination of network time. It is functioning not as a Primary server, but as a Secondary server which happens to be using a 50 percent synchronization algorithm and can contact more than one server for information during each polling loop. In a sense, it is the way a server is treated by its peers that determines whether it is a Secondary server or a Primary server.

How do I disable the use of SAP by time sources on my network?

You can prevent time sources from advertising their presence by issuing the "SET TIMESYNC Service Advertising = Off" command. This requires custom configuration of all servers on the network. Use the "SET TIMESYNC Configured Sources = On" command to prevent any server type from listening to SAP information.

Can a Secondary server get time from another Secondary?

Even though the documentation implies that every Secondary server must follow a Primary server (or other time source), there is nothing wrong with having Secondary servers follow other Secondary servers - as long as you realize that the depth of the synchronization hierarchy determines the maximum error between any two nodes.

With Secondaries following Primaries, there is a maximum error of four times the synchronization radius. Since time synchronization is more closely related to the physical layout of a network than the logical Directory Services structure, there may be times when it is inconvenient to have a Secondary server follow a Primary server. There is nothing wrong with making the time synchronization "tree" a little deeper, as long as the maximum error is acceptable.

Can I have more than one Reference server?

On large national or international networks, there is nothing wrong with having more than one Reference server. In fact, for large networks it may be more practical to have several Reference servers that are each synchronized by radio or modem sources, rather than depending on time synchronization to do it across slow and heavily utilized WAN links. Just remember that the Reference servers must be synchronized by some external algorithm. They will not synchronize with each other.

Network Load Generated by Time Synchronization

Although network load information is not documented, it might be useful to know what kind of a network load is generated by time synchronization. The actual workload is controlled by the number of time exchanges during each polling loop, which is determined by the polling count parameter.

The default is to make three time exchanges which each involve an NCP send/receive pair, totalling 332 bytes of data. Thus, the default three exchanges involve six packets, totaling 996 bytes of data.

When time synchronization first begins, polling occurs every ten seconds, but then slowly backs off to every ten minutes. So the workload of about 1KB every ten seconds eventually stabilizes to 1KB every ten minutes. If these loads are too high, they can be adjusted by changing the polling count and polling interval parameters-as long as those adjustments don't cause problems maintaining synchronization.

There is nothing wrong with changing the polling interval to cut down on network traffic. The default polling interval (or "sleep for a while" period in the pseudocode) is ten minutes. But as long as the server clock is not drifting and synchronization is maintained, that polling interval may be extended.

In situations where perhaps dozens of Secondary servers would poll a single Primary server across a slow LAN or WAN segment, it may be helpful to increase the polling period to even one or two hours. This would cut back on the network traffic and probably have little or no effect on synchronization, unless the server clocks drifted by several seconds a day.

In actual fact, once a server has reached a stable state, the amount of network traffic attributed to time synchronization will probably be minuscule compared to the normal background traffic.

Adding New Servers

When adding a new server to an already synchronized network, time synchronization acts on two basic premises. First, it works from the notion that adding a server should not disrupt the network's time synchronization. Second, it assumes that if the new server's time doesn't agree with network time, the network time is more likely to be correct.

Therefore the first act of time synchronization (for any server type) is to set the server time to the time reported by the first time source contacted. This is true even for Reference and Single Reference servers that do not normally adjust their clocks.

When you bring up a server, make sure that time synchronizes properly, and, if necessary, reset the time on Reference and Single Reference servers manually. It is always a good idea to check the time after bringing up a server just to make sure that all the time parameters are set correctly and that time is synchronized.

Configuring Time Synchronization

The task of configuring time synchronization on your network may seem complex in light of the number of details you must consider and the amount of planning that is required before installation. In an effort to make the installation of NetWare 4.x as simple as possible, Novell established a default installation model that should suffice in many small networks.

However, the default installation is not necessarily the best, especially as the number of servers in the network increases. What may be simple and easy to maintain in a small business with only a few servers may be completely impractical and chaotic on a large network.

The following sections describe the default and custom configuration methods and give some of the pros and cons for each method. These should help you decide which configuration method is best for your network.

Default Configuration

The installation program for NetWare 4.x makes a very simple assumption about time synchronization. It assumes that time synchronization consists of two levels of servers. At the top level (the root of the Directory Services tree) is a Single Reference server. On the second level are Secondary servers, which synchronize to the Single Reference server.

This installation model was chosen for two reasons:

  • It is simple and it works.

  • It is the only model that is universally applicable and does not require reconfiguration of time synchronization as new servers are added to the network.

The default configuration relies on SAP to advertise the time source. No custom configuration information needs to be provided to any of the time servers, except that the type of the Single Reference server must be specified.

Below are some of the pros and cons of the default configuration.

Pros:

  • The default configuration is easy to understand and requires no advance planning.

  • There is no need to provide a configuration file.

  • Since the synchronization hierarchy has only two levels, synchronization error is minimized.

Cons:

  • The Single Reference server must be contacted by every other server on the network. This can lead to communication problems on networks with slow or over utilized LAN/WAN links.

  • The use of SAP means that an accidentally misconfigured server(advertising as a time source) can disrupt the network. Some of the Secondary servers may decide to synchronize to it rather than to the authorized Single Reference server.

  • With only one time source, there is a single point of failure.

Custom Configuration

Custom configuration is not difficult, but it does require some planning. Time synchronization may be reconfigured at any time. However, if you are configuring a large network, it makes sense to do the time synchronization configuration as part of the installation process, since you must configure each server individually.

Custom confIguration generally consists of determining which servers on the network will be time sources and which servers will follow which time source. Each server is then given a configuration file (TIMESYNC.CFG), listing the authorized time sources for that server along with other parameters.

The same configuration file can frequently be copied unchanged onto several servers. Many times the only change required is the order of the time sources. Secondary servers attempt to contact the time sources in the order listed, and stop as soon as any time source is reached. So, it is frequently the case that all the Secondary servers can have the same overall list of time sources and that groups of servers can share the same ordered list.

Below are some of the pros and cons of using the custom configuration method.

Pros:

  • You have complete control of the time synchronization hierarchy.

  • You can eliminate the potential problems caused by the use of SAP.

  • You can optimize the network traffic and distribute time sources around the network.

  • You can add robustness to the synchronization hierarchy by adding alternate time sources to be used in case of network failures.

Cons:

  • Customization requires careful planning, especially on a large network.

  • Adding new time sources generally requires that configuration files on several other servers be updated. (Remember a time source isn't really a time source until the other time sources include it in polling activities.)

Below is a checklist of the decisions you must make when performing a custom configuration:

  • Which servers will be time sources (Primary and Reference servers) and which will be Secondary servers?

  • Will time synchronization rely on SAP, a configured sources list, or a combination of the two?

In general, if you are going to use a custom configuration, you should probably eliminate the use of SAP altogether by using the SERVICE ADVERTISING = OFF and CONFIGURED SOURCES = ON parameters in the configuration file.

  • If servers will use a configured sources list, which servers will contact which time sources?

  • Which configuration parameters should be changed to optimize the traffic between servers? (This generally involves changing some combinations of the polling interval, the polling count, and the synchronization radius.)

  • Will more than one Reference server be required? If so, what external time sources will be used to synchronize the Reference servers?

  • If more than one Directory Services tree is on the same network, will the trees be time synchronized independently or together?

General Guidelines

When customizing time synchronization, the general approach is to create a hierarchical structure in which the time servers at the top level are closely synchronized, and servers at each lower level are synchronized to servers on the next level up. In this structure, which has more to do with the physical location of servers than the logical structure of the Directory tree, the maximum synchronization error between the top level and any lower level is directly proportional to the number of intervening levels. Errors build up as the number of levels increases.

The following suggestions may help you organize your time synchronization hierarchy:

  • Whenever possible, have Secondary servers synchronize to timesources - Primary, Reference, or Single Reference servers.

  • If Secondary servers must follow other Secondary servers, keep the depth of the tree as shallow as possible. The maximum error across the network increases as the tree grows deeper, and the goal is to make the maximum error as small as possible.

  • Keep the number of time sources as small as possible to keep network traffic low. Remember the number of packet exchanges between n servers is approximately n2 during each polling interval.

  • Use time sources to provide local access throughout the network. On a large network, the use of multiple time sources can reduce overall network traffic. Remember that by default each secondary server will exchange three time packets with a time source during each polling loop.

Configuration Parameters

Configuration information for time synchronization can be supplied from console SET parameters or from a configuration file. The default configuration file is named TIMESYNC.CFG, located in the SYS:SYSTEM directory.

In addition, if the TIMESYNC NLM is loaded manually or from an NCF file, command line arguments can be supplied that override parameters in the configuration file. For example, the configuration file overrides the "SET Default Time Server Type" parameter specified during operating system installation.

Note: The NetWare 4.x installation program does not check for or modify the configuration file. So, if a TIMESYNC.CFG file exists, it will continue to control time synchronization even if you reinstall the operating system.

The server type is determined in the following order:

  1. The default type is Secondary.

  2. The type specified in the "SET Default Time Server Type" command, if present, will override the normal default. (This command is typically used to set the time server type on the Single Reference Server during a default installation.)

  3. If a TIMESYNC.CFG file exists, the type specified in the configuration file is used.

  4. To override the configuration file setting, you can specify the server type as a parameter in the LOAD TIMESYNC command.

  5. You can change theserver type at any time by issuing the "SET TIMESYNC Type" command on a server.

For an explanation of all the time synchronization configuration parameters and related SET commands, refer to the NetWare documentation sections listed at the end of this AppNote.

Troubleshooting Time Synch Problems

The TIMESYNC NLM supports several hidden parameters that were implemented for debugging, testing, and fine tuning of the synchronization algorithm. These parameters were purposefully not mentioned in the NetWare documentation, partly because they may be eliminated or changed in future releases. However, they can be useful in determining whether time synchronization is functioning properly.

Debug Flag

The "Set Timesync Debug" flag enables screen output at various points in the code. The output appears on the system console screen and is not particularly well formatted. Some portions are language enabled and may be translated.

To enable this feature, enter the command as follows:

SET TIMESYNC Debug = 7

To disable it, issue the command again, only with a value of 0.

You can set the flag to other values than 7, but the results are not very useful since each bit in the value controls a group of messages or disables output altogether. The following messages (labeled A, B, and C for purposes of discussion only) illustrate the information provided by this flag.

Message A:

TIMESYNC: Polled sever Corp_Com
Weight = 1, OFFSET.H = FFFFFFFF OFFSET.L = F1F06723

In message A, the most useful pieces of information are the name of the server (Corp_Com) and the weight (normally 0, 1 or 16). If time synchronization cannot actually exchange information with the server or if out-of-range data is detected, the weight will be zero. Generally that means that the server is not up or is not reachable across the network.

The values for OFFSET.Hand OFFSET.L are the calculated deviation of this servers time from the target servers time. The values form a 64-bit signed number with an implied hexadecimal point separating the whole and fractional parts: FFFFFFFF.F1F06723. (This server is a fraction of a second ahead of Corp_Com.)

Another possibility that may occur is a weight of zero with non-zero offset values. This indicates that the synchronization data is out of range (one server is more than 10 years ahead of the other).

If message A does not appear at all, there are no time sources in this server's list. Either the configured time source list is empty, or no SAP time source can be found, or both. Of course, if you have disabled the use of SAP, the only possible cause is that the configured time source list is empty. You can check the state of the list by typing "SET TIMESYNC Time Source =" at the system console screen (note that the equals sign with no following parameter is required).

Message B:

Uniform Adjustment Requested = -0.0E0F98DD
Server type = 2

Message B shows the actual adjustment that will be applied to the clock during the next sleep period. It also lists the server type: 2=Secondary, 3=Primary, 4=Reference, 5=Single.

The adjustment value is hexadecimal, but the sign is displayed so that the magnitude of the adjustment is easier to understand. In this case, the value 0.0E0F98DD is significant: it is one tick, so this server is ahead of Corp_Com by one tick. (It is very common to see one tick or one-half tick errors that are caused by randomness between the two machines.)

When the adjustment is +0.00000000, the servers are in exact synchronization, which really means that no error can be detected by the algorithm. It is not uncommon to see this value stabilize at a very small negative value, such as -0.00000094, due to a small round-off error in the synchronization algorithm when slowing the clock. (An error of 0.00000094 is 34 nanoseconds, much smaller than the resolution of the clock and nothing to worry about.)

Message C:

Adjustment smaller than Correction Floor was ignored.

Message C is mentioned because it is quite common. It means that the clock adjustment is so small that it is being ignored. Actually, the parameter which determines the cutoff point is set to 1 millisecond by default. The parameter can be changed using the following undocumented command:

SET TIMESYNC Correction Floor = x

where x is a value in milliseconds. This value must always be less than the synchronization radius or else synchronization will be impossible.

This parameter is undocumented and hidden so that people won't change it. In actual experience, correcting errors until they fall below one millisecond seems to work well. The only reason to change this parameter would be to eliminate the correction for the one-tick jitter that sometimes occurs - and then only if an application were terribly sensitive to that amount of error correction over a ten-minute period.

Immediate Synchronization

Another hidden and undocumented SET parameter is the following:

SET TIMESYNC Immediate Synchronization = On

This is a trigger that simply awakens the synchronization process and causes it to start a polling loop. It automatically resets to off. This trigger is sometimes useful after the debug flag has been set to cause some screen output, rather than waiting for the process to awaken normally.

Note that using this SET parameter does not speed up synchronization in any way; it simply wakes the synchronization process immediately. Normally, the synchronization process will respond within two seconds. Occasionally there may be a delay of several seconds (10 or less) due to normal network overhead while attempting to reach the target server.

Time Fails to Synchronize

When time fails to synchronize, the most probable reason is that there are no reachable time sources. Check the configuration information to be sure it is correct. Make sure that the time sources are running and synchronized. Remember that a secondary server will not be synchronized until its time source is synchronized. If necessary, turn on the debug option and verify that the server is actually contacting a time source.

If the time has been set far ahead, time synchronization may take a long time. Remember that the server cannot move time backwards. So, for example, it takes at least two hours to lose two hours. Check the time to see if it is close to the correct time and adjust the clock manually, if necessary.

Warning: Setting time backwards is a very bad thing to do for most applications that require synchronized time stamps. Always set the DOS time before booting the server, just to make sure that the hardware clock has the correct time.

Remember that time synchronization requires routing information to make contact with the time source. Sometimes it takes a while for routing information to get to a server, especially when the server has just been booted. Even though time synchronization normally happens quickly, wait a minute or two before jumping to conclusions. Also, try the DISPLAY SERVERS console command to see if the target server is known to the router.

A rare condition exists when the only two time sources on a network are booted for the first time. Since the first action of any server is to find a time source and set its own clock, it is problematic which server will first set its clock from the other server (the first server polled sets the time). Once servers have synchronized, and as long as one time source remains active, other time sources can be shut down and rebooted. The booting server will set its time to the network time. Since one server remained in operation, that server is not attempting to set its clock, and the race condition does not exist.

Again, it is always a good idea to set the DOS time before booting a server to make sure that the hardware clock is correct and to minimize any possible time adjustment.

NDS "Time Not Synchronized" Error

NetWare Directory Services may report the following error:

Time_Not_Synchronized - Error 659 (FD6D)

Yet when users check the server's status with the TIME command, it reports that time is synchronized. What this error actually means is that Directory Services has received a time stamp that is older than information already in the Directory. The server time has probably been set backwards. This could result from a dead CMOS battery or the time being set wrong when the server was booted.

This error occurs mostly on small networks that use the default time synchronization configuration. Note that it is an NDS error, not a TIMESYNC.NLM error.

Correcting Local Time on a Server

Fortunately, once time information is correctly configured, there is little need to change it. When time synchronization is active, you need to be extremely cautious about changing local time information. If local time information is misconfigured while time synchronization is active, UTC time will also be incorrect. Time synchronization will attempt to adjust UTC time to correspond to network time, which will, in turn, control local time. Time synchronization may therefore fight efforts to correct misconfigured local parameters.

To avoid this problem, you have to unload the TIMESYNC NLM, configure the local time information correctly, and then reload the NLM.

Note: The TIMESYNC NLM is automatically loaded when the NetWare server is booted. However, in NetWare 4.01 it is not shipped as a separate module; therefore, if you unload TIMESYNC you won't be able to load it again. If you need a copy of the NLM as a separate module, contact Novell Technical Support at 1-800-NETWARE.

As an alternative to unloading TIMESYNC, use the following command after correctly setting the server time and creating a TIMESYNC.CFG configuration file:

SET TIMESYNC Restart = On

See the NetWare documentation for more information on the TIMESYNC.CFG file and SET commands related to time synchronization.

Summary

NetWare 4.x includes several new time-related features that form the basis for time synchronization. Time synchronization attempts to maintain the same UTC time on all servers. Time sources (Primary, Reference, and Single Reference servers) determine the official network time. Secondary servers attempt to stay synchronized with one other server, usually a time source.

The default configuration for time synchronization services is easy to understand and requires no advance planning. However, a custom configuration offers you complete control of the time synchronization hierarchy and allows you to eliminate potential problems associated with the use of SAP.

Additional References

Several sections in the NetWare 4.x product documentation contain additional information about time synchronization:

  • "Managing Network Time Synchronization" in Chapter 6 of Supervising the Network

  • The TIMESYNC entry and the "Time" section under the SET entry in Utilities Reference

Also refer to the Related AppNotes Apr 93 "An Introduction to NetWare Directory Services" Apr 93 "Planning a NetWare 4.0 Directory Tree"

Related Third-Party Products

C-Note's Cadence Network Time Synchronizer for NetWare uses a modem attached to either a workstation or a server to obtain the time from government-run time services such as the U.S. Naval Observatory. Cadence consists of an NLM for the server and a terminate-and-stay-resident program for the workstation. Once it is loaded, the NLM becomes part of the operating system and automatically maintains the correct time on the server. Cadence Plus is available for multiserver LANs. (Call 800- 849- 0090 for more information on Cadence.)

* 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.

© Copyright Micro Focus or one of its affiliates