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

[Rich Adamson]

inline...

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

And more then likely several _depending_ upon exact configurations in
the mind of the reader. :)

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

And the above statement reenforces my statement elsewhere that telco
engineers (or pstn providers) generally understand the sync issues far
better then most * engineers, and engineer their systems accordingly.
Asterisk engineers need not be concerned with level of detail that a 
pstn engineer has to deal with.
 
> > 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.

I'll disagree with your "not true", but you have a specific case in mind
that from a human communications perspective we're not sharing, so _some_
specific cases (but very few) you could be correct with the disagreement.
(How is that for a double negative. :)

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

This is definitely not true (relative to one card in the same box syncing
with another card in the same box). The clock sync is a layer 1/2 issue 
for each span, and there is no requirement to suggest that downstream
spans must be in sync with upstream spans when two cards are used.
Example: a downstream span heading towards a channel bank on one digium
card doesn't care who is syncing to who on a second digium card handling
the upstream data to the pstn. The pcm data to/from the downstream flows 
into one digium card, moves across the pci bus (and is subjected to any/all 
interrupt latency issues in that system), then analyzed by asterisk
code, and finally sent to the upstream digium card (being subjected to
yet another set of interrupt latency issues). Asterisk code is buffering 
that data flow making clock sync issues between the two cards 100% 
irrelavent in all cases.

I fully understand the words that you're using and your words "do" apply
to specific cases when engineering pstn switching systems. They just
don't apply to the architecture of asterisk systems.
 
> > 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.

Your trying to distort asterisk span engineering with the more complicated
issues that pstn providers have to dial with. Let's stick to * stuff.
 
> 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.

That really depends on how each operator engineered their systems, and,
somewhat on the quality of the hardware deployed. I'm sure we can find
exception cases in every country.
 
> Note that this is not neccesarrily the effect of the operators clocking 
> from one another. If they don't then they need to use a common traceable 
> clock to guarantee the frequency stability needed for sdh operation.

And that certainly is the objective of every operator, but again some
may have valid engineering exceptions, lack of budgets, etc, that preclude
their immediate ability to comply with whatever hierarchical structure
is relavent for that country. Luckily, * engineers don't have to be 
concerned with the pstn operator/engineering issues.
 
> 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.

That is simply not true for asterisk systems built on digium cards (or
the equivalent). Again, asterisk is buffering the data flow _between_
cards, and that buffering negates _any_ requirement for two digium cards
to be in sync with the same clock. (Your trying to apply telco engineering
principles to the asterisk system and they are not the same at all.)

There are some very very specific cases where your comments are generally
true, but they are only true when using a 4-port card and two or more
of those ports terminate spans from different pstn providers, and one
of those providers is not participating in their country's hierarchical
clocking plan. (This _is_ a case for engineering the spans so the two
conflicting spans terminate on different digium cards within the same
* system, and is further justification for _not_ trying to sync clocks
between two T1/E1 cards.)
 
> 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?)

Agreed, one does separate the two but only in the engineer's mind. The
engineer is the one that must carefully think through which systems/devices
are syncing on others and must establish whatever hierarchy is appropriate
for his specific requirements. In some cases, the engineer may decide to
physically separate the clock syncing from the embedded pcm data stream.
But again, those are pstn engineering issues not * span issues.

Some of those pstn engineering issues do apply to engineering asterisk 
implementations where multiple T1/E1 spans are involved. The issue on 
_this_ list is that a large percentage of asterisk implementors are 
taking on the role of an engineer without the knowledge/experience to 
even know what they are getting into from a T1/E1 perspective (which 
was the start of these span sync threads). Luckily, engineering * spans 
is far more simple then engineering a telco office sync structure.
So, lets do everyone a favor and keep the topic oriented towards *
engineering.

Rich