Hi Rob (et al),
I've noticed the spikes in CPU utilization when running DXLabs SpotCollector also. Dudley is exactly correct: Raising the scheduling priority for PowerSDR can help with the "pops" in some cases, especially when PowerSDR is competing with something else (like SpotCollector) for CPU time. The problem is that the signal processing path involves many steps, and an unexpectedly long delay in any ONE of those steps can cause a signal discontinuity leading to a "pop" in the output. This is part of the challenge of doing this type of processing on a general purpose operating system and on a variety of hardware platforms. Just a SMALL CHANGE in a seemingly unrelated device driver (such as for a video card or NIC) can cause your Firewire or USB device to experience problems. That's why I always advise folks: Once you get your system to a point where it's working acceptably, DO NOT update any drivers. Windows OS updates are typically fine, but don't routinely do driver updates... it's just asking for trouble. I guess that's a built-in advantage of the 5000C over the 5000A - Flex presumably will carefully select and configure the whole SUITE of hardware and software (the CPU, the bus choices, every device, and every version of every driver) to ensure acceptable performance. It really is a rather complex system integration problem. de Peter K1PGV From: Rob Dennison [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 10:34 AM To: [EMAIL PROTECTED] Cc: FlexRadio@flex-radio.biz; Peter G. Viscarola Subject: Re: [Flexradio] Buffer / Sample Rate Thanks Dudley, I kinda thought that was the case. Wanted to make sure changing the priority wasn't fouling up processing priorities vs. driver priorities. Have been trying to visually correlate processing load with spot arrivals so I could verify spot process was the cause of CPU utilization spikes, but recently (with my filtering setup) the interval between spots has been longer than my attention span. ;o))~ I bought a separate computer for PowerSDR and DXLabs. No email, General IE browsing only when downloading new programs. DXLabs does use the IE layer in the background for uploading QSL data and spot collecting. I had been considering moving DXLabs to yet a third computer. (What, another mouse and keyboard?) But with the higher priority for PowerSDR, will stick with the current lash up. 73's Rob AB7CF On Wed, 24 Oct 2007 01:04:29 -0500 Dudley Hurry <[EMAIL PROTECTED]> writes: Rob, I am going to jump in the middle of this thread to say that the process priority that is in the PowerSDR Setup is just the same as if you went into Windows Task Manager, highlighted PowerSDR.exe process, right clicked, Set Priority. This gives PowerSDR a higher processing priority (compared to other programs) so that it might overcome or jump ahead of other lower processes. Helps if there is something else causing issues.. Sometimes programs and devices creates a process, that has been rendered useless and is just hanging around and not needed, or has a long delay before being serviced or complete a task. The ethernet NICs are bad about this as is USB NICs, this is one reason why when DXLabs (email programs, WEB browsers, CAD programs, etc) is calling for a spot, and it's servers respond, there is a long delay and this is what causes the occasional pops.. Don't use the ethernet, stop firewalls and Spam filters, it all runs much better, but this is not piratical, so upping the priority will help, you can also lower others.. Now where is that Quad Core?? HI HI Hope this helps, Dudley WA5QPZ At 05:49 AM 10/24/2007, Rob Dennison wrote: Hi Peter, I've been following this discussion with great interest. Can you shed any light on how the options in (PowerSDR Setup > General > Options > Process Priority) relate to overall performance including the low level buffer utilization etc, Also how it affects PowerSDR processes relationship to other none PowerSDR processes? I have PowerSDR running more smoothly (no pops or dropouts) since I upped it's Process Priority to "Above Normal" though I have no idea why. My buffer size is 4096 with a sample rate of 192kHz. (~50 interrupts/sec?) Normally, I would think increasing the buffer size with a given sample rate would decrease the number of interrupts and DPC's. Thus as the sample rate goes up so should the buffer size (to decrease OS overhead.) Yet the larger the buffer the longer it would take a given speed CPU to process it increasing the process latency. (Though I'm sure it's not so simple.) To confuse matters I also have DXLabs running. The only CPU intensive DXLabs operation is a sort function when a new spot comes in. CPU utilization ranges from about 17.5% to a to an occasional high of about 60%. Normally (90% of the time) CPU utilization ranges in the 15% to 20% range. Thanks in advance for any insights, 73's Rob AB7CF On Tue, 23 Oct 2007 20:33:21 -0400 "Peter G. Viscarola" <[EMAIL PROTECTED]> writes: > > > DPCs also add "big time" latency and they are entirely a hardware > based phenomenon. > > I'm sorry to have to correct this again, but DPCs are most certainly > not > "entirely a hardware based phenomenon." They're entirely a driver > based > phenomenon. > > Your note started by talking about ISR (interrupt) latency. But in > this > case you're talking about DPC-to-ISR latency. I'm sorry, but these > are > different concepts entirely. > > DPCs are simply callbacks from the OS to a driver, to allow that > driver > to perform some less-than-time-critical processing while the OS > remains > entirely hardware interruptible and (almost always) before returning > to > user mode. > > While DPCs can add latency TO OTHER DPCs they can NOT contribute to > hardware interrupt latency (unless interrupts are disabled on the > device > in question while all or part of the DPC runs, which would be a > broken > design for a driver that supports having multiple requests > outstanding > simultaneously). > > The whole idea of using DPCs in Windows is to help keep interrupt > latency as low as possible, by Deferring (the "D" in "DPC") all but > the > most time-critical tasks so that they can be processed with > hardware > interrupts fully enabled (and thus not blocking other device's > interrupts). > > I'm not saying that abnormally long-running DPCs aren't a problem > in > Windows. They can be. If DriverA (your NIC driver, for example) > has a > very long running DPC, it is possible that the DPC for your > Firewire > card could get "stuck" behind DriverA's long-running DPC and thus > experience increased (perhaps even unacceptable) ISR-to-DPC > latency. > Note that the problem here is with DriverA and can be avoided by > (a) > trying a new DriverA, (b) swapping NIC cards. > > > > > but how well the hardware driver "recovers" (and this is very > subjective, IMHO) > > from long duration DPCs (delayed procedure calls). > > > > The typical way we build drivers that tolerate longer ISR-to-DPC > latency > is to do more in the driver's ISR. THIS adds Interrupt latency to > other > devices in the system, and is thus highly discouraged. > > It would be most enlightening to know how the driver in question > achieves this. Can you please supply us some more details about > this > area? Or is the driver open source, so we can "use the source, > Luke"? > > > de Peter K1PGV > > > _______________________________________________ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: > http://www.mail-archive.com/flexradio%40flex-radio.biz/ <http://www.mail-archive.com/flexradio@flex-radio.biz/> > FlexRadio Knowledge Base: http://kb.flex-radio.com/ > FlexRadio Homepage: http://www.flex-radio.com/ > > > _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ <http://www.mail-archive.com/flexradio@flex-radio.biz/> FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071024/6854dd11/attachment.html _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/
