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

[Rich Adamson]

> It seems to me that if not all cards are clocked from the same source, 
> then each one should be able to get its own external clock. However, 
> card 0 has an external clock, but card 1 does not.

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.

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.

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.

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.

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.

The digium T1/E1 cards only have a single clock chip on the card. There 
is no reason to have four clocks on a four port card. By telling your
card to accept clock sync on port 1 (as an example), the digium card has
the smarts to adjust that single clock chip to be in sync with that span.
Since practically every telephone company has T1/E1 feeds from other
telco's, they follow a hierarchical engineering approach that basically
says all telco's are in sync. That engineering approach has been around
since T1's were invented, and the telco engineers know that very well.

So, what happens if port #2 goes to yet another telco? No problem, because
the telco's are already in sync. Choose one as your primary sync and
the other for backup (secondary).

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.

The only exception (as mentioned above) to this is "if" you happen to 
engineer a combination of three or more asterisk systems in a circular
fashion, and you've told all three to sync from its neighbor. In other
words, system A connects to system B, then C, which connects back to 
system A, and you have B accepting clock sync from A, C from B, and 
then on the last leg from C back to A you tell A to use clocking 
from C. Any clock drifting that might occur will be passed around the 
closed loop and _could_ present a problem if the clock drifted far 
enough off frequency. E.g., one bad card could impact all three spans 
under the right conditions.

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).

What if you have something like: telco -> legacy PBX -> asterisk ?
The legacy PBX has already been configured to sync to the telco. If the
T1/E1 from the PBX to asterisk _happens_ to be on the exact same PBX
card that has the span to the telco, then that card will be in sync
with the telco and asterisk should be configured to accept clock sync
from the PBX. What if the PBX span to asterisk is on a different card
in the PBX? Doesn't make any difference, asterisk should still be
configured to accept clock sync from the PBX. It's almost a none issue.

What if you have 17 digium T1/E1 cards in the fanciest system you can
buy? Doesn't make any difference; for each card select a span that you
believe might have a reasonably accurate clock and sync from it. If
none exist, then think in terms of this card _is_ the most accurate,
and you're going to configure the devices attached to those spans to
accept clock sync from your card.

What happens if you have a dual-homed fancy channel bank where one of
the spans from it goes to somewhere different? From a pure engineering
perspective, find out whether that second channel bank T1 leads back
to a telco, and if so, sync from the channel bank.

The telco engineers have had to deal with clock sync for years. If your
going to play the role of the engineer for asterisk, then best think
through the hierarchical clock sync thingie and engineer appropriately.
If you're planning a large scale asterisk deployment, put together a
plan that makes sense hierarchically passing along clock sync from one
system to another.

None of the T1/E1 clock sync issues have anything to do with interrupts,
interrupt latency, etc, etc. In fact, changes in interrupt latency are
likely to be 1,000's of times greater on just about any PC system when
compared to the slight drift seen in T1/E1 clocking.

What if you have a single port T1/E1 card from digium? No decision to
be made really; you're going to sync from the other end if it goes 
higher in the hierarchical chain. If the port goes to a box consider
lower in the chain, then the distant box should be configured to
accept clock sync.