EN

Installation and Configuration

AEOS NTP process

AEOS and the Network Time Protocol process for
time synchronisation

Version 4 23-08-2018
Installation and Configuration | AEOS NTP process EN

Date Version Changes

23-08-2018 4 New layout.

21-08-2015 3 Change date and time settings (incl. screenshots) added.

14-09-2009 2 VM-ware screen shot added.

Manual version 4 2/18

Installation and Configuration | AEOS NTP process EN

Contents
1. WHAT IS NTP? 4

2. NTP PROCESS AND TIME SYNCHRONISATION 5

3. HOW THE NTP PROCESS WORKS 6

4. MONITORING THE NTP-STATUS ON AN AEPU. 7

5. TROUBLESHOOTING 8
5.1 NORMAL SITUATION: NTP IS SYNCHRONISED / SYNCHRONISING 8
5.2 PROBLEM: NTP DOES NOT SYNCHRONISE 8
5.3 PROBLEM: STRANGE BEHAVIOUR WHEN THE SERVER CLOCK IS MANUALLY CHANGED 10
5.4 HELPFUL COMMANDS ON AN XSCALE AEPU. 11
5.5 KNOWN PROBLEMS WHEN THE AEOS APPLICATION SERVER IS A WINDOWS SERVER 12
5.6 WHICH NTP SERVICE SHOULD WE USE? 14
5.7 STILL HAVING PROBLEMS 14
5.8 CHECK ROOT DISPERSION 15
5.9 IF THE ROOT SERVER IS WINDOWS TIME SERVICE 15
5.10 EXAMPLE 15
5.11 NTP AND VMWARE 16
5.12 CONCLUSIONS 16
5.13 FURTHER RESOURCES 17

Manual version 4 3/18

 Installation and Configuration | AEOS NTP process EN

1. What is NTP?
NTP (Network Time Protocol) is used to synchronise your system's time with an online server. This
is a very useful application, and should be installed on every network machine.
NTP can also be used to serve time for a network. For example a LAN consisting of Windows and
Linux machines can all synchronise to a single NTP server, saving bandwidth. For AEOS this
process is used to synchronise the AEPU time with the AEOS application server time.

Manual version 4 4/18

 Installation and Configuration | AEOS NTP process EN

2. NTP Process and time synchronisation

The NTP process is used to synchronise the time of AEpu and AEserver. This document gives some
more background information about the NTP process and some possibilities to monitor and debug
this process.
Here is described how the NTP process acts in combination with the new AEpu filesystem (FS2)
and AEOS version 2.0 or higher. For the ‘old’ filesystem (as used till AEOS version 1.6.3) it acts in
brief lines as here described.
More info on NTP time synchronisation can be found on
http://www.eecis.udel.edu/%7emills/exec.html

Manual version 4 5/18

 Installation and Configuration | AEOS NTP process EN

3. How the NTP Process works

The NTP process (Network Time Protocol) consists of a client (AEpu side) and a server process
(AEOS server). In addition, there may be interaction with the Windows Time service which is by
default running on a Windows platform. NTP uses UDP port 123. TCP is not used.
On the AEserver side: during setup, the Network Time Protocol service is installed and started on
the server. The configuration file is located in ../system32/drivers/etc. This service now serves as
the time server for the AEpus to synchronise to.
Note that the time server is not available immediately after starting; this is caused by the fact that
the NTP process is also a client to other NTP servers in the network. So the server also tries to
synchronise. When this is accomplished, the server as time server is available to the AEpus.
On the AEpu side, the NTP service is known as the NTP-daemon. It is started by the script
/etc/init.d/timeconfig during startup of the AEpu the scripts actually has two tasks:
• use the script ntpdate to synchronise/update the date and time with the AEOS server
• start the ntpd (NTP daemon) process which keeps the synchronisation active

Initially, the polling time of the client is 16 s, and as the time has become accurate, the polling
interval is gradually decreased to 1024 s. This already shows that NTP will not react instantly to
time changes caused by e.g. the user on the server (change the clock). The NTP daemon on the
AEpu is started with the g flag to allow for time jumps to be synchronised in steps.

NTP daemon
AEOS server

NTP daemon

NetworkTimeProtocol
service NTP daemon

Manual version 4 6/18

 Installation and Configuration | AEOS NTP process EN

4. Monitoring the NTP-status on an AEpu.

