IPSLA:udp-jitter with codec g729: no value for latency

[Martin Ermel]

I've setup an udp-jitter operation with codec g729 on a cisco 1761 to run on port UDP 51140 (destination) and an ip sla responder on the far end side. I see that control packets are received and get a MOS and ICPIF value as well as RTT. But I do not get any value for latency. It is always 0.
First I noticed that ntp was not in sync but this is ok now but still no luck.
this is the topology:
c1761 - ASA - Internet - ASA - remoteRouter(c38??)
both sides are running IOS from the 12.4T train (I currently have no access to check exact version). I have no access to the config on the ASA (and the Internet :-) ) but according to the reponsible person there is no ACL to restrict any traffic (ip permit). Connection is done through an IPSEC tunnel.
What can prevent the latency to be calculated? (I assume ASA is doing stateful inspection)

[Joe Clarke]

The main reason for not getting one-way latency values ia clock skew.  I know you say the routers are synced with NTP, but are they synced to the same source?  On both end points, do:

no ntp clock-period
ntp clock-period

This should correct any drift problems, and hopefully get these latency values to show up.

[Martin Ermel]

I configured the same 2 ntp servers on both routers. Both ntp servers do have a stratum of 2 and if I remember well they have the same reference clock. I have no perferred ntp server set but when I checked the ntp association both routers were synced to the same server. Tomorrow, I will definitely issue the commands you provide and see what happens.
I also tried to figure out the cause of the problem with "debug ip sla trace", but could not well interpret the output and found no documentation about it...

I will try to get more output

[Martin Ermel]

I issued the command you provided but I got the message that it is depreciated so I do not know if it had an effect;
There was a latency value for 2 or 3 cycles but then it fall back to zero; Interestingly on monday (3 days later) the latency value was provided constantly so I assume there was indeed a problem with time synchronization. I checked again a captured log from last week from a seesion when ip sla debugging was enabled and found a "Timestamp inconsistent for jitterIn" which I think points to a timing issue, also.

attached are some more information for those who are interested in...

So now it is working and I have the next question....
When ip sla debugging is enabled the baseline for jitter and delay are shifted by a value x which would mean that the timestamp to calculate these values is given after the debug processing. Does anybody has observed this behaviour as well?
This is not ideal because it does have an impact on the SLA I want to prove with this method...

[Joe Clarke]

I haven't observed this personally, but it wouldn't surprise me to hear that debugging affects jitter calculation as the process of printing debugging messages requires a non-zero amount of time.  I don't see that this has been reported by any other customer, but that, too is not surprising as running with debug isn't a common thing.

[stephen.himebaugh]

I'm having a similar situation.  Using UDP-Jitter IP SLA different devices & different level of IOS 12.4T code (even a 15.1T) are all showing no data for latency.

Here is a typical SLA:

ip sla 10
udp-jitter [destination ip address] 16384 codec g711ulaw
tos 184
tag [location]
ip sla schedule 10 life forever start-time now

Found something in the Cisco IP SLA 12.4 Configuration guide about no latency data that confirms the error message about NTP.  But we synchronize to the same Stratum 1 NTP appliances for all our devices: Time synchronization, such as that provided by NTP, is required between the source and the target device in order to provide accurate one-way delay (latency) measurements. To configure NTP on the source and target devices, perform the tasks in the “Performing Basic System Management” chapter of the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2. Time synchronization is not required for the one-way jitter and packet loss measurements, however. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data will be returned, but values of “0” will be returned for the one-way delay measurements provided by the UDP jitter operation.