I'm debugging a TxFax problem whereby the fax transmission fails. I suspect interrupt latency--some interrupt routine is holding its interrupt too long. I have all unnecessary services switched off and X is not running when I perform these tests. Some transmission are successful while others fail at random points. I've noticed that after I boot Linux, load zaptel, wcfxo, and wcfxs, and then run System Monitor, the CPU utilization spikes to 60% every 10 seconds. After I remove wcfxs the spikes stop, and system utilization stays at 0%. I have two TDM22B cards and get these spikes with either card in the system. This is an Athlon-64 3000+ CPU and Fedora Core 2. zaptel-1.0.2. Is there anyone who has a TDM card on a "quiet" system who can run System Monitor and observe CPU utilization? Thanks for your help. P.S. I do 'hdparm -u1 /dev/hdx' on the disks. -- Michael Welter Introspect Telephony Corp. Denver, Colorado US +1.303.674.2575 mike@introspect.com www.introspect.com
> I'm debugging a TxFax problem whereby the fax transmission fails. I > suspect interrupt latency--some interrupt routine is holding its > interrupt too long. I have all unnecessary services switched off and X > is not running when I perform these tests. Some transmission are > successful while others fail at random points. > > I've noticed that after I boot Linux, load zaptel, wcfxo, and wcfxs, and > then run System Monitor, the CPU utilization spikes to 60% every 10 > seconds. After I remove wcfxs the spikes stop, and system utilization > stays at 0%. > > I have two TDM22B cards and get these spikes with either card in the system. > > This is an Athlon-64 3000+ CPU and Fedora Core 2. zaptel-1.0.2. > > Is there anyone who has a TDM card on a "quiet" system who can run > System Monitor and observe CPU utilization?FYI, I see the same thing on a RHv9 2.2ghz box with a single TDM04b and no calls being processed. Top indicates 30.6% every 10 seconds. Stopping * has no impact. Stopping zaptel makes that disappear. Starting zaptel only (no asterisk) brings it back to 30.6%.
Michael Welter wrote:> I'm debugging a TxFax problem whereby the fax transmission fails. I > suspect interrupt latency--some interrupt routine is holding its > interrupt too long. I have all unnecessary services switched off and X > is not running when I perform these tests. Some transmission are > successful while others fail at random points. > > I've noticed that after I boot Linux, load zaptel, wcfxo, and wcfxs, and > then run System Monitor, the CPU utilization spikes to 60% every 10 > seconds. After I remove wcfxs the spikes stop, and system utilization > stays at 0%. > > I have two TDM22B cards and get these spikes with either card in the system. > > This is an Athlon-64 3000+ CPU and Fedora Core 2. zaptel-1.0.2. > > Is there anyone who has a TDM card on a "quiet" system who can run > System Monitor and observe CPU utilization? > > Thanks for your help. > > P.S. I do 'hdparm -u1 /dev/hdx' on the disks. > >I have a athlon xp 1600 with a gig of memory a tdm40 with 2 fxs ports and a t100p t1 hooked to a audiocoded tp260 and see minimal cpu utilization when idle. run top and see what is using the cpu. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Michael Welter wrote:> I'm debugging a TxFax problem whereby the fax transmission fails. I > suspect interrupt latency--some interrupt routine is holding its > interrupt too long. I have all unnecessary services switched off and X > is not running when I perform these tests. Some transmission are > successful while others fail at random points. > > I've noticed that after I boot Linux, load zaptel, wcfxo, and wcfxs, and > then run System Monitor, the CPU utilization spikes to 60% every 10 > seconds. After I remove wcfxs the spikes stop, and system utilization > stays at 0%. > > I have two TDM22B cards and get these spikes with either card in the system. > > This is an Athlon-64 3000+ CPU and Fedora Core 2. zaptel-1.0.2. > > Is there anyone who has a TDM card on a "quiet" system who can run > System Monitor and observe CPU utilization? > > Thanks for your help. > > P.S. I do 'hdparm -u1 /dev/hdx' on the disks. > >Forget what I just posted - after watching top for a while about every 30 seconds I see irq% go to about 30%. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
I'm seeing a correlation between the fax transmission failure and the second hand on my watch. Failures occur at about :02, :12, :22, :32, :42, and :52. This is +/- the same time as the CPU spike. Can anyone from Digium help with this? Thanks, -- Michael Welter Introspect Telephony Corp. Denver, Colorado US +1.303.674.2575 mike@introspect.com www.introspect.com
Steve Clark wrote:> > Forget what I just posted - after watching top for a while about every > 30 seconds I see irq% go to about 30%. > > Steve >What are your command line options? -- Michael Welter Introspect Telephony Corp. Denver, Colorado US +1.303.674.2575 mike@introspect.com www.introspect.com
On Thursday 02 December 2004 16:25, Andrew Kohlsmith wrote:> On December 1, 2004 02:48 pm, Juan J. Sierralta P. wrote: > > Maybe vmstat(8) could be of help instead of the so flamed top(1). > > vmstat only polls every 1 second, *but* it does give interrupt counts and > context switches per period.You can give an interval time and count to vmstat. B
On December 2, 2004 12:35 pm, Bob Goddard wrote:> > vmstat only polls every 1 second, *but* it does give interrupt counts and > > context switches per period. > > You can give an interval time and count to vmstat.from vmstat(8): delay is the delay between updates in seconds. Your granularity is still no better than 1s. :-) -A.
On Thursday 02 December 2004 18:30, Andrew Kohlsmith wrote:> On December 2, 2004 12:35 pm, Bob Goddard wrote: > > > vmstat only polls every 1 second, *but* it does give interrupt counts > > > and context switches per period. > > > > You can give an interval time and count to vmstat. > > from vmstat(8): > delay is the delay between updates in seconds. > > Your granularity is still no better than 1s. :-)The smaller the granularity the more skewed the results. 10s may be better. Either way, it is not limited to 1s. B