>>It might be possible to change the values slightly to judge their impact. >>I've not done the math, so not sure if changing the values has any real >>merit.
>Yes, I think it does. I'm definitely going to try some tweaks there. >For anybody interested, the reference document that I am using can >be found here: >http://www.silabs.com/public/documents/tpub_doc/dsheet/Wireline/Silicon_DAA/en/si3035.pdf >Pages 22-24 demonstrate how the sampling rate is determined for the DAA. I followed up with this and tried some different values for programming the PLL. Found that there are several ways to program the dividers to come out with the same 8000 Hz sample rate. Various combinations of divider settings seemed to yield the same results in terms of the final output frequency. I'd guess that the deviations from true 8000 Hz are most likely a function of the crystal tolerance. In order to try to adjust the problem away, it looks like I would have to target a rate of 7999.5 Hz or so. It does not appear that the PLL system can be programmed to supply any frequency adjustment to that resolution. >>I'm not a proficient programmer at all, but some experienced programmers >>use various profiling tools to help understand which routines are >> consuming >>cycles. It would seem like that could be used to help isolate the >>repetitive cpu spikes. >Yes, that sounds right on. Perhaps I'll try a little googling around to >see if anything looks useful. I tried kerneltop for this and obtained some interesting results. During a normal idle interval, I received this output: --- snip --- Linux pbx 2.4.30 #1 Sun Jun 5 00:13:59 EDT 2005 i686 unknown Sampling_step: 2 | Address range: 0xc0105000 - 0xc0203a41 address function ...... 2005-06-23/17:05:25 ...... ticks ( 103) c0106d10 default_idle 101 c01ff1f0 __generic_copy_to_user 2 --- snip --- During an interval with a cpu spike, I would see this: --- snip --- Linux pbx 2.4.30 #1 Sun Jun 5 00:13:59 EDT 2005 i686 unknown Sampling_step: 2 | Address range: 0xc0105000 - 0xc0203a41 address function ...... 2005-06-23/17:09:46 ...... ticks ( 103) c0106d10 default_idle 87 c0200d40 bitreverse 8 c0109888 handle_IRQ_event 6 c01ff1f0 __generic_copy_to_user 2 --- snip --- The obvious difference is time being spent in the kernel's interrupt handling code as well as the kernel's bit reverse code which I believe is part of the CRC32 functions. I think the above does begin to give us a picture of what's going on in general. The built-in profiler can apparently only provide results for drivers that have been statically compiled into the kernel. It won't show information for modules. It looks like oprofile may be able to provide more insight into what wcfxo and zaptel are doing, so I think I'll give that a try next. _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
