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
_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
