2620 with Serial errors, T1 slow downloads

[dtisp]

I have a T1 from Sprint. About a week ago I noticed things were getting slow. I did some tests to dslreports and other palces. I am only getting around 768Kbps download. I used to get right at the full 1.54Mpbs of the T1. I even took down everything but one computer and it is still the same.

I contacted Sprint, but they tell me they do not go by those internet tests, but ask me how the web pages seemed to download. Boy, that makes a lot of since doesen't it!

They did find a couple of settings in the router that were not right and we corrected them. I ask if they had a site avail for me to test with and the guy was not sure. He then proceded to send large amounts of data to my router and the input rate showed I was receiving around 1.2 meg. They told me nothing was wrong.

The system is still slow and I have noticed some errors on the router that I am not sure about. Could someone please look at this and give me some insite on these errors.

I am not sure about the drops, input errors, interface resets and carrier transitions. Do these indicate hardware problems? I read that drops indicate line saturation, but I don't think that is the case. I have had MTR running for a while and it does not appear that is the case.

http://stats.dtisp.com

Sorry for the long post, but I am at the end of my rope.


Router#sh int Serial 0/0
Serial0/0 is up, line protocol is up
Hardware is PQUICC with Fractional T1 CSU/DSU
Description: description
Internet address is x.x.x.x/30 (hidded for protection)
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliablility 255/255, txload 15/255, rxload 55/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 6d16h
Queueing strategy: fifo
Output queue 0/40, 2254 drops; input queue 1/75, 1011 drops
30 second input rate 336000 bits/sec, 86 packets/sec
30 second output rate 92000 bits/sec, 92 packets/sec
42012231 packets input, 843502088 bytes, 0 no buffer
Received 57762 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort
55611979 packets output, 4016495393 bytes, 0 underruns
0 output errors, 0 collisions, 22 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up


Router#sh service-module
Module type is T1/fractional
Hardware revision is 0.88, Software revision is 1.08,
Image checksum is 0xB8C1E847, Protocol revision is 0.1
Receiver has no alarms.
Framing is ESF, Line Code is B8ZS, Current clock source is line,
Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.
Last module self-test (done at startup): Passed
Last clearing of alarm counters 6d17h
loss of signal : 0,
loss of frame : 1, last occurred 4d15h
AIS alarm : 1, last occurred 4d15h
Remote alarm : 0,
Module access errors : 0,
Total Data (last 96 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in current interval (124 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

 

[Cluebird]

Look at changing your queuing from FIFO to something like class-based weighted fair queuing to help manage the congestion and lower the drops.

http://www.cisco.com/en/US/products...figuration_guide_chapter09186a00800b75a9.html

 

[dtisp]

It was set to weighted fair and the tech support guy at Sprint had me change it to fifo.

Is the line considered 'congested' with only half of the maximum data rate? Looking at a 5 minute average over the last week the maximum input was 712.2 kb/s with an average input of 314.8 kb/s.

Is the T1 data rate of 1.54Mb/s a total of input and output (750 in + 750 out at same time) or can it do 1.54 in and 1.54 out at the same time?

This still does not explain why I can disconnect everything but 1 pc and still not get greater than 768kbps download and 1.2Mbps upload at dslreports when I have been getting 1.1Mbps to 1.5Mbps download until a couple of weeks ago. I have had this line for about 3 years and I know by the feel of everything that something is wrong.

Thanks for any information.

 

[rburke]

In most cases a T1 is only half duplex, meaning that you add the input and the output to get the amount of bandwidth you are using, which of course can not be above 1.544 Mbps.

I do dedicated tech support for another major backbone ISP and I can sympathize with the Sprint guys because basing your download speed on DSL reports or any other download speed test that is not specifically made for Sprint dedicated customers can lead to confusing results.

From the MRTG results it doesn't look like it would be a capacity issue. Also from the "show int s0/0" most everything looks clean. The only exception would be the interface resets and the carrier transitions. The interface resets generally come from when the line loses sync and goes up/down or down/down, or admin down. The carrier transitions are when the line goes up/down because of circuit issues. You can see at least one of the circuit transitions from you "show service-module" output line about the AIS error.

What I would recommend would be to contact sprint again and have them run a capcity test on your circuit. They should be able to loop the CSU/DSU and then run a test that test the capcity of the line. Unfortunetly I don't work in the department that does that with our ISP, but there have been several instances where I know this has been done for customers. This would rule out a capacity issue, but after looking at the graphs I don't think it is going to be the problem.

The more likely issue has to do with DNS. I'm not sure what DNS you are using the resolve with but in most situations where the internet "slows down" suddenly it is a DNS issue where the internal DNS has gone haywire and isn't working properly causing the host to timeout on the primary DNS server and then query the secondary.

Those are my thoughts on the subject, hopefully they help.

Burke

 

[robertjo24]

Rburke,

In what cases do you get a half duplex T1?

 

[rburke]

I don't understand what you are asking?

I'm using the term half-duplex fairly loosely because duplex settings are really meant for broadcast mediums, such as Ethernet, and not for clocked circuits like the ones you get with T1 and above lines. What I mean when I say half-duplex for a serial line is that you must add the input and output together to the amount of bandwidth you are using. This is opposed to full-duplex where both input and output can theoretically be handling the maximum bandwidth.

Burke

 

[dtisp]

I run my own dns servers. ns1.dtisp.com and ns2.dtisp.com
I have no problems with anything resolving. The only thing in the logs are tons of 'lame server' errors. I don't think these are caused by my dns, are they?

I know that the speed tests on dslreports and others are not exact, but they should be a baseline to test by. Even if a T1 can only handle 1.54 total, that still does not explain why with only 1 pc and my dns server connected to the router, that I only get half the download speed that I have gotten for the last 2 1/2 years.

I am going to call Sprint this week and get them to do a capacity test on the line as suggest earlier. Will this check all the way to the router? The router is a 2620 with the T1-CSU/DSU card connected to a 'smart jack' from Centurytel.

LaRoy.

 

[rburke]

Generally they will loop it to the CSU/DSU but depending they might loop it only to the smart jack. Either way it will test the actual capacity of the line all the way to the demarc where it is in your contract with Sprint. Again, I seriously doubt it is a capacity issue since your MRTG graphs are not showing any flat lines at a certain area. From capacity issues I've seen the MRTG graphs will show a flat line instead of a peak where it is maxing at. Your graphs show no signs of this.

If the capacity test comes back clean then you might want to look into packet loss. I don't know if you have a Linux box around but a good program to track packet loss is "mtr" stands for Matt's Traceroute. It shows packet loss on a per hop basis. It doesn't look like it would be packet loss on your circuit, but maybe there is a link from your POP to the backbone that is having issues. If so and you had proof then Sprint sould need to fix that. Anyways, that is just another thought of what could be causing slow speeds.

Let us know what Sprint says.

Burke

 

[BuckWeet]

Try downloading things from sprint themselves, that way you know you're not leaving their network, and it should be very fast within.. If the problem arises when you leave sprint, then thats the problem.. I'm not sure where sprint is now, but a few years back their network was horrible when getting to the peer providers..


BuckWeet