Search  | A-Z Directory  | Contacting People Faculty of Education
Melbourne Education The University of Melbourne
    Network Operations
ed-IT : Faculty of Education IT


Internet: Time Servers
Netware Servers

The prefered method of TIme Syncronization within ed-IT is NTP, the solutions below will be aimed at providing a clean NTP feed to the NDS EDFAC_TREE.
As we run NW4.11 and NW5.0, the notes will be for these versions.

If this seems new/alien I'd suggest you break open your manuals immediately and learn about timesync as it's essential to NDS operation. As all the changes that take place in your network get recorded the information must go to all replicas of your partitions. Each change has a timestamp. If a receiving server is not in sync time-wise your results are unpredictable.

You're finished when time is correct and stays correct *and* the command TIME states that "Time is synchronized to the net" on all servers.

Netware: Time Synchronization Solutions
Setting time on NW servers.

AUTOEXEC.NCF


# ------------------------------------------------------------------------
#             Melbourne Uni Netware 5 Server: "KRYPTON"
#             AUTOEXEC.NCF: Last Modified 18/4/2000
# ------------------------------------------------------------------------

# ---- Netware Settings --------------------------------------------------
SET TIME ZONE = EST-10ESUT
SET DAYLIGHT SAVINGS TIME OFFSET = 1:00:00
SET START OF DAYLIGHT SAVINGS TIME  = (OCTOBER SUNDAY LAST 2:00:00 AM)
SET END OF DAYLIGHT SAVINGS TIME = (MARCH SUNDAY LAST 2:00:00 AM)
SET TIMESYNC TYPE = SINGLE
SET DEFAULT TIME SERVER TYPE = SINGLE

LIST1: AUTOEXEC.NCF

GMT vs UTC
They're functionally the same. GMT is a time zone, UTC is a time value. The time in the GMT zone equals the value of UTC.

TIME
It is simple enough to set Time on the server (SET TIME...) and then unload and load your timesync.nlm (unload....load), answer yes to the question it asks you.


KRYPTON:time
  Time zone string: "EST-10ESUT"
  DST status:  ON
  DST start:   Sunday, October 28, 2001   2:00:00 am EST
  DST end:     Sunday, March 25, 2001   2:00:00 am ESUT
  Time synchronization is active.
  Time is synchronized to the network.
Friday, January 5, 2001   1:15:16 am UTC
Friday, January 5, 2001  12:15:16 pm ESUT
LIST2: TIME

If all fails simply perform a SET TIME on *all* servers. And after that a TIME RESET using MONITOR.NLM


KRYPTON:set time 10:30 am
LIST: SE TIME

TIMESYNC.NLM

Timesynch.NLM is the module which controls the time synchronization process.


	SET TIMESYNC DEBUG = 7
LIST: TIMESYNCH DEBUG

When you bring the server up and time does not synchronize, by default the timesync debug screen will load. This can be loaded manually by typing: (set timesync debug = 7) and turned off manually by typing (set timesync debug = 0), if setting it to 0 does not turn it off, set it to 7, then set it to 0 and it should be turned off.

TIMESYNC.CFG
The below recommended TIMESYNC.CFG file for a NW5 server, and should be placed in SYS:SYSTEM. For an explanation of these parameters, refer to your Netware manuals. Time can also be configured with SERVMAN.NLM.


# TimeSync.Cfg is now updated automatically,
# when changes are made on the System Console

# TIMESYNC Configuration Parameters 

Configured Sources =	ON
Directory Tree Mode =	ON
Hardware Clock =	ON
Polling Count =	3
Polling Interval =	600
Service Advertising =	ON
Synchronization Radius =	2000
Type =	SINGLE

# TIMESYNC Configured time source list 

TIME SOURCE = 128.250.151.40:123
TIME SOURCE = 128.250.3.11:123


LIST: TIMESYNC.CFG

 


SET TIMESYNC Directory Tree Mode = On 
SET TIMESYNC Configured Sources = On 
LIST: SET TIMESYNCH from console

"Type" defines what form of time server the machine is to be (single reference, ref, primary, secondary).

