Re: Event log "No time check was outstanding" on rogger

K_require · ‎09-07-2008

Hi,

We found the following errors in event logs on rogger this morning:

---------------------------------------

No time check was outstanding with the transaction ID of 390 reported by controller 5002.

No time check was outstanding with the transaction ID of 388 reported by controller 5000.

No time check was outstanding with the transaction ID of 389 reported by controller 5001.

---------------------------------------

Event ID : 38 Category : Call router

Our IPCC operation is working fine. We want to investigate why this error has generated. Can anyone guide? Many thanks in advance

SportsGuy0223 · ‎09-09-2008

I am having the same issue. It is coming from the rtr process. I am going to open a TAC case on this unless anyone else has seen this.

The environment i'm working with is 7.2.4 upgraded from 6.x.

Thanks,

K_require · ‎09-12-2008

Hi Andy,

Will you please let me know the TAC case result once you will get the ifo?

SportsGuy0223 · ‎09-12-2008

We turned up debugging and are still waiting to see if it occurs again. I have only seen it one time thus far. I will post again if it happens again and we can find a solution.

Thanks,

Riccardo Bua · ‎09-12-2008

Hi there,

nothing particular to be concerned.

These messages indicate that for the given controller, a response to a time check query

by the RTR was received by the RTR, but after the timeout period.

Network latency might have cause this or CPU spikes.

Regards,

Riccardo

SportsGuy0223 · ‎09-12-2008

Riccardo thank you for the response. That is what the TAC engineer originally expected however the servers are both plugged into the same switch, negotiating at 1 gig full with no collisions. Also if something caused a CPU spike which triggered this message wouldn't it be something to worry about?

Thanks,

Andy

Riccardo Bua · ‎09-12-2008

Hi Andy,

not really guess the system was busy processing some other messages before turning on those ones.

Roggers have quite some time sensitive messages, check on CPU spikes, maybe via perfmon monitoring.

Tracing will not help.

Regards,

Riccardo

SportsGuy0223 · ‎09-12-2008

Perfmon tracing was turned up as part of "turning up traces" that the TAC engineer wanted to see. If this is a CPU issue we should catch it if it happens again. Is there anyway to adjust the timeout value or is that not recommended?

Thanks,

Andy