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

[Peter Svensson]

On Sat, 27 Nov 2004, Rich Adamson wrote:

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

Ah, but here is where we disagree. If the two T1/E1 links are not in 
complete sync there will be a need to insert / drop data. There is a 
buffer but the buffering can only handle jitter, not compensate for 
frequency difference. If the spans on the two cards are kept in sync the 
data going from one card to the other will be consumed exactly as fast as 
it is written. This will keep the buffers from overfilling / draining.

The fact that a buffer is involved is no magic bullet that solves 
everything. 


On the other part of your email regarding the fact that asterisk is almost 
exclusivly used in a hierarchial arrangement I do agree with. In fact, 
this is why it is important to keep the hierarchial timing going even 
across different cards on the pci bus. It is certainly possible using a 
phase locked loop in the computer to get the needed stabillity across the 
pci bus. There is no need to send _every_ timing event form one card to 
the other.

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

No, but we seem to have drifted onto two different conversations in one 
email. This discussion is certainly rather far off from what concerns 
Asterisk. I think it was my fault. I only wanted to correct the statement 
that timing in the pstn was always hierarchial. It is usually, but only 
until you reach the top tier operators. 

All discussion below have little direct effect on Asterisk users. 

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

In many countries we have several top tier operators active. For example, 
we have several national and a few international carriers in Sweden, all 
having customers directly attached. The international carriers are more 
likely to not use the national incumbents clock than the other national 
operators are. However, as long as they all have properly disciplined 
clocks the differences should be small.

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

If the clock quiality is of importance they are often split physically as 
well. Clocking derived from an active pcm stream may suffer during pointer 
adjustments etc. For primary clocking distribution it is recomended to 
have a separate clocking connection with a guaranteed lack of induced 
phase discontinuties.

Again, not relevant for a scenario where asterisk is used. Hm, possibly 
not that asterisk/zaptel is on the cusp of gaining ss7 support this may be 
relevant. I don't know.

Peter