... However, you may choose to reconfigure the current 'primary' to a 'secondary' and a 'secondary' to a 'reference' and another 'secondary' to a 'primary' in this case. 'reference' servers do not adjust their time. So in the end everything is equal to it (except for other 'reference' servers ofcourse).

BTW you need at least two 'primary' and/or 'reference' server. An option is to have *one* 'single reference' and everything else a 'secondary'.

So, in short.

  • 'Reference' servers do not adjust their time. So please connect them to a reliable time source. Unless you like cleaning up from a time drop back to 1987 or so (eg BIOS time glitch).
  • A 'single reference' may only exist if other servers are all 'secondary'.
             SINGLE    <----- Internet -----   Reference
             /   \                                          
            /     \                                          
    Secondary   Secondary  
    
  • A 'primary' and/or 'reference' only work if there's at least one other of that kind.
        Primary Time Server    ------ WAN ------   Primary Time Server
             /   \                                       /   \
            /     \                                     /     \
    Secondary   Secondary                      Secondary   Secondary
    

Uniform Adjustment Requested:  -2.10CAA1CB
This server is configured as a SECONDARY
Sun Jan  7 02:13:30 2001
 *** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
          offset.h = FFFFFFFD  offset.l = FA79E2F5

Uniform Adjustment Requested:  -2.05861D0B
This server is configured as a SECONDARY
Sun Jan  7 02:23:23 2001
 *** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
          offset.h = FFFFFFFD  offset.l = FA97FE05

Uniform Adjustment Requested:  -2.056801FB
This server is configured as a SECONDARY
Sun Jan  7 02:33:16 2001
 *** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
          offset.h = FFFFFFFD  offset.l = FA986F55


HOW

  1. We explicitly "told" our SINGLE server (KRYPTON) to get the time from the reference server

    TIMESYNC Add Timesource = reference server
    TIMESYNC configured sources = on
    # TIMESYNC Configuration Parameters 
    
    Configured Sources =	ON
    Directory Tree Mode =	ON
    Hardware Clock =	ON
    Polling Count =	3
    Polling Interval =	600
    Service Advertising =	ON
    Synchronization Radius =	2000
    Type =	SINGLE
    
    # TIMESYNC Configured time source list for KRYPTON 
    
    TIME SOURCE = 128.250.151.40:123
    TIME SOURCE = 128.250.3.11:123
    
  2. SAP time-broadcast on the reference server are not used, if you are running a Netware rather than UNIX refernce server use ...

    TIMESYNC Service Advertising = off

    Why????? The SAP-broadcast of the reference server will be lost before it was picked up by the primary servers. By forcing the primary servers to get the time from our reference server SAP is not needed (at least for the communication between the reference and primary servers). [Win95 IPX machines really stuff up SAP on the network]

  3. Secondary local on the WAN (CHAOS, HELIUM, COSMOS)
    # TIMESYNC Configuration Parameters 
    
    Configured Sources =	OFF
    Directory Tree Mode =	ON
    Hardware Clock =	ON
    Polling Count =	3
    Polling Interval =	10
    Service Advertising =	ON
    Synchronization Radius =	2000
    Type =	SECONDARY
    
    # TIMESYNC Configured time source list for HELIUM 
    
    TIME SOURCE = 128.250.151.21
    TIME SOURCE = .KRYPTON.EDFAC
    
  4. Secondary remote on the WAN (ARGON)
    Configured Sources =	ON
    Directory Tree Mode =	ON
    Hardware Clock =	OFF
    Polling Count =	3
    Polling Interval =	600
    Service Advertising =	OFF
    Synchronization Radius =	4000
    Type =	SECONDARY
    
    # TIMESYNC Configured time source list 
    
    TIME SOURCE = 128.250.151.21
    TIME SOURCE = .KRYPTON.EDFAC
    TIME SOURCE = NTP.EDFAC.UNIMELB.EDU.AU
    

