leased line timing for point to point via microwave "line or internal"

dnickich · ‎03-18-2003

I am having trouble with several Point to Point T1 circuits. Two of these are between a couple 3640 routers. These routers are connected via a T1 to DS3 MUX to microwave hop to DS3 MUX back down to T1. There is no DACS in the circuit. My Current clock source is line on both ends of this circuit but I am seeing

show service-module serial 0/0

...

Total Data (last 96 15 minute intervals):

27 Line Code Violations, 601 Path Code Violations

0 Slip Secs, 11 Fr Loss Secs, 21 Line Err Secs, 15220 Degraded Mins

191 Errored Secs, 77 Bursty Err Secs, 11 Severely Err Secs, 0 Unavail Secs

I have heard that the clock source should be set to line AND I have heard that it shold be set to "internal". Which is correct for this WAN configuration? If timing off the line on both ends is correct where does the timing on the circuit come from?

michael-faust · ‎03-18-2003

Ideally, there should be one clock source per T1. Two sources could be used if they sync to a common source. Are you confused yet? To really get to the answer you want - If there is a network element (MUX, DACS, etc.) that is providing clock to you - use it (clocking line). This assumes that clocking is provided to both ends from a common source. Otherwise you must provide the clocking.

The whole idea is that both ends are using the same source. So, if you need to supply timing, set the clock to 'internal' at one end. This will cause that end to use the clocking from it's internal oscillator. The other end should be set to 'line'. This will cause it to re-sync it's clock on each 'one' bit received. Hence, they are both using the same clock source (the internal oscillator at one end).

Hope this helps.

dnickich · ‎03-18-2003

How can I tell if the MUX is providing clock? I am using clocking line now but I am seeing errors. These errors seem to be bursty. The circuits run OK for a few hours at a time then take a stack of errors. I am thinking that this is a timing slip on the WAN (T1 spans). I can not figure out how to isolate the problem. I have removed one T1 from service and did a hard wire loopback at the far end and ran a test pattern on it for 24 hours with out an error.

As to the common Timing source issue I don't think that I have that. I am connecting to AT&T which is on one end of a DS3 microwave hop and Telus owns the DS3 microwave equipment that it is "talking" to. Other than each network having it's own stratum one clock.

I am told by the carrier that the circuits that I am using are "clear channel" "unframed". This make me think that I can not "recover" clock from the line.

michael-faust · ‎03-19-2003

Timing slips can cause the behavior that you describe, but other things can also. When the two ends of a circuit are not using the same timing source, they may slip. What happens is that when a bit is received out of time, it is buffered. When 193 bit slips have occured, the buffer is cleared. This is a frame slip. Jitter on the line will cause bit slips, but positive slips cancel negative slips and no frame slip occurs. When the two ends are slightly out of time, the circuit can run for quite some time before a frame slip occurs.

There are too many variables here for me to tell you what is wrong but I will try to lead you in the right direction. I would be surprised if you are receiving clock from the line. If that is true, then you need to provide the clock. Do so at one end only. It should be pretty easy to see if that fixes the problem. If it doesn't, let me know, and I will tell you how to run some loopback tests. Good luck.

dnickich · ‎03-19-2003

We have changed to provide clock on the local end and things are running better. We are still having some trouble. Also we have 2 other T1s that are running better than these that are timing off the line. They are on the same DS3, MUX and Microwave path and end at the same office. Our loop back tests show that when we loop back at the DSX Jacks the T-bird show they run with no errors while testing for 72 hours.

Maybe you could check me on this. I know that our IXC is running clear channel. We connect to them on copper with no active network devices. I believe that clear channel is unframed by the IXC. I also believe that clock is recovered from the framing bit. If there is no Framing bit then there can be no recovered clock. Then the Framing bit has to be inserted at the end equipment, correct?

michael-faust · ‎03-21-2003

When the IXC says that they are configured for unframed - clear channel, I think that they are talking about the DS3. To the DS3, the T1 is just bits. You need to set the framing, line code and timing.

I can't address your loopback tests because you didn't tell me exactly what was looped back and where. There are many places to do loopbacks. Also, most CSU/DSUs that I have worked with will provide the clock under certain loopback conditions. In other words the CSU logic is, "I have sent a loopup code to the other end. The other end cannot provide clock now. I better clock myself."

Possible loopbacks for testing are: Far end DSU (or data) loopback - the data is sent to the far end, through the CSU to the DSU where it is looped back to the near end. Far end CSU (or line) loopback - the data is sent to the far end CSU where it is looped back to the near end. Near end CSU loopback - the data is sent through the DSU to the CSU where it is looped back. Near end DSU loopback - the data is sent to the DSU where it is looped back. You can also do a hardwire loop at any point in the circuit.