Problem on CS1K with NTP server

[kvepps]

I've read some past posts on problems with the date/time clock drift. I have a customer complaining about the drift of their clock. The CS1K is a Co-Res running Release 7.5. I decided to use a PC configured as an NTP server to reduce the drift problem. Since the system is Co-Res, I experimented with the NTP settings in the Linux Base screen under the Unified Communication Manager (UCM).

I configured a PC (Windows XP) to be an NTP server for the system since they do not have any Internet connections to it.

Because the CS1K is a Co-Res system, I configured in Linux Base the NTP server to be the Primary Server with the type of clock as external. I then entered the external IP address of my Windows PC acting as an NTP server. Once this is saved, I can update the time on the CS1K by clicking on the Sync Now and the system will access my NTP server and update successfully. However, when I change the time on the NTP server, the CS1K will never update. I used Wireshark to monitor the NTP information between the CS1K and NTP server. When I click on the Sync Now button, I see the CS1K IP address send an NTP client message to the NTP server requesting the time and the NTP server responds back. However, when the CS1K sends out an NTP packet on its own (after a minute or so) I see a multicast NTP message (224.0.1.1). It seems that the CS1K is sending out its time but never asks the NTP server for any updates.

Then I tried to set the NTP configuration in Linux Base to "Not a Clock Server" and entered the IP address of my NTP server. Using Wireshark, I now see the CS1K send an NTP client request to the NTP server on my network and the NTP server responds back with the updated date/time but the CS1K does not update the time (phones do not update). I have waited an hour to see if this would happen but it does not. When I click on Sync Now, the CS1K will update its date and time out to the phones.

What am I missing? With a Co-Res system, you are not allowed to set the NTP configuration in LD 117. Everything is done via the Linux Base.

Any help would be appreciated.

Thanks
Ken

 

[Firebird Scrambler]

Have you got patch MPLR 32442 fitted?

However, I found some info below that might be applicable

Call Server (CS) system time drifts on Release 6.00 Co-resident ( Co-Res ) System

Problem Description
On Co-RES systems, Linux Base provides system time for all elements including CS.
Linux Base time is the SW ( Software ) time, while it gets initial time from HW ( Hardware) clock (BIOS battery) on startup, then it continues to update system time according to its SW clock. The issue reported is, thatSW clock keeps drifting 30 seconds per day.

Problem Resolution
If internal clock type is used as it is configured now in the system, system time is synchronized with BIOS time initially and then updated continously according to SW clock.
If machine type is CPPM ,system time could be corrected by setting an appropriate offset on Ld (Load.) 117 in case of a drift on system time.

In Co-Res systems, Linux Base time provides the system time and overlay commands on Ld 117 to modify system time could not be used.
Thus, in case of drift in Linux Base time, Network Time Protocol needs to be used ( NTP ). Rather than using Linux Base time as an internal clock, an NTP server ( which could simply be a PC ) would provide correct time as an external time source. NTP could be configured via Base Manager > Date and time > NTP edit > Add a reliable external clock source IP address from edit page. After editing , when <Sync Now> button is pressed , time is received from NTP server and it is updated periodicallyafter that.

Though there is no available command on Linux Base to keep time accurate by setting an appropriate offset in case of drift,commands below could be used to display SW clock time,HW clock time ; synch SW clock to HW clock or HW clock to SW clock manually.
[spalav@cores ~]$ su
Password:
[root@cores spalav]#
[root@cores /] # find / -iname hwclock*
/usr/share/man/man8/hwclock.8.gz
/usr/sbin/hwclock
[root@cores /] # /usr/sbin/hwclock --------->prints HW clock time
18 Jun 2010 05:37:28 PM EEST -0.977187 seconds
[root@cores /] # date ---------> prints Linux Base (SW) clock time
Fri Jun 18 17:37:30 EEST 2010
[root@cores /] # /usr/sbin/hwclock --hctosys ---------> retrieves HW clock time and sets it to SW clock time
[root@cores /] # /usr/sbin/hwclock --systohc ---------> retrieves SW clock time and sets it to HW clock time

Date can be set with the command 'date MMDDhhmm' or 'date MMDDhhmmYYYY.ss'


All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[kvepps]

Discovered the problem is with the NTP server stability running on my Windows XP machine.

The path MPLR32442 is not for a Co-Res machine running 7.5. I verified this with Avaya.

Using Linux commands, I was able to determine the Linux system was not syncing to my NTP server. This was accomplished by using the ntpq utility which allows you to look at the ntp references configured in Linux. What I found was that the dispersion of my clock was varying too much for the Linux OS to consider it a usable NTP reference. Linux Base defaulted back to the internal Linux clock.

The following commands were issued in order as root user in Linux:

1. ntpq -p ' lists all NTP servers on the system. This listed the IP address of my NTP server (ip address is listed backwards) as well as the Linux Base NTP service.
2. ntpq ' executes the utility and gives you a ntpq> prompt
3. associations ' lists the association IDs of each of the peers (ntp servers)
4. rv assocID# ' issuing rv followed by the association ID listed in assocations above will read the variables (rv) associated with the particular peer or server. When I entered my Windows NTP server AssocID#, it showed that my dispersion was very high. The Linux base will not sync to a server if the dispersion is >10.

I am going to try a small commercial ntp server made by Masterclock (NTP100-OSC) to see if it will work on the system.

Thanks

 

[I2007]

You have a command in the SS called "timaadj". This is a script made by Avaya to adjust timedrift on servers not being able to sync to NTP.

If you use this command timeadj with the correction value of -60 would add 1 minute making the clock going faster every day. Setting it to 60 would slow the clock down by 1 minute. It's fairly safe to play around with the command in the linuxbase if you want to test it.

I2007