In normal operation, the status of the NTP process can be monitored as follows:
• On a 586 AEpu: use the command ntpstat at the prompt.
This will give a message which looks like:
synchronised to NTP server (10.1.17.108) at stratum 14
time correct to within 24 ms
polling server every 64 s
• On a XScale AEpu: use the command ntpq -p at the prompt.
This will give a message which looks like:
remote refid st t when poll reach delay offset jitter
=========================================================================
*aeosserver 10.1.8.10 3 u 40 1024 175 1.053 4770.61 152.853s
Explanation:
*aeosserver: connected with NTP process on the AEOSserver, the * means also that the time is
syncronised. When the * is not there then the NTP server is not good enough or not ready yet
to synchronise with.
refid: IP address NTP server
• On the server (in a DOS-box, in the directory \AEOS\utils) type ntptrace aepuname.
This will give the following message (in this case for AEpu with name aepu999):
C:\AEOS\utils>ntptrace aepu999
aepu999: stratum 14, offset 0.005996, synch distance 0.02357
aeosserver.nedap.local: stratum 13, offset 0.007370, synch distance 0.01141

ntptrace determines where a given Network Time Protocol (NTP) server gets its time from, and
follows the chain of NTP servers back to their master time source.
If given no arguments, it starts with localhost. On each line, the fields are (left to right):
• the host name (aepu999)
• the host stratum (stratum 14)
• the time offset between that host and the local host (as measured by ntptrace; this is
why it is not always zero for "localhost") (offset 0.005996)
• and the host synchronization distance (synch distance 0.02357)

The host stratum is a value which indicates the accuracy of the system. A client NTP process can
only synchronise to a server which has a next lower stratum. When the NTP daemon on the AEpu is
started, it has a stratum of 14 and it is specified that it can only synchronise with a server which
has a lower stratum then 13.
Explanation of the Stratum value:
0 : unspecified or unavailable
1 : primary reference (e.g., radio clock)
2-15 : secondary reference (via NTP or SNTP)
16-255 : reserved

Manual version 4 7/18

 Installation and Configuration | AEOS NTP process EN

5. Troubleshooting
5.1 Normal situation: NTP is synchronised / synchronising
During normal operating the NTP process is synchronised, ntpstat (on the AEpu) gives following
response:
• 586 AEpu
# ntpstat
synchronised to NTP server (10.1.16.221) at stratum 14
time correct to within 129 ms
polling server every 128 s
• XScale AEpu
# ntpq –p
remote refid st t when poll reach delay offset jitter
=========================================================================
*aeosserver 10.1.8.10 3 u 40 128 175 1.053 129.61 152.853s
Here you can see that the time difference between AEpu and NTP server is 129ms, and is still
synchronising (polling time is 128 sec, should go to 1024 sec).

5.2 Problem: NTP does not synchronise

The message: No suitable server available (NTP process stopped or still starting) is shown on the
AEpu.
If the timeconfig script is executed (during AEpu startup, from the commandline or from the
setdatetime script from the server) and there is no suitable timeserver available, the following is
shown as a response to the ntpdate command:
Problem: NTP does not synchronize

3 Nov 11:57:08 ntpdate[4373]: no server suitable for synchronisation found

In this case, ntpstat (on a 486 AEpu) will show:
# ntpstat
unsynchronised
time server re-starting
polling server every 16 s
ntpq –p (on a XScale AEpu) will show:
# ntpq –p
remote refid st t when poll reach delay offset jitter
=========================================================================
aeosserver 10.1.8.10 3 u 811 1024 175 1.053 129.61 458.853s

Because there’s no * before aeosserver, it’s connected to the NTP server but not (yet)
synchronised.
On the server side, ntptrace will show:
C:\AEOS\utils>ntptrace aepu999
aepu999: stratum 16, offset 0.007972, synch distance 0.00356
73.78.73.84: *Timeout*

Manual version 4 8/18

Installation and Configuration | AEOS NTP process EN

