[Asterisk-Users] Problems with TDM400P card

[Michael Welter]

Rich Adamson wrote:
>>>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!!!
> 
Hello Rich,

You're doing outstanding research.

As I recall, I've seen CPU spikes every four seconds, and I believe it 
was on an Intel mobo with a P4 w/ hyperthreading.

Mike