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

Mon Nov 29 08:40:17 MST 2004

Your description makes perfect sense. My system is still getting HDLC 
overruns, which are certainly a consequence of frame slips because the 
second card is not getting clocked from the external source.

I come back to my basic question:

How do you configure an asterisk system so that a second TE410P card 
recognizes an external clock source? No matter what I've done the second 
card is always reported as "internally clocked". Configuring span 5 (the 
first on the second board) with exactly the same timing parameters as 
for span 1 (which works great) is not doing it. What is the trick?

Can anybody share the config files for a succesful installation with 
more than one TE410P boards?

Fernando

Rich Adamson wrote:

>>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.
>
>
>
>_______________________________________________
>Asterisk-Users mailing list
>Asterisk-Users at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-users
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20041129/4cf44657/attachment.htm