Also on the AEpu you can check if the NTP process can find the server specified:
• 586 AEpu
# /etc/init.d/timeconfig restart
tick = 10035
Looking for host aeosserver and service ntp
host found : aeosserver.nedap.local
14 Jun 11:31:01 ntpdate[8727]: no server suitable for synchronisation found
• XScale AEpu
Looking for host aeosserver and service ntp
host found : aeosserver.nedap.local
15 Feb 14:08:57 ntpdate[22529]: no server suitable for synchronisation found
Above two examples the host can be found, but no NTP process can be found there.
• 586 AEpu and XScale AEpu
# /etc/init.d/timeconfig restart
tick = 10035
Looking for host aeosserver and service ntp
host found : aeosserver.nedap.local
14 Jun 11:34:12 ntpdate[8767]: step time server 10.4.16.51 offset -12.614744 sec
Now above the NTP process can be found on the specified server.

Possible causes
• NTP process is not running on the server.
• NTP process is starting and the stratum (level of accuracy) is higher than that of the AEpu
(normally this is the case when the windows clock has been changed manually).
• There is no network connection between AEpu and server.
• There is a name resolving problem (AEpu and server have different names on different
platforms).

Solution
• start the NTP process.
• ping from both sides using IP address and hostname.
• wait, if the processes are running, it may take a long time before the time server has reached a
stratum 13 level.
• if the NTP time server is operating properly and the time process on an AEpu is restarted it
usually takes about 5 minutes before the synchronisation is effectuated (but it can also take a
lot longer to reach the correct time, depending on how the NTP processes synchronise).
• Sometimes the server has no correct behaviour if beside the NTP process also the Windows
Time process is active. Go to the Services of Windows at Stop the Windows Time process. (Set
also this service to Manual to prevent that after a reboot of the server this service is running
again.)
• For getting more information you can let the NTP process create a logfile by make a change at
the registry of the server and restart the NTP process. Go to
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\NetworkTimeProtocol and add to
the entry C:\WINDOWS\System32\ntpd.exe following string: –L C:\ntp.log . This will now
generate a logfile with information about the NTP process ( in this example at C:\).

Manual version 4 9/18

Installation and Configuration | AEOS NTP process EN

5.3 Problem: Strange behaviour when the server clock is manually

changed
If the server clock is given an offset of several minutes (when NTP processes are running) the NTP
process will react as follows:
• 586 AEpu
• ntptrace will show an offset between the local host and the AEpu
• the polling interval of ntpd on the AEpu will decrease to 16 seconds
• after several minutes, the ntpstat will show:
# ntpstat
synchronised to unspecified at stratum 14
time correct to within 34 ms
polling server every 16 s

• XScale AEpu
• ntpq -p will show an offset between the local host and the aepu
• the polling interval of ntpd on the AEpu will decrease to 16 seconds
• after several minutes, the ntpq -p will show:
# ntpq –p
remote refid st t when poll reach delay offset jitter
========================================================================
*aepsserver 10.1.8.10 3 u 811 16 377 1.087 53.623 98.750

Solution
• restart and initialise the AEpu time ( using setdatetime.bat or /etc/init.d/timeconfig restart)
• and wait for everything to synchronise.

Manual version 4 10/18

Installation and Configuration | AEOS NTP process EN

5.4 Helpful commands on an XScale AEpu.

Using the ntpq command with extensions can give you some additional information:
# ntpq command to start ntpq
ntpq> as command to check assigned IDs
ind assID status conf reach auth condition last_event cnt
===========================================================
1 40004 b614 yes yes none sys.peer reachable 1

ntpq> rv 40004 <40004> is processnumber off the above assID

status=b614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=w2kservera, srcport=123, dstadr=10.4.108.91, dstport=123,
leap=00, stratum=3, precision=-18, rootdelay=31.738,
rootdispersion=174.957, refid=10.1.8.10, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, ttl=0, offset=-0.384,
delay=0.910, dispersion=1.187, jitter=10.593,
reftime=cb6024a8.809f6230 Fri, Feb 15 2008 15:48:08.502,
org=cb6024c3.80f8c64f Fri, Feb 15 2008 15:48:35.503,
rec=cb6024c3.812fc265 Fri, Feb 15 2008 15:48:35.504,
xmt=cb6024c3.2e0817fc Fri, Feb 15 2008 15:48:35.179,
filtdelay= 0.91 1.19 1.37 2.02 2.03 3.17 1.09 1.20,
filtoffset= -0.38 -3.27 5.76 6.14 12.71 16.97 0.62 -98.13,
filtdisp= 0.02 1.01 1.97 2.96 3.93 4.91 20.27 35.63
ntpq> exit <exit> stops ntpq tracing
#
Here you can see all interesting info about the NTP process running on the AEpu. The dispersion is
referred to in chapter 5.8.

