[Asterisk-Users] Re: Problems with TDM400P card

[Mike Mueller]

On Thu, May 05, 2005 at 07:57:49AM -0400, Andrew Kohlsmith wrote:
> 
> My two fax machines (Canon IR3300 and Panasonic something-or-other) do not 
> work with the TDM400P either on fax reception; fax transmission works fine.  
> This is most certainly a TDM400P driver issue.

Yeah.  Getting smacked with a Cannon or Panasonic hurts.
> 
> Couple this with the fact that the driver now seems to pull 100% CPU every 5 
> seconds or so and it didn't before and I think we have a good case for there 
> being something weird in the driver that is causing frame slips or other 
> weirdness that is generally not audible for most people but wreaks havoc even 
> for G3 or ECM (I think that's the term for error-correcting fax) fax 
> machines.

As measured with top?
> 
> Nah; we've been down this road.  I just need a block of time to pull wctdm 
> from about a year back and basically do a binary search until I find where 
> the driver started pulling this insane CPU use every 5 seconds or so.

diff 'em. It's much faster :).

If you use an old driver revision then you can receive faxes? Can you
use an old TDM driver in a new Asterisk rev?
> 
> You comments on zttest and kernel process scheduler are very important, IMO.   
> I don't know, I think Digium made a horrible mistake by not including even a 
> small buffer on these cards.

What was that? No buffering? That means its tx/rx ISR should have priority
over those servicing interfaces with buffering.  Is that happening?

So maybe you won't find a significant diff between an old TDM driver and
a new one.  Instead, the problem may be coming from another driver that
is not letting the TDM driver service its interrupts on time.

Assuming there are a lot of samples from TDM missing - and that
lack of buffering makes that plausible - this could be measured in a
working system by dumping TDM input into a file over a 10 minute period
as measured by gettimeofday and determining the amount of shrinkage that
occurred.  Using a long time period like 10m will reduce the effects of
Linux scheduler latency and it will ensure capture of the 5-second-100%-CPU 
effect.

-- 
Mike