Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CPPM CS time drift (delta)

Status
Not open for further replies.

one234

IS-IT--Management
Mar 8, 2003
728
GB
Hello All,

I upgraded a Release 4.5 system to a release 7.5 system 2 weeks ago. After the upgrade the time in CPPM CS is drifting very fast. More then 30 minutes a day. I've setup NTP in the call server and it should be syncing the time. I've changed the sync interval from daily to hourly so the thresholds shouldn't stop the sync.

But what I find weird is that we can see the time drift. When I do TTAD in LD 2 just after the NTP sync it's already a few seconds behind. And the difference is getting bigger by the minute.

Does somebody know where to look for this problem? I've upgraded multiple systems (Most 4.5 to 7.5) but I have never seen this problem before. Could it be a DOA CPPM card?

Best regards,


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
I've found this below that might help you?.

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


All the best

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

If it's working, then leave it alone!.
 
Unfortunately it's not a Co-res system (CPPM Call Server). The UCM is running on a CPDC and is syncing with the same NTP server without any problems...


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
Do you have it in Call Server mode or Signal server mode? Have you enabled the NTP with the ENL NTP command in LD 117. Have you done a STAT NTP in LD 117?
 
... Sorry but what do the NTP settings have to do with the drift of the internal clock???


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
Because the internal clock is a POS. Check your PEP's and make sure they are current in the CS. Otherwise I would replace the CPPM.
 
All the current PEP's are in. What do you mean by "the internal clock is a POS". What is POS?


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
You can correct the time drift in LD 2 and get it more accurate. But if NTP is synching does it really matter? If it is drifting that far before the NTP can update then corect it in LD 2 to get it closer. POS means Piece of $hit!
 
A thanks. But POS is a bit extreme. We got a lot of CPPM's that aren't syncing using NTP and they don't drift at all and this CPPM is drifting between 5 and 16 seconds each hour. I increased the thresholds so the NTP keeps syncing every hour, but the system generates alarms every hour so hopefully the customer isn't going to complain about that.

Maybe I should contact Avaya and see what they think about this issue. The customer told me that they did another upgrade in another country and they are having the same issue over there. So maybe there is a production fault or Avaya replaced the great Nortel clock crystals for real POS [2thumbsup]


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
Ok, I had a nice chat with an Avaya engineer and this is a know issue with some CPPMv2 cards. And there is a patch that should solve this issue: MPLR32194.

Conditions:
-----------
VxWorks based CPPMv2 Call Server. Time lag about 15 seconds per hour. It is not
known if all CPPMv2 have this issue or only some batch.

Actions:
--------
No additional actions are required.

Expected Response:
------------------
Time accurate enough.

Actual Response:
----------------
Time lag about 15 seconds per hour.

Patch Solution:
---------------
The timer’s input clock frequency should be 1193180Hz. If we want to have 2000
interrupts per second then the timer counter should be initialized with
1193180/2000~=596.
It is in ideal case. But in case of issue there are 1995 interrupts.
It looks like clock ticks at value of 1189020Hz instead of 1193180Hz.
To get 2000 interrupts per second we should set the counter to 1189020/2000 ~= 594.


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top