Latency on OC48

[swizzguy]

Hi

My question is regarding a latency on one of our OC48 transatlantic circuit from new york to london. This circuit has provisioned by a US based carrier. We used to have a 80ms of ping replies and now it has jumped to 110ms.

I investigated and couldn't find any issues with our OC48. I am not seeing any type of sonet errors including Loss of signal and Loss of Light, also Sonet path hasn't been changed either by our Telco, but latency has increased by 30ms. Can someone help me out with this problem.

Thanks

[fmeetz]

This might be a problem from the service provider end.

Ask the provider to test the circuit.

[swizzguy]

They did test the circuit and couldn't find any problem.

I am still clueless. :o(

[anthony.pugh]

Normally reduced light level would induce errors at some point in the circuit, but this is not readily apparent. Perfrom all ping tests on the edge router interfaces ( directly attached to the Light transport switches), this will rule out any intermediate interfaces. Perfrom testing with different payload sizes to see if latency is consistent with all packet sizes as errors may be reflected at certain payloads. If no change this should rule of the carrier facilites. The only other options is the change out of edge components ( not a nice prospect) to elimante possible processor or inter-router delay. good luck!

[swalimbe]

Please check with the carrier if there is protection on the circuit and if so what is the configuration. If the configuration is UPSR, make sure that the circuit is on the working side on both the ends. If the receive on one end is on working and on the other end is protect, that would explain the change in latency if the working and protect paths have different lengths. I have seen such issues in my network and one way to resolve is to make the circuit revertive. Hope this helps.

[melon_2]

An OC48 is always 2.4gb/s. There is never latency involved with SONET; you will always see errors associated with latency if end user devices are experiencing it and it's the carrier's fault. UPSR rings are not more or less latent depending on which path the cross connected STS channel has been placed on for transmission across the high speed optics.

I would deduct that you have a problem with your routing equipment, or the carrier is not well-versed in obtaining diagnostic information from their equipment, and therefore not seeing existing problems.

[#7]

To Swissguy: is 110msec of delay any cause of users dropping data, voice, video between continents, or did you jest notice at one point that ping replies went from 80msec to 110msec and you want ping replies as fast as they can be? If all other aspects (emulated circuits, LANE, whatever) run without problem, I can't understand why you are worried about ping delay. Personally, I'd stop worrying.

To swalimbe: I partially disagree with your statement "There is never latency involved with sonet". In a perfect world I would agree. There are two obvious things: (1) even though OC-38 sonet is a deterministic technology, the layers that ride in it do not have to be. The framer ASICS rely on getting Ethernet or Token Ring frames from buffered memory - that is one source of delay , (packets have to be SARRED & UNSARRED when going onto & leaving ATM). As transistors age, the gain can lessen and turn-on time decrease slightly - adding to delay- over time to the framing process.(2) yes I agree on the routers being probably the main delay source. If they are configured correctly, ping requests and replies get a lower priority than voice & video.

To things like OC-Xs riding inside the OC-48, the OC-X is buffered before being injected to the timeslots of the OC-48 - the injection process feels the same effects of buffering and delay.

Would you not say swissguy has no need to worry if all other users of the OC-48 have no complaints?

Bill

[melon_2]

SONET/SDH ADMs are not concerned with Ethernet, ATM, etc - it's all 1's and 0's. You would see associated framing errors at the remote end if your scenario were encountered.

[smif101]

In reply to your jump of 30ms after going to another carrier that is transatlantic, this really shouldn't be a concern. What actually happened here was that you received a 15ms delay one way on your cirucit. When you did a ping it just doubled it. By the way, SONET equipment does induce delay just like any networking gear. SONET isn't the real reason here there is delay but the fact you are going from NY to Londond is. Even if this was on a OC-768 you will still receive the same amount of delay because it takes that long for the signal to reach the other end. If this circuit went to the moon, then you can see how distance effects delay. My guess is that because you went with a new carrier they probably have more equipment and a little longer distance than your previous carrier and that is why you got the extra delay. As long as you are not dropping packets along the full range up to 1500 bytes then you are fine.