High Latency on Point to Point

[joshthek1]

I have a point to point DS3.  There are no errors on either end.  However, the latency is triple what it normally is.  I called the vendor and they stated that everything was running fine.  I was wondering if anyone might know of something I can check on my side, or anything I can ask the vendor to look at specifically?  For instance, are there any tests I can have them run that might isolate the problem?  I know the question is pretty vague, but my users are complaining about the network and I am having difficulty finding a place to start in resolving this problem.  Thanks,

Josh

[paolo bevilacqua]

If users are conmplaining, there is likely packet loss. Latency alone dos not cause problems., what you have line 5 ms ?

What is circuit utilization ?

[joshthek1]

It normally is at 5ms but for the past couple days it has been 13ms.  Line utilization is very low.  I use Solarwinds to monitor and it is below 10%, however if you would like some other metrics just let me know and I'll post them.  For instance the txload is 6/255 and the rxload is 12/255 currently.

Router#sh int s1/0
Serial1/0 is up, line protocol is up
  Hardware is DSXPNM Serial
  Internet address is 192.168.XXX.XX/30
  MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec,
     reliability 255/255, txload 6/255, rxload 12/255
  Encapsulation HDLC, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1d01h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 25
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/25 (size/max total/threshold/drops)
     Conversations  0/43/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 15473 kilobits/sec
  5 minute input rate 2186000 bits/sec, 482 packets/sec
  5 minute output rate 1085000 bits/sec, 302 packets/sec
     11574498 packets input, 3776316811 bytes, 0 no buffer
     Received 10755 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     9293649 packets output, 2862497603 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
DSU mode 0, bandwidth 44210, real bandwidth 44210, scramble 0

Now, it is true that users were complaining yesterday, and not yet today so these numbers may not mean much.  In addition, the problems that they are complaining about may be a result of something that is not related to the network.  However, I was wondering if there were any tests I could run or have the vendor run to make sure that this line is not the issue.  As you can see from the above, there are no errors here and I have not run a clear counters command since yesterday when I began looking at this.  Thanks,

Josh

[joshthek1]

Maybe to rephrase the question, what might cause the latency to jump from 5 to 13?

Some ideas here might give me a place to start looking.  Thanks,

Josh

[vmiller · Accepted solution]

Here is how I might go about it.

1. Get a rough estimate of the geographical distance between the sites. Somewhere on the web is a calculater to get a working number for what the  latency based on distance should be. Do not share this with your users.

2. Ping sweep from the serial interface of router a to b. vary the size and quantity.

3. Step the pings back into the network, following the path of the users back to the last layer 3 capable device.

What we are doing here is building the chain of evidence to show that its not a network issue. Each step  is supported by the data of the preceding step.

Your carrier is off the hook at this point, unless they have followed some strange physical routing, that might be worth a call.

Even money bet its an application issue with tcp window size or lots of small packets back and forth,