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 [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users |
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users