"Synthetic time is being issued..." messages at the console
When you modify an NDS object the object is time stamped. If you change the time backwards on your network, you will see that you get synthetic time being issued on partition <some name>. This message is displayed every 2 minutes while time synch tries to close the gap. If the gap is too large you will need to use DSRepair using the -a switch.


Can someone define EPOCH for me?
Epoch is the time base of the system. NDS keeps messages in order by timestamp, and needs to so that an old message is recognized as having likely inaccurate information compared to recent messages and hence should be discarded.

Using DSREPAIR to "declare a new epoch" means in practice to stop, wait for the declarer to say The time a the tone will be ..., and then let servers progress from that point forward. Those servers ahead of the time hack are obliged to forget and then relearn information based on the announced time. One does not want to "declare" frequently because it is a serious disruption to NDS synchronization activities, but when we need it we really need it.

The common mistake on epoch things is let a server get days or years ahead of the tree. Oh boy, that's serious stuff. Ditto in the other direction. So we always check the time when rebooting a server and only after that check do we let the machine start server.exe. The smarter the system manager the more often time/dates are set wildly wrong, an observed situation based on not wanting to follow directions.

MONITOR.NLM

Within MONITOR.NLM (Monitor replaces Servman in NW5) there's an option to ADJUST time.

If all fails simply perform a SET TIME on *all* servers. And after that a TIME RESET using MONITOR.NLM

It may not be recommended by some but up to now this has worked for me.

Time settings in NW5 Monitor FIG1: MONITOR.NLM - Time settings in NW5 Monitor
Server Parameters>Time


[australia-tasmania]
time-zone-name = EST
time-zone-full-name = Australia/Tasmania
time-zone-offset = -10:00
dst-name = none

[australia-queensland]
time-zone-name = EST
time-zone-full-name = Australia/Queensland
time-zone-offset = -10:00
dst-rule = none

[australia-north]
time-zone-name = CST
time-zone-full-name = Australia/North
time-zone-offset = -9:30
dst-rule = none

[australia-west]
time-zone-name = WST
time-zone-full-name = Australia/West
time-zone-offset = -8:00
dst-rule = none

[australia-south]
time-zone-name = CST
time-zone-full-name = Australia/South
time-zone-offset = -9:30
dst-name = none

	

DSREPAIR.NLM

Troubleshooting: Run DSRepair Report Synchronization Status. If servers are out of sync this needs to be corrected - in some cases it may be caused by a communications problem between servers. Also check that network time server configurations are appropriate. See TIDs 2930686, 2908867, and 2918511 for excellent information on this. Run unattended repairs on servers with master replicas of user partitions. Make sure your DS.NLM versions are current.

/****************************************************************************/
Netware 5.00 Directory Services Repair 5.21 , DS 7.44
Log file for server ".KRYPTON.EDFAC" in tree "EDFAC_TREE"
Start:  Friday, September 8, 2000  11:34:29 am Local Time
Retrieve replica status

Partition: .[Root].
  Replica: .HELIUM.EDFAC                    9-08-2000 11:30:12
  Replica: .CHAOS.EDFAC                     9-08-2000 11:33:46
  Replica: .KRYPTON.EDFAC                   9-08-2000 11:32:32
  Replica: .ARGON.EDFAC                     9-08-2000 11:31:01
  Replica: .COSMOS.EDFAC                    9-08-2000 11:28:54
All servers synchronized up to time:          9-08-2000 11:28:54  

*** END ***

/****************************************************************************/
Netware 5.00 Directory Services Repair 5.21 , DS 7.44
Log file for server ".KRYPTON.EDFAC" in tree "EDFAC_TREE"
Time synchronization and server status information
Start:  Friday, January 5, 2001  12:17:44 pm Local Time

                            DS.NLM    Replica   Time        Time is     Time
Server name                 Version   Depth     Source      in sync      +/-
---------------------------+---------+---------+-----------+--------+-------
.HELIUM.EDFAC                 7.44      0       Secondary   Yes          + 1
.CHAOS.EDFAC                  6.09      0       Secondary   Yes            0
.KRYPTON.EDFAC                7.44      0       Single      Yes            0
.ARGON.EDFAC                  7.44      0       Secondary   No       + 71:02
.COSMOS.EDFAC                 7.44      0       Secondary   Yes            0

