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

[Rich Adamson]

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

No, there is no need at all.

> There is a 
> buffer but the buffering can only handle jitter, not compensate for 
> frequency difference. 

No, you're assuming a one-byte (or very small) buffer, and that's not 
what's going on in asterisk.

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

Maybe in utopia, but that's certainly not asterisk. You've been around
this list long enough to have read the many discussions relative to
interrupt latency, and some of those latencies are directly assoicated
with human recognized echo, etc. Those issues imply delays through the
system upwards of a bunch of milliseconds, with hugh variations depending
upon what other devices grab the pci bus. So, you couldn't keep the data
flow to be "exactly in sync" if you tried real hard.

You can't implement phase lock loops, etc, to control the bus issues
either without modifying the motherboard and/or digium cards. No one
is going to go there.

> This will keep the buffers from overfilling / draining.
> 
> The fact that a buffer is involved is no magic bullet that solves 
> everything. 

That's true, but it _is_ what you've got to work with in *, like it
or not. Its not been an issue for anyone that has implemented multiple
digium cards, so I guess it boils down to don't fix it if it ain't
broken.

Rich