iDirect Evolution and iNfinity latency

(Read 5807 times)

Oct 31^st, 2010 at 10:20pm

A question to the forum: what is the minimal latency expected on Evolution system, in ACM mode and on iNfinity, assuming a remote exchanges TCP/IP traffic with a server in the hub?

Nov 2^nd, 2010 at 5:53pm

There is a certain release in which the latency switched within the iDirect product line.
Pre iDs 7.0.8 (i think or 7.0.7) the Latency "typical" value was quoted as 560ms to 580ms approx.
After the release of iDs 8 the Latency increased to 630ms - 640ms approx.
iDx releases (Evolution) currently have the later latency values so you should see 630ms - 640ms in a decent, well commissioned and well designed system.

Are you seeing values wildly different to these? there are lots of configuration and design as well as physical influences that will give you less than optimum Latency performance.

Nov 4^th, 2010 at 1:34pm

Dear Scout,
Thanks for that.

AGOR

Jan 11^th, 2011 at 7:11pm

Just wanted to follow up:
iDirect have resolved issues that caused increased latency in versions 8.2 and above.
In the new release, I think 2.1.2 moving forward, the latency on the iDirect platform is back to pre 8.2 values. so I see a 40 to 70ms improvement over the previous versions....
I think you should see in 2.1.2 and newer the old values, 560-580ms perhaps.

Jan 11^th, 2011 at 7:12pm

this is also backed up in their release notes.....just checked

Mar 2^nd, 2011 at 6:04am

by the way, what is the possible cause of the latency alarm if the SNR values are good? I have been facing this so many times.

Mar 2^nd, 2011 at 6:53am

Congestion on the network?

Mar 2^nd, 2011 at 2:19pm

Quote:

by the way, what is the possible cause of the latency alarm if the SNR values are good? I have been facing this so many times.

Dot is correct, if you have a good transmission path, the likely cause is congestion, this does not mean you have to have fully used bandwidth, you could have a QoS configuration restricting the data allowed for NMS traffic (latency is measured by ICMP messages from primary NMS)
check out your bandwidth utilization, if it looks like you do have free bandwidth in your inroute (typically inroutes are the restrictive segment, but not always), if you have free bandwidth, check the traffic through that remote, see what queues the traffic is flowing through. It is very common to see QoS configurations that need tweaking.
Are you experiencing traffic problems other than seeing the latency being high?

Email me:eric@satsig.net

Disclaimer, Terms of Use and Privacy

Old Forum rules

Cookie policy.