Manual version 4 11/18

Installation and Configuration | AEOS NTP process EN

5.5 Known problems when the AEOS application server is a

Windows server
Normally AEOS is installed with the reference implementation of the NTP protocol of the NTP
Project. This NTP implementation is installed as a Windows service (AEOS NTP) and default
enabled.
If AEOS is installed on a Microsoft Windows 2003 server service pack 1 (W2k3 server sp1) you
can run into some problems, because the Windows Time service, also known as the W32Time, is
installed as service and is also started at startup (since W2k3).
Normally the AEOS NTP service is started before the Windows Time server, but both are claiming
the default NTP port 123. At this moment you don’t see any error in one of the event logbooks.
Everything looks fine, because the AEOS NTP works fine and the AEpus synchronised, but the
Windows Time service is not working now and the server isn’t synchronised. When you start the
services the other way around, first the Windows Time service then the AEOS NTP, you get an error
event in one of the logbooks of the server, which says something like: the AEOS NTP cannot bind
to the NTP, because the NTP port is already bound or in use.
Also when a windows machine is not part of a domain, you have to disable windows internet time:
1. Click on the time/date the taskbar:

2. Click on Change date and time settings.

If the screen has only two tabs, then your windows system is part of a Domain and you don’t
have to do anything.

Manual version 4 12/18

Installation and Configuration | AEOS NTP process EN

3. Click on tab Internet Time.

4. Clear the Synchronize with Internet time server checkbox.

Manual version 4 13/18

Installation and Configuration | AEOS NTP process EN

5.6 Which NTP service should we use?

The above implies of course you never run both services at the same time. It depends on the
situation which service must be used. First of all it doesn’t matter which one you use, but if you
don’t need the Windows Time service, disable this service and prevent it from start up.
You only use the AEOS NTP service which can be configured with the normal documentation. But
in short if there is no NTP server in the network (inclusive internet) the AEOS service must be
configured using his local clock with a stratum of 12, this can be done in the ntp.conf which is
located in the etc. directory. But if there is an external NTP server on the network the AEOS NTP
service must be configured using the external NTP, in this way the server, where the AEOS NTP
service is installed (the AEOS server), is also synchronised.
But sometimes it is necessary to use the Windows Time, because some other services want to use
the Windows Time or even don’t start up when the Windows Time is disabled. For these situations
in old windows version it was possible to start the Windows Time, but with disabled client and
server functions. But unfortunately the new Windows Time service (since w2k3) keeps the default
port bound even without client and server functions enabled. There are now many different
situations possible, but the two most important situations are described below:
1. The AEOS server is a standalone server and you can’t use the AEOS NTP.
In this situation you must install the Windows Time service as server:
a. Stop and disable the AEOS NTP.
b. With regedit find the next key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders
\NtpServer
c. Set the next parameter:
Enabled = 1
d. Don't forget to restart the time service.
2. The AEOS server is a domain member and is synchronised by Domain Controller (DC) which is
not synchronised by an external NTP server.
Also in this situation the Windows Time service must be configured as server (see above).
Enabling the NTP server option on the Windows Time service is done because it is not easy to
set all AEpus to another NTP server than the AEOS-server and also prevents possible VLAN
problems.
If you want to connect Windows Time to an external NTP server see Further resources (5.13).

5.7 Still having problems

There is still an issue in both situations (using AEOS NTP or Windows Time service), especially
when the root NTP service is a W2k3 Windows Time service. The problem is that the root
dispersion may never be more than 1 second. A normal NTP server has a root dispersion of a few
milliseconds, but a default W2k3 sp1 Windows Time service has a default local clock dispersion of
10 seconds. So the root dispersion is the sum of local clock dispersion and the sync distance
between the server and the client, so in total the root dispersion is 10s +/- sync distance in
practice this is something like 10s +/- 10ms. Both the AEOS NTP and the NTP client on the AEpu
reject all root NTP servers which have a root dispersion of more than 1 second.
In other words, all root servers are rejected by the AEpu client and AEOS NTP service which have a
root dispersion of:
(local clock dispersion + sync distance) = root dispersion
root dispersion > 1 second

Manual version 4 14/18

Installation and Configuration | AEOS NTP process EN

