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

[Peter Svensson]

On Sat, 27 Nov 2004, Rich Adamson wrote:

> > You misunderstand me. I know that the buffers are larger. However, even if 
> > they are 1 second deep they will eventually empty / overrun. There is no 
> > way about this except to either allow data to be invented/dropped or to 
> > keep the source and sink in perfect sync.
> 
> I wouldn't doubt there is code in asterisk to handle some sort of buffer
> overrun, but I'd guess its simply throwing away some bytes. Voice
> users wouldn't even hear it. An 8,000 byte buffer should handle a
> frequency differential of 4%. I don't know of any modern electronics
> that can't hold better tolerances then that, including the digium cards.
> So, the entire discussion of syncing two cards is irrelavent. Asterisk
> users really don't care and don't need it; a large majority would be
> very happy to have a single T1/PRI available to them. :)

How on earth can a buffer handle a frequency discrepancy? The buffer will 
either fill up or empty completely. If the frequency error is 4% then an 
8000 byte buffer will go empty / overflow in 12 seconds, after which you 
will have to start dropping / inventing data, and have a half-second 
delay at that!

A buffer can _never_ compensate for inaccurate timing. This is why you try 
very hard to have good clocking end-to-end. For the pstn the clocking is 
derived from a source all agree upon. For VoIP you most often clock the 
outgoing data from the incoming. 

> > You do not have to have the pci bus in sync though, as long as the two 
> > cards are in sync. 
> 
> And how would propose to keep two cards in sync if you didn't rely on
> the only common existing path (pci bus)?

You do not have to sync every clock tick, you only have to sync the 
frequency. Measure the error over a longer period of time (say 1 second or 
so) and adjust.

> > The interrupt latency is a red herring. Extremely precise interrupt timing 
> > is _not_ needed to communicate the clocking from one board to another.
> 
> You should probably ask any of the audio folks and a large number of
> digium x100p/tdm04b folks if they think interrupt latency (and pci bus)
> is a red herring. Think you'll find a strong difference of opinion.

For this discussion it is a red herring. Not in general. 

> > For Unrestricted Digital connection I wonder what happens. I guess they
> > are not allowed across boards? (They do work very nice within a board
> > though, this is very nice).
> 
> I don't have one of the digium T1 cards in front of me, but if they are
> designed with the same type of pci chips used on the analog boards,
> there are only tiny buffers (a few bytes, maybe eight). That's why
> interrupt latency is such an issue. If the card can't dump its data
> across the pci bus quickly (by raising an interrupt) and in a 
> consistent manner, overruns or lost data will occur right on the card.

The E1/T1 cards generate interrupts at 1 kHz and tolerate at least a 
latency of 0.6 ms. Not that that has any relevance to the discussion of 
clock sync between cards.

> The digium boards don't have much intelligent controllers on them; all 
> of the control intelligence resides in asterisk code running on linux.
> So, there isn't any capability to send selected data from one card
> directly to another across the pci bus. It all has to pass from card
> to bus to OS to asterisk, and then back through that path to the next
> card (if that's the destination for those bytes).

And this was not what I suggested. Use the estimate of the clock error 
derived from the fill/empty rate of the intervening buffer as feedback to 
the local clock control on the second card. 

This is not rocket science. It is how you almost always distribute 
clocking, and indeed solve a large number of other problems. Create a 
servo loop that controls a local oscilator. Control it by measuring the 
error/beat what have you.

Peter