[Asterisk-Users] Re: Problems with TDM400P card

[Rich Adamson]

> First off, I want to say that I'm getting involved because this is
> interesting and I want to contribute.  I am just getting started with Asterisk
> so smack me if I say something stupid.
> 
> <snip> 
> > I think we all understand the 8000 per second. That's not an issue at all
> > at the pcm level. However, the TDM card sends 1024 byte frames, not 1000
> > byte frames. 
> 
> Frame? It's an octet stream of one octet per 0.000125 sec.  It doesn't
> matter if they are delivered in chunks of 50, 100, 1000, or 1024. Just
> got to use the corresponding time expectation: n * 0.000125.
> 
> I understand in this thread from now on, "frame" means a group of 8192 
> sample octets that should arrive every 1.024000 seconds.
> 
> > The original zttest.c triggers on data=>8000, and that 
> > translates into 8192 bytes each 1.024 second (etc).
> 
> zttest.c looks fine to me (in absence of Linux scheduling delays).
> 
> It loops 8 times, and count is 8192 > 8000 so the time report is made.
> 
> First the seconds element of elapsed time is used to calculate how many
> chunks of 8000 octets should have arrived.  Next the microsecond element
> is used to calculate how many additional octets should have arrived 
> (1,000,000 / 125 = 8000).
> 
> Consider the following:
> 
> 	sec		usec
> ------------------------------------
> start    5              998,000
> now      7               22,000 (1.024 sec later when 
>                                  8192 octets arrive)
> 
> The calculation yields:
> 
> 1. (7 - 5) * 8000 = 16,000
> 2. 16,000 + ((22,000 - 998,000)/125) = 8,192 octets should have arrived
> 
> This calculation, however, assumes no unwanted delays from the Linux scheduler.
> 
> zttest.c is a user space program.  There is no
> guaranteed latency between the 8th read and the refresh of the "now"
> timestamp.  A long delay could jack up the expected number of octets and
> make the percentage calculation go below 100%.
> 
> The general Linux scheduling algorithm can insert some long delays where
> and when you don't want them.  All of the numbers reported in this thread are
> in the 99.9xxxx% range aren't they?  Given how this code is being
> run, I think that's fair indication that the TDM samples are coming at
> the expected rate.  If you need better accuracy, then you'll need to put
> some tools into the driver code.
> 
> > 
> > So, 8000 bytes in one second is the same thing as 8192 bytes in 1.024000
> > seconds. 
> 
> Yep. 1.000000 sec that is, and that is the problem in a nutshell.

What do you mean by "the problem in a nutshell"?


> > We're still looking for the root cause as to why the TDM card is missing
> > frames "in a large percentage" of implementations, negatively impacting
> > things like spandsp. 
> 
> Frames in this context means the chunks of 8192 octets collected in zttest.
> What I understood was that frames weren't missing. Instead some of
> these reports on 8192 samples were less than 100% which suggested
> samples were not arriving in a timely fashion. I contend that zttest is
> inherently incapable of making such a determination accurately, primarily
> because the calculation depends on low latency which cannot be assumed
> in a user space program running under the general Linux scheduling
> alorithm. (You could try SCHED_FIFO policy to improve things; can give
> code chunk and advice on how to not lock up the node if needed).
> 
> > According to Steve Underwood, spandsp _did_ work
> > with the TDM card some time back and its his general feeling that 
> > something has changed that has negatively impacted it.
> 
> When I called Digium they were forthcoming about recent problems and improvements
> when asked about defects being discussed on the user list. They said there 
> have been recent firmware improvements with echo-can and some
> other stuff (the nature of which I can't remember).  Could changes or
> flaws with echo-can have affected spandsp?

Having watched the -cvs list for about six months or so, I don't remember
seeing any changes to the echo can code.

There has been several revisions of the TDM card, but I'm using the
latest one from about two weeks ago (just RMA'ed).

> I am new to Asterisk, but so far, having looked at this thread (which is
> quite long and full of lot's of hard work), the zttest code, the Digium web site,
> and the spandsp website, and having talked to Digium sales/support about
> the TDM, I think the issue belongs the spandsp community.  They may be
> able to point out an improvement to the TDM product that Digium may or
> may not implement.  Or they may need to adapt to an improvement on new TDM
> cards. It does not appear that Digium has promised support to
> the spandsp add-on function to Asterisk. I also didn't see where the spandsp
> project was committed to staying up to date with each new revision of
> TDM card - that's what the community is for.

Historically since the TDM card came out, there hasn't been any
significant support from anyone for the TDM (as lots of folks will
atest to). The key issues here seem to be:
 - spandsp apparently functions correctly with T1/E1 cards,
 - spandsp apparently did work with the TDM card several months ago, and
   without changing the card, it does not work now
 - Steve has done some detailed analysis work, and every case that I've
   heard about with the TDM involves missing inbound data (whether that
   was one or one-hundred octets I don't know)
 
> In summary, it doesn't appear that spandsp not working and zttest output
> is sufficient to cast doubt on the TDM cards.  More comparison between
> working and non-working spandsp faxing apps might give more reliable
> clues about where the problem lies. 

If you look back at the previous posts over the last six months or so,
you'll find all kinds of suggestions in terms of latency, shared
interrupts, running * with -p (Run as pseudo-realtime thread), changing
pci latency settings, pci bus construction (north & south bridges),
mobo, etc, etc. So far none of those have impacted the issue in any
significant manner. 

So what's left?