> > 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 _______________________________________________ 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