High latency when idle, low latency when passing traffic

We are using ppp multilink bundle connections throughout out network to aggregate bandwidth from multiple T1s. One of these connections is exhibitying bizarre behavior.

At night, when the traffic rate is low, latency on the line increases to about 300 ms. As soon as data starts coming down the line, latency drops down to sub-80 ms. There are 7 T1s in the multilink bundle. I checked the DSU settings on both ends for each of the lines, and they all look correct. We are using ESF / B8ZS.

We have three other connects using similar routers, IOS versions, and numbers of T1s in the multilink bundle;they all show what you'd expect: really low latency at night, with increases under heavy load. It's not an issue of ARPing adding to the latency.

Could this be a timing issue?

Reply to
Mark Williams
Loading thread data ...

Some things to look at:

  1. CPU - show proc cpu
  2. Interface drops
  3. Interface queue . Are there packets in the hold-queue on the interface waiting to be sent? (show interface)
  4. Interface errors on a particular T1.

Steve Griffin

formatting link
(Bluetooth Wireless Console Cable)

Reply to
info

Mark,

Can you swap the suspect T1 with another T1 at both ends. This could prove the T1 is at fault. Also, look at the NIU's. If you see an "L1" or "L2" LED that is orange, red or not lit then the problem is with telco. If the "DS1" LED is yellow or red then the problem is in house. When we had problems with latency, sometimes it was the router or CSU/DSU but most often it was due to a T1 issue. Sometimes one loop of the T1 followed a different path through the crossboxes than the other loop and this caused problems - this is hard to prove though since it may not show up as an error on the LED's and you would need to physically get into the T1 circuit with a TDR and check the distance of the two cable pairs and then get telco to match the pairs. Other issues could be half-taps on the circuit between you and telco - again they may only be detectable by getting into telco's circuits and they probably would not show errors on the LED's on the NIU, but can cause errors that only show up during specific situations. Do you have access to a TBERD (T1 tester)? If so then you can run tests on the T1 (quasi, all ones, all zeros,

3 in 8, etc.) the different tests will identify different issues with the T1. You may have a problem with a circuit that has an exposed wire someware between you and telco and at night moisture builds up and causes errors due to high impedance shorts - when you send a lot of traffic through the circuit then the current dries out the moisture and the circuit cleans up. This may sound like sci-fi but I have had more then one T1 tech tell me that this is more common then one may think. To prove this you may have to check the NIU LED's late at night to see if they change from what they are during the day. I couldn't tell you how many times I was at a site at 2-3-4 am trying to prove or disprove telco as the problem. God I'm glad I got out of hi-tech. To put things in reference - I worked on a project (many years) where among other things we maintained 96 sites and over 150 T1's, OC-3 through OC-48, microwave, etc. and Cisco routers, Nortel voice and Marconi ATM, and over 90% of the problems we encountered were with the telco T1's.
Reply to
clubfoot

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.