On Thu, May 05, 2005 at 12:11:51PM -0400, Andrew Kohlsmith wrote: > On May 5, 2005 11:13 am, Mike Mueller wrote: > > > What was that? No buffering? That means its tx/rx ISR should have priority > > over those servicing interfaces with buffering. Is that happening? > > It's one of the primary reasons these cards are *so* interrupt and system > sensitive. > > But remember; system didn't change, drivers did. the problem was not there > with earlier drivers and is now. Therefore, since everything else has > remained constant, the problem is with the drivers.
Sounds like the problem is isolated. So you have a system that works with the old driver revision and doesn't work with the new driver revision? Can you identify a working revision and an early broken revision so we can do a diff and code review? > > > Assuming there are a lot of samples from TDM missing - and that > > lack of buffering makes that plausible - this could be measured in a > > working system by dumping TDM input into a file over a 10 minute period > > as measured by gettimeofday and determining the amount of shrinkage that > > occurred. Using a long time period like 10m will reduce the effects of > > Linux scheduler latency and it will ensure capture of the 5-second-100%-CPU > > effect. > > Well I think we're missing frames because the driver is holding the system > hostage for such a long amount of time every so often. Steve's proposed a > couple of tests for measuring this, we just need to get off our duffs and do > it. :-) Do you need to? Seems like code review time. I'll contribute a pair of eyes B-). -- 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