*** END ***
LIST4: DSREPAIR.NLM (SYS:SYSTEM\DSREPAIR.LOG)

Older Methods
For pre-NW5 boxes.

RDATE
RDATE uses the RFC 868 "Time protocol" (port 37), NOT the RFC 867 "Daytime protocol" (port 13), so port 37 must be available for you to use RDATE.
Here is a rdate.ncf command files, just for reference:


load rdate.nlm /q /u /p 60 n.n.n.n n.n.n.n n.n.n.n

LIST3: RDATE.NCF

Translation: /q be quiet, /u use UDP rather than TCP, /p 60 poll every 60 minutes, and try one of the three addresses which follow.

RDATE2: RDATE2

The NetWare time sync client RDATE has been simplified and is available with source as RDATE2. A NetWare time sync *daemon* is also available. A complete package of the three is included here.

 

Time synchronization has been lost
Time synchronization has been lost after XXXXX successful polling loops.


 6-09-2001   8:46:13 am:    TIMESYNC-5.15-62
     Time synchronization has been lost after 8565 successful polling loops.


 6-09-2001   8:46:22 am:    TIMESYNC-5.15-63
     Time synchronization has been established.


 6-10-2001   6:56:59 am:    TIMESYNC-5.15-62
     Time synchronization has been lost after 8038 successful polling loops.


 6-10-2001   6:57:08 am:    TIMESYNC-5.15-63
     Time synchronization has been established.
LIST4: Errors from the console of HELIUM.

TIMESYNC-X-72: Time synchronization has been lost after number successful polling loops.

Source: TIMESYNC.NLM

Explanation: Time synchronization was lost for some unexplained reason. This is normally not a problem and the system will reestablish synchronization. However, if the problem occurs frequently, the system may have a hardware or network problem.

Action: Try the following:

Check for recent time changes or configuration changes that may have caused this problem. Check the Synchronization Radius parameter and make sure it is not unreasonably small. A practical limit is 1000 milliseconds (1 second). The system might be experiencing a hardware or network problem. See Troubleshooting in the online documentation.

http://www.novell.com/documentation/lg/nw5/usreflib/sysmsenu/data/hs3clxsy.html

 

Documents
Documents, White Papers, Links and Resources.

Time Synchronization Solutions Guide
http://www.connectotel.com/netware/timesg.html

Email thread on NetWare & Time Synchronization
nov-tim1.txt
nov-tim2.txt

Time Synchronization
http://www.circa.ufl.edu/netware/timesync.html

Novell Technical Information Documents
Time Synchronization White Paper (doc# 10020147)
doc # 2930686
SFT III Time Not in Synch With the Network (doc# 2926308)

Novell AppNote- "Using Network Time Protocol (NTP) with NetWare 5", © Jul 99
Using NTP with NetWare

Time Synchronization Solutions Guide for NetWare (24 Oct 95)
Novel-guide.txt

Understanding Time Synchronization in NDS
Caldera NetWare for Linux
Introduction to NDS
Restricted access: http://docs.edfac.unimelb.edu.au/ndsdesc/06.htm
http://www.bmends.bme.hu/documentation/ndsdesc/06.htm

 [ Top of the Page ] [ Staff homepage ][ Student homepage ][ Visitor homepage ]
[ Home ]ed-IT Network Operations Home Page.


The University of Melbourne ABN: 84 002 705 224
© The University of Melbourne 1994-2002. Disclaimer and Copyright Information.
* Please note - University of Melbourne makes no endorsement of external companies or products
but provides this information 'as is' as a possible service to staff and students

Last Reviewed: 13-Jun-2001 by Darren Robertson

Current Date: Saturday, 04-Jul-2009 22:56:38 EST
Last Updated: Wednesday, 13-Jun-2001 16:04:29 EST

Contents by: Darren Robertson
Maintained by: Darren Robertson Operations Manager, IT.
Authorised by: Darren Robertson Operations Manager, IT.