5.8 Check root dispersion

The root dispersion can be checked by starting the ntp query command:
1. Start the ntpq command on a AEpu (/bin/ntpq):
• ntpq
• as
2. Find the correct peer and get the assid: - rv <assid>
3. Check the parameter rootdispersion, the value is in milliseconds.

5.9 If the root server is Windows Time service

To make the W2k3 Windows Time service more reliable you have to change the following register
parameters on the service Windows Time server:
1. With regedit find the next key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
2. Set the next parameters:
• LocalClockDispersion = 0
• Acceptable clock offset must be within a second, else linux NTP client rejects this clock)
• AnnounceFlags = 5
• Say that this clock is reliable
3. Don't forget to restart the time service.
4. To check if an AEpu is synchronised when the server:
Start putty connect to an AEpu:
/bin/ntpq –p
One of the peers (peer to your root) should start with the ‘*’ mark.
Always be patient, because synchronization is normally working after 15 minutes.

5.10 Example
When the domain controller is also the NTP-server (with Windows Time) without external clock
and AEOS is installed on another W2k3 sp1 as domain member which synchronises the time
(Windows Time) with the domain controller automatically (NT5DS).
1. On the Domain Controller the Windows Time service must be configured as:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config
LocalClockDispersion = 0
AnnounceFlags = 5
Don't forget to restart the time service.
2. On the AEOS server:
Stop and disable the AEOS NTP.
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
Enabled = 1
3. Don't forget to restart the time service.

Manual version 4 15/18

Installation and Configuration | AEOS NTP process EN

4. Restart all AEpus or restart the time service on each AEpu

Start putty and connect to an AEpu.
/etc/init.d/timeconfig restart
5. If you are sure the Domain Controller is always running, everything is okay, else you must do
step 1 for each windows 2003 sp1 server in the NTP path (all Windows Time services from
client to root): Last step is necessary if one of the other Windows Server 2003 machines
(check ntptrace for the path to the root) is becoming the root NTP server; this will happen
when the Domain Controller fails.

5.11 NTP and VMware

Special attention is needed if VMware is used.
At some VMware situations the clock synchronisation will be continuously changing, thus causing
troubles on the AEpus.
Check carefully the above hints if you are having problems under VMware. Sometimes the points
below can help:
• Change Timesynchronisation to NTP instead of Win32Time
• Add module RTC on VMware-host (to Time stabilisation on Windows guest)
When using VM ware make settings as below to achieve that the VM-ware session synchronises
with the VM-ware server (the server where these VM-ware sessions are running).

5.12 Conclusions
Never ever run two NTP services together and if the root NTP server is a W2k3 Windows Time
service external or internal always check the root dispersion on the AEpu. If the root dispersion is
much to high (always wait at least 15 min.) check how the Windows Time is configured and adjust
the parameters if necessary. Even if the Windows Time service is not the root service, be aware it
is possible that it can become the root service when the original root server fails.

Manual version 4 16/18

Installation and Configuration | AEOS NTP process EN

5.13 Further resources

NTP-protocol
http://www.ntp.org/

Register parameters from Windows Time on a Windows 2003 server

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/secur
ity/ws03mngd/26_s3wts.mspx

Setup Windows Time on a Windows 2003 server to connect to an external NTP server
http://support.microsoft.com/kb/816042

Manual version 4 17/18

Copyright
Copyright© Nedap 2018. All rights reserved. The information in
this document is subject to change without notice. Nedap AEOS is
a registered trademark of N.V. Nederlandsche Apparatenfabriek
“Nedap”. All other trademarks referenced belong to their
respective owners.

Disclaimer
Nedap has made every effort to ensure the accuracy of the
information contained in this document. However, Nedap makes
no representations or warranties whatsoever whether express or
implied as to the accuracy, correctness, currency, completeness
or fitness or suitability for any purpose of such information and
therefore disclaims to the maximum extent permitted by
applicable law any and all liability for any error, damage, loss,
injury or other consequence which may arise from use in any
manner of any information contained in this document. Nedap
makes no commitment to update or keep current the information
in this document and reserves the right to make improvements to
this document and/or the products described therein at any time
without notice.

Nedap Security Management

P.O. Box 103
NL - 7140 AC Groenlo
+31 (0)544 471 111
[email protected]
www.nedapsecurity.com