[Asterisk-Users] Problems with TDM400P card

[Rich Adamson]

> > To help identify the source of the delays, I built a new system this
> > weekend from scratch. When that is complete, I'll use it to compare
> > the differences in motherboards, OS distro's, and maybe kernel versions.
> 
> Very good Rich, the results of that work will be very interesting.

And now for the results (thus far)....

Built a new system from scratch using ECS PM800-M2 Mobo, ide 7200 rpm
drive, 2.7ghz celery, 512 meg, fedora 3 (v2.6.9-1.667, no updates).

With TDM04b installed only (new system):
 - 'vmstat 1' shows 100% cpu every 8 seconds with no significant changes
    while processing a single pstn or iax call.
 - zttest shows 99.987793% consistently with no significant variation
 - wctdm using Int #11 (no sharing)

With Digium X100P installed only (new system):
 - 'vmstat 1' shows 12% cpu every 8 seconds with no significant changes
   while processing a single pstn or iax call.
 - zttest shows 99.987793% consistently with no significant variation
 - wcfxo using Int #11 (no sharing)

Conclusions:
 - the vmstat indication of 12% peak on x100p vs 100% peak on TDM04b
   suggests that each fxo module/port is being accessed by asterisk
   every 8 seconds, and not likely to be a kernel config/version issue.
 - the zttest ran exactly the same error rate regardless of the x100p
   vs TDM04b, and regardless of the significant changes in the Mobo.
   Since the x100p uses wcfxo and the TDM uses wctdm, either the same
   issue exists in both drivers (or its zaptel), or, its a Tigerjet 
   pci issue.
 - the 2.2ghz vs 2.7ghz celery processor differences had zero impact.
 - the kernel for RHv9 (2.4.20-31.9) vs Fedora3 (2.6.9-1.667) appears
   to have no significant impact on the TDM/pci throughput or
   interrupt servicing.
 - the improvement in zttest results from 99.975586% on a three year old
   mobo vs 99.987793% for the newer PM800-M2 mobo is _almost_ insignificant
   but its unknown whether the mobo, the slight cpu speed increase, or
   the kernel differences actually contributed to that slight improvement.
   (I have not tried spandsp on the new system.)
 - a modified zttest.c run on both systems to show the delays in reading
   8192 bytes from the TDM card as 23,850 microseconds lateness on
   the old mobo, and 24,000 microsecond lateness on the new system. No
   significant change resulting from the differences in mobo, pci
   structure, interrupt structure, cpu speed, quantity of ram, kernel
   differences (v2.4 vs v2.6), etc.

All of the above testing would suggest that in order to make the TDM04b
(and x100p) work reliably with things like spandsp (and probably better
echo cancellation), one or more of the following would need to be 
investigated:
 - issues with the Tigerjet pci controller on the TDM & X100p cards,
 - since asterisk code was not running when zttest was running, code
   within asterisk should not an issue.
 - with only wctdm/wcfxo/zaptel drivers loaded (no asterisk), the vmstat
   results suggest the OS is still doing something with the cards that
   is not being done when used on FreeBSD. Whatever that is, could "that"
   be the reason for the 24,000 microsecond lateness? (Probably not
   likely since that peak traffic occurs every 8 seconds, and that
   peak does not impact the 24,000 microsecond lateness measured every
   second.) Could there be code in wctdm/tcfxo/zaptel that is instigating
   the unusual vmstat results? Are the vmstat results a smokescreen?
 - is there anything unusual about the zap/pseudo OS interface that would
   impact these measurements (eg, is this the correct way to measure it)?
 
Any suggestions on the above would be greatly appreciated!!!

Rich