[Asterisk-Users] Cannot get two TE410Ps to operate correctly in the same machine

[Peter Svensson]

On Fri, 26 Nov 2004, Rich Adamson wrote:

> I've read the early posts relating to this and there still seems to be
> a misunderstanding on this clock sync issue. This stuff has been around
> for a looooong time in the telephony business, but it seems like not
> many people understand it on this list.

IT is true it is a complex thing. However, even your mail has some 
simplifications / inaccuracies. :-)

> Syncing a digium card's clock has nothing to do with universal time, 
> expensive add-on clocking hardware, or my clock is more accurate then
> your clock. Every single T1/E1 data stream has clocking information
> embedded in the data stream. There is no such thing as turning _off_
> the clocking. The telco can't do it and you can't do it.

It is true that clocking is provided in the data stream, for the simple 
cases of a low level consumer. In pstn provider to pstn provider this is 
frowned upon since the 2.048 MHz stream is prone to phase shifts due to 
pointer adjustments in the sdh link it is embedded in. For pbx use this 
is good enough.

> Also, there is absolutely no need for a clock on one digium card to be
> in sync with the clock on another digium card (or any other manufacturer
> of T1/E1 cards). That discussion is totally irrelevant to using those
> ports with one exception, and I'll mention that further in this text.

This is not true. Assume all incoming links pstn links are on one card and 
the outgoing links on another? See below.

> The clock syncing issue is really very simple. For asterisk cards, do
> you connect to some system/device via a T1/E1 that you think interconnects
> with _other_ systems/telcos/ITSP's? If so, your digium card should accept
> clock syncing from that source (and only that source). You only need to
> choose one, but on the four-port digium card you're also given the option
> of selecting a secondary (etc) source should the first one fail.

True. However, you want to distribute the clocking to _all_ your 
downstream peripherials to avoid the equivalent of frame-slips. If your 
cards are not clocked the same exactly you will need to invent/drop a 
freme efery now and then. That is why most people want to lock a second 
card to the first. More so for T100P/E100P.

> What's the issue?  The telco (or whatever your connecting to) is doing
> exactly the same thing; they accept clock sync from another telco or long
> distance provider that provides T1/E1 connections to them. Assume purely
> for discussion purposes, the telco's clock is supposed to run at exactly
> 1.544 mhz/sec. What happens if their clock is actually running at
> 1,543,900 hz instead (clocks do drift)? You could have the most accurate
> clock in the world that you're syncing to, and in this case you are going
> to have a problem because the two clocks are _different_. There is going 
> to be frame slips that occur, and the rate of slips is directly related 
> to how far apart the two clocks really are. How do you get around that? 
> By simply telling your T1/E1 card that you are syncing to that span. 
> No more slips, period.

This may be so in USA. However, at some level you reach the tier-1 phone 
companies. These _do_ run independant clock sources, synchronized to TAI 
or UTC (equivalent for this discussion) to keep their sdh trees 
interconnectable. This is why the clocking stream from the operators are 
usually a good timing reference.

There is however a bit of wander involved. This means that the 
operators may not be completely in sync. Since this wander and jitter is 
kept below the levels the protocols are designed for there is normally no 
problem in using the clocking from one operator to transmit to another.

Note that this is not neccesarrily the effect of the operators clocking 
from on another. If they don't then they need to use a common traceable 
clock to guarantee the frequency stability needed for sdh operation.

To recap: telcos are in sync either because they are hierarchical (very 
common in america I understand) or because they reference standardized 
time (most Europeean telcos). 

So far we are in agreement.

> What happens if port #3 goes to one of your channel banks? No problem, 
> your digium card has embedded the clocking information in the T1/E1 data
> stream (you don't have a choice either), and you configure your channel
> bank to _accept_ clock sync from that T1/E1.

> What happens if you have a second T1/E1 card in the system? It doesn't
> make any difference. If a port on that card _is_ connected to a telco,
> then accept clock sync from it. If none of the ports have such a 
> connection, then simply configure the devices at the far end of those
> T1/E1's to accept clock sync from your second card. Does it make a
> difference if your clock is accurate? Absolutely not, but it does make
> a difference if the clocks at both ends of that T1/E1 are allowed to
> drift around on their own (no sync).

Yes, it does make a great bit of difference! If the second card is not in 
sync you will get the equivalent of frame slips. Data will have to be 
invented or dropped to compensate for the mismatched speed. This is a 
problem.

On another note, in modern pstn design you separate the clock distribution
hierarchy from the data hierarchy for various reasons. One being the the 
core network has no real hierarchy, only peer switches. Another is that 
timing derived from data carrying links is not that stable. If you dig a 
bit you can find the clocking interface definitions from various pstn 
providers on the net. It can be an interesting read, if one is so 
inclined. (I know, sick isn't it?)

Peter