Synthetic time?

Well....sorta.

Unlike AD, eDirectory cares what time everyone in the Directory Tree thinks it is. Why? Well, transactional timestamps determine the order in which changes are applied. AD orders transactions based on a number of variables, many of which are of higher importance than time, and as a result, transactions can be applied out-of-order.

For example, suppose that at 10:01:34, administrator Bob removes Mary from the VPN group, and at 10:01:36 administrator Tom adds Emma to the VPN group, and Bob and Tom use different DCs (as they should be able to, in a true "multi-master" environment like AD *claims* to be), then it is possible that during replication of the change, Bob's change will "overwrite" Tom's. The result would be a VPN group that had neither Mary nor Emma (the reverse situation - Tom's change overwriting Bob's - is also a possibility, yielding a VPN group that has Emma and also still has Mary). AD's penchant for replicating entire objects rather than just the object deltas contributes to this problem - but the failure would have been avoided if AD had been built with a reliable and effective time synchronization.

By keeping all Directory Tree participants in time synchronization, eDirectory avoids such problems. No matter which eDirectory server in the Tree is the origination for an object change, the timestamp ensures that the changes are applied in proper order. eDirectory uses the standard NTP protocol for time sync, meaning that it can easily sync with *NIX environments.

Back to "synthetic time"....

Synthetic time is a self-defense measure employed by eDirectory when Tree participants are having trouble agreeing on what time it is. It's an unusual circumstance that is not generally seen in any but large/complex eDirectory Trees (like one the size of, say, CNN, or USPS), or Trees that have a lot of communication problems. Whenever the time disagreement exceeds a certain amount (usually about 10 minutes), the Tree will enter a synthetic time state and start trying to slowly get everyone to "slip" their time until the disagreement can be eliminated. Because of the disagreement, timestamping becomes less effective during synthetic time.

The fact that the woman you mention responded to "synthetic time" messages by turning off time sync instead of looking up the issue on Novell's extensive support website suggests that she is neither technical nor astute. It's akin to saying "My engine has problems? Well, I heard some knocking and banging but I just turned up the music on the radio. I don't understand how the engine could be having problems now!"

Just to add a bit, I recently did the blunder of issuing "Set Time hh/mm/yy" command in order to sync all my time sources to a time lag that has occured on the Network. Then I realised that Set Time is a leftover from NW 3.x days. Always use monitor - server parameter - time, or down the time source server and do it in bios. Best Practise and easiest to schedule when the user connections are minimal. Takes just a minute to boot back up normally.


Official Synthetic Time Problem Defn:

Problem:  The NetWare® server reports the following error:
Synthetic time is being issued on partition.
Possible Cause:  In NetWare 4 and later versions, synthetic time is issued at a server with the error DS- 4.63-12 if the server time is set backwards. The synthetic time is cycled every two minutes until the server time is later than the last modified time stamp.
Action:  Run DSREPAIR.
Click Advanced Options > Replica and Partition Operations, and then select the partition you want to update.

http://www.novell.com/documentation/nw51/index.html?page=/documentation/nw51/time_enu/data/hl5k6r0y.html

In these days of nearly-ubiquitous Internet connectivity, there's no reason not to use one of the Stratum 2 "free" NTP servers local to your area as the time source for your Single Reference or Reference time server (in a large network the Reference server acts as time source for the Primaries.)

Modern NetWare uses the industry-standard NTP protocol (port 123) in client/server mode (not peer mode like Windoze does - leave it to M$ to come up with a chatty way to synchronize time.)  Make sure your NetWare server can resolve DNS names, and use the DNS name of the NTP server or pool in your timesync time source configuration on your Single or Reference server, with :123 tacked onto the name.

Make sure your firewall allows the NetWare time source server to resolve DNS and to request TCP port 123 and recieve responses from those requests.

Be kind to the public time server provider, and set your timesync to request time once per hour (SET TIMESYNC POLLING INTERVAL = 3600)

That way, using a "real" time source, not only is your network's time accurate to the subsecond, but it also does not require you to muck around with manually adjusting time, or with rebooting your server(s) to set the hardware (BIOS) clock.

Note that if your BIOS clock is prone to drifting, if you have to reboot your time server, you should check the BIOS clock and set it so it's reasonably close to the correct date and time before letting it start up; that way there's less chance it will push the wrong time info to your network before it gets a chance to check with its public time source.

There was a definite problem with older NetWare versions where if the BIOS clock drifted, it would cause the server's time to drift, too.  I haven't seen that happen with modern NetWare.  The versions the Asker has (per his other Question) are of sufficient vintage to potentially have that problem.