Re: [Flexradio] Buffer / Sample Rate
Note that this feature was fixed in recent SVNs. ;) Eric Wachsmann FlexRadio Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] radio.biz] On Behalf Of Kirb Nesbitt Sent: Sunday, October 28, 2007 12:31 AM Cc: flexradio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate Steve, ok, if you go into setup, then: DSPOptions tab . You should have a Buffer Size setting. One value for Receive and one for Transmit. I find that if you run with Receive set to 4096 and then Transmit at a smaller value you have to make sure that each time you start PowerSDR you go in and (re)select the receive buffer value. Otherwise the receive level calibration will be off by 6-8 dB. It would appear that in spite of calibrating against the receive value it subsequently uses the transmit buffer value on each successive re-start. Obviously an beta bug and likely will get fixed once Eric returns from vacation and sees my bug filing. ___ 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/
Re: [Flexradio] Buffer / Sample Rate
I experienced Kirb's description of the symptoms with SVN 1680 on an SDR-1000. It definitely threw the level calibration off. 73, Steve N6VL -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Wachsmann Sent: Wednesday, October 31, 2007 9:53 AM To: [EMAIL PROTECTED] Cc: flexradio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate Note that this feature was fixed in recent SVNs. ;) Eric Wachsmann FlexRadio Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] radio.biz] On Behalf Of Kirb Nesbitt Sent: Sunday, October 28, 2007 12:31 AM Cc: flexradio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate Steve, ok, if you go into setup, then: DSPOptions tab . You should have a Buffer Size setting. One value for Receive and one for Transmit. I find that if you run with Receive set to 4096 and then Transmit at a smaller value you have to make sure that each time you start PowerSDR you go in and (re)select the receive buffer value. Otherwise the receive level calibration will be off by 6-8 dB. It would appear that in spite of calibrating against the receive value it subsequently uses the transmit buffer value on each successive re-start. Obviously an beta bug and likely will get fixed once Eric returns from vacation and sees my bug filing. ___ 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/ ___ 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/
Re: [Flexradio] Buffer / Sample Rate
Kirb, Where are the separate tx and rx DSP buffers at in PowerSDR setup? I can't find them! 73, Steve N6VL -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirb Nesbitt Sent: Wednesday, October 24, 2007 3:08 PM To: flexradio@flex-radio.biz Subject: [Flexradio] Buffer / Sample Rate Boy o boy, must have had a brain bubble or something, When I said, ..running the receive buffers at 4096 to maintain filter performance while reducing the receive buffers to 256 (cw) or 512., this was in fact code for, set the Receive DSP buffers to 4096 and the TRANSMIT DSP buffers to 256 or 512 initially. In actuality, under normal operation I don't notice much of a difference between the 256 and 512 Tx buffer setting in so far as keying latency is concerned (ext keyer via com port), provided your running at 192k samples. To get to the 35-40 wpm scenario you really have to watch the size of the audio and driver buffers in addition to the DSP stuff mentioned above. I think sometimes those two get neglected and left at the max values simply because they work fine most of the time for ssb operation. 73, Kirb - VE6IV -- Ken, I wish I could comment on the F5000 in the config you speak of however I can state that the SDR-1000 runs without issue for me at a DSP buffer setting of 256 and 512 both at 192k. The key for me was two-fold effectively fine-tuning the buffers for smooth operation. First, make sure your running PowerSDR in a above normal process priority setting. I'm not sure what the equivalent setting equates to with the F5000 however the same concept should apply. Secondly, set the DSP buffer and sampling rate parameters *first*, running the receive buffers at 4096 to maintain filter performance while reducing the receive buffers to 256 (cw) or 512. Next, tweak your audio and driver buffers until you find a combination that works well with the DSP buffers/sampling values defined above. As John mentioned, the two (audio and driver buffers) should initially be of the same value. Depending on your PC platform you will want to reduce (or increase) those two values in concert (and then individually) until you have hitless audio and no snapping on tx/rx change-over. My hardware config here is pretty mainstream; Dedicated XP box running a Pentium D dual-core (3.60 Ghz) and 2 MB of RAM. The split DSP buffers (Tx/Rx) is for a cw op, like having your cake and eating it too. In previous implementations of the code, one would have to accept a certain amount of transmit and timing latency to ensure that receiver performance was not impacted too greatly with overly smallish buffers. Cheers 73! Kirb - VE6IV --- ___ 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/ ___ 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/
Re: [Flexradio] Buffer / Sample Rate
Steve, ok, if you go into setup, then: DSPOptions tab . You should have a Buffer Size setting. One value for Receive and one for Transmit. I find that if you run with Receive set to 4096 and then Transmit at a smaller value you have to make sure that each time you start PowerSDR you go in and (re)select the receive buffer value. Otherwise the receive level calibration will be off by 6-8 dB. It would appear that in spite of calibrating against the receive value it subsequently uses the transmit buffer value on each successive re-start. Obviously an beta bug and likely will get fixed once Eric returns from vacation and sees my bug filing. Cheers es 73! Kirb - VE6IV -- Steve Kallal wrote: Kirb, Where are the separate tx and rx DSP buffers at in PowerSDR setup? I can't find them! 73, Steve N6VL ___ 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/
Re: [Flexradio] Buffer / Sample Rate
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
Re: [Flexradio] Buffer / Sample Rate
I may be preaching to the choir here but I think it should be mentioned that everyone that is having latency issues may be able to pinpoint their problems using a little utility called AUTORUNS. It has worked for me and I never have any Latency issues anymore.(Be Careful) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dudley Hurry Sent: Wednesday, October 24, 2007 1:04 AM To: Rob Dennison; FlexRadio@flex-radio.biz; [EMAIL PROTECTED] Subject: Re: [Flexradio] Buffer / Sample Rate 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
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
Re: [Flexradio] Buffer / Sample Rate
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
Re: [Flexradio] Buffer / Sample Rate
Thanks Peter, My list of things to tweak is getting pretty short now. What a great radio and great reflector group... Best regards, Rob AB7CF On Wed, 24 Oct 2007 12:21:36 -0400 Peter G. Viscarola [EMAIL PROTECTED] writes: Hi Rob (et al), Ive 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. Thats why I always advise folks: Once you get your system to a point where its working acceptably, DO NOT update any drivers. Windows OS updates are typically fine, but dont routinely do driver updates its just asking for trouble. I guess thats 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
Re: [Flexradio] Buffer / Sample Rate
Hello and thanks for the replies. However I must be missing something here. I am still running 1.10.2 with XP along with the Flex5000, and I don't see where my question actually had gotten answered. My CPU is a duel 2.4 Intel Processor with 4 gigs of memory. My statement and question was that some people are using 192K sampling rate with 256k for buffering. Are these settings being used in Safe Mode 1 or in Normal Mode? The reason I had asked, I can only run 192k sampling rate at (512k Buffering) When I try to go to 256k buffering, the program crashes. Again, other people were using 192/256 before any new SVNs. How were they able to achieve these settings without any issues? My head is thick, so you have to pound harder!! Ken K3YI Gerald Youngblood wrote: See comments in the text below. Gerald Youngblood, K5SDR FlexRadio Systems Ph: 512-535-4713 Fax: 512-233-5143 Email: [EMAIL PROTECTED] Web: www.flex-radio.com -Original Message- From: John P Basilotto W5GI [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 8:31 AM To: 'Bill Winkis'; [EMAIL PROTECTED]; 'Gerald Youngblood' Subject: RE: [Flexradio] Buffer / Sample Rate Importance: High Bill, I am forwarding your email to gerald for a response. I heard your QSO this morning but only the DX station who said you had a problem with the audio being overdriven the same as someone else. Use your TX meter in the MIC setting position, you want to keep audio peaks below 0 dB and above -5. CUL John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512-535-5266 Fax512-233-5143 www.flex-radio.com -Original Message- From: Bill Winkis [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:48 PM To: john; [EMAIL PROTECTED]; FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate I agree ... my best preformance is 512/192 .. but it runs fine at 256/192 ..now this is a Intel dual/6700 with 4 Gigs..and the only item on the machine is the 5000A. John: I upgraded SVN today and see that there are now Buffers for TX RX ..explain the merits...?? This was to allow us to set smaller transmitter buffers to shorten TR time for CW and digital modes. The DSP receive buffer size determines the filter shape so higher is better. The transmit buffer determines the length of time it takes to go from receive to transmit. It will also change the filter shape factor on transmit so the larger sizes will give sharper skirts. You can see the difference on the panadapter while transmitting. Overall, you will want to use the smallest driver and audio buffer size that allows stable operation. The driver and audio buffers should be set to the same value. You can then set the DSP receive buffer to the best comprimise between filter shape and latency. This will be a personal preference. Also I sweep the the headphone and the Line Out (out to 7K) and they both are flat, with one of the best return audio's I have ever heard from a transceiver...(Even better then the Kenwood 870) With out a print I am assuming the line out is mono and unbalanced...the headphone is Stereo. But what is the pick up on the headphone's right left Channels..?? I am not sure I understand the questions? Bill KC4PE - Original Message - From: john [EMAIL PROTECTED] To: [EMAIL PROTECTED]; FlexRadio@flex-radio.biz Sent: Monday, October 22, 2007 5:00 PM Subject: Re: [Flexradio] Buffer / Sample Rate Ken, Try increasing the Driver buffer size. John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512 535-5266 FAX512 233-5143 www.flex-radio.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Monday, October 22, 2007 8:03 AM To: FlexRadio@flex-radio.biz Subject: [Flexradio] Buffer / Sample Rate I hear some people are using 192k sampling rate with 256k buffering. Are they doing this in safe mode 1 or in the normal mode? I am running an Intel duel processor 2.4 with 4 gigs of memory with the two high speed 7200 rpm western digital hard drives in a Raid 0 configuration using XP for the operator system. The rig is the new Flex5000. The Power SDR seems to run its best at 192K sampling rate but at 512K for the Buffer in the Normal mode. I have tried the 256k buffering and it ends up crashing. Any input on all of this would be a great help to aid towards my understanding! Thank you. Ken K3YI ___ 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
Re: [Flexradio] Buffer / Sample Rate
Ken, My initial comment is try it. If it works, great. If not experiment. It sounds like you have experimented and have hit the wall. :-) It is difficult to say if one configuration over another will work or not without first trying it out since CPU type/speed does not provide an adequate metric to make a predictable determination. In addition to CPU, the Firewire transfer rate has a big influence on performance and stability too. If your Firewire host bus controller is sharing IRQs with other devices, the effective throughput my be so low that additional buffers are needed. The difference between Safe Mode 1 (aka DefCon 1) as compared to Normal mode is not in how it effectively it transfers data, (although it has a small effect) but how well the hardware driver recovers (and this is very subjective, IMHO) from long duration DPCs (delayed procedure calls). DPCs also add big time latency and they are entirely a hardware based phenomenon. Now, with all that said, using 256k hardware/audio buffers at a 192 KHz sampling rate on any computer is pushing the envelope a bit, as you have discovered. If it is reduction in latency you are after, use the 256K buffers and start dropping the sampling rate to achieve the latency performance you are after. I personally never operate at 192KHz. I prefer using very large DSP buffers, (especially on RX) and I really don't need to look at 180 KHz worth of spectrum. Also, the signals a awfully squished up on the panadapter at that sampling rate and I like looking at the waveform characteristics (yes, I have a stripped beanie with a propeller on it. It looks great with my plaid pants, tweed jacket, green sneakers and the worn out plastic pocket protector). -Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Tuesday, October 23, 2007 5:21 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate Hello and thanks for the replies. However I must be missing something here. I am still running 1.10.2 with XP along with the Flex5000, and I don't see where my question actually had gotten answered. My CPU is a duel 2.4 Intel Processor with 4 gigs of memory. My statement and question was that some people are using 192K sampling rate with 256k for buffering. Are these settings being used in Safe Mode 1 or in Normal Mode? The reason I had asked, I can only run 192k sampling rate at (512k Buffering) When I try to go to 256k buffering, the program crashes. Again, other people were using 192/256 before any new SVNs. How were they able to achieve these settings without any issues? My head is thick, so you have to pound harder!! Ken K3YI Gerald Youngblood wrote: See comments in the text below. Gerald Youngblood, K5SDR FlexRadio Systems Ph: 512-535-4713 Fax: 512-233-5143 Email: [EMAIL PROTECTED] Web: www.flex-radio.com -Original Message- From: John P Basilotto W5GI [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 8:31 AM To: 'Bill Winkis'; [EMAIL PROTECTED]; 'Gerald Youngblood' Subject: RE: [Flexradio] Buffer / Sample Rate Importance: High Bill, I am forwarding your email to gerald for a response. I heard your QSO this morning but only the DX station who said you had a problem with the audio being overdriven the same as someone else. Use your TX meter in the MIC setting position, you want to keep audio peaks below 0 dB and above -5. CUL John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512-535-5266 Fax512-233-5143 www.flex-radio.com -Original Message- From: Bill Winkis [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:48 PM To: john; [EMAIL PROTECTED]; FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate I agree ... my best preformance is 512/192 .. but it runs fine at 256/192 ..now this is a Intel dual/6700 with 4 Gigs..and the only item on the machine is the 5000A. John: I upgraded SVN today and see that there are now Buffers for TX RX ..explain the merits...?? This was to allow us to set smaller transmitter buffers to shorten TR time for CW and digital modes. The DSP receive buffer size determines the filter shape so higher is better. The transmit buffer determines the length of time it takes to go from receive to transmit. It will also change the filter shape factor on transmit so the larger sizes will give sharper skirts. You can see the difference on the panadapter while transmitting. Overall, you will want to use the smallest driver and audio buffer size that allows stable operation. The driver and audio buffers should be set to the same value. You can then set the DSP receive buffer to the best comprimise between filter shape and latency. This will be a personal preference. Also I sweep the the headphone and the Line Out (out to 7K) and they both are flat, with one of the best return audio's I have ever
Re: [Flexradio] Buffer / Sample Rate
Tim, thank you so much for your information. I didn't get the answer that I thought I would get, but got more then I expected! I am using the on board Fire wire on the Intel board. The information that you had given broadened my understanding a little more then I had before! I am all about experimenting, but lacking information that allows one to start in a particular direction. I will look for another Fire Wire card and start there. Maybe I should setter for 192/512 but I rather keep pushing the envelope until I know I had enough. I try to read as much as I can through this reflector before asking any questions, but maybe I miss a few items from time to time. Thank you Tim and to all of the others who respond. Life is good! Ken K3YI Tim Ellison wrote: Ken, My initial comment is try it. If it works, great. If not experiment. It sounds like you have experimented and have hit the wall. :-) It is difficult to say if one configuration over another will work or not without first trying it out since CPU type/speed does not provide an adequate metric to make a predictable determination. In addition to CPU, the Firewire transfer rate has a big influence on performance and stability too. If your Firewire host bus controller is sharing IRQs with other devices, the effective throughput my be so low that additional buffers are needed. The difference between Safe Mode 1 (aka DefCon 1) as compared to Normal mode is not in how it effectively it transfers data, (although it has a small effect) but how well the hardware driver recovers (and this is very subjective, IMHO) from long duration DPCs (delayed procedure calls). DPCs also add big time latency and they are entirely a hardware based phenomenon. Now, with all that said, using 256k hardware/audio buffers at a 192 KHz sampling rate on any computer is pushing the envelope a bit, as you have discovered. If it is reduction in latency you are after, use the 256K buffers and start dropping the sampling rate to achieve the latency performance you are after. I personally never operate at 192KHz. I prefer using very large DSP buffers, (especially on RX) and I really don't need to look at 180 KHz worth of spectrum. Also, the signals a awfully squished up on the panadapter at that sampling rate and I like looking at the waveform characteristics (yes, I have a stripped beanie with a propeller on it. It looks great with my plaid pants, tweed jacket, green sneakers and the worn out plastic pocket protector). -Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Tuesday, October 23, 2007 5:21 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate Hello and thanks for the replies. However I must be missing something here. I am still running 1.10.2 with XP along with the Flex5000, and I don't see where my question actually had gotten answered. My CPU is a duel 2.4 Intel Processor with 4 gigs of memory. My statement and question was that some people are using 192K sampling rate with 256k for buffering. Are these settings being used in Safe Mode 1 or in Normal Mode? The reason I had asked, I can only run 192k sampling rate at (512k Buffering) When I try to go to 256k buffering, the program crashes. Again, other people were using 192/256 before any new SVNs. How were they able to achieve these settings without any issues? My head is thick, so you have to pound harder!! Ken K3YI Gerald Youngblood wrote: See comments in the text below. Gerald Youngblood, K5SDR FlexRadio Systems Ph: 512-535-4713 Fax: 512-233-5143 Email: [EMAIL PROTECTED] Web: www.flex-radio.com -Original Message- From: John P Basilotto W5GI [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 8:31 AM To: 'Bill Winkis'; [EMAIL PROTECTED]; 'Gerald Youngblood' Subject: RE: [Flexradio] Buffer / Sample Rate Importance: High Bill, I am forwarding your email to gerald for a response. I heard your QSO this morning but only the DX station who said you had a problem with the audio being overdriven the same as someone else. Use your TX meter in the MIC setting position, you want to keep audio peaks below 0 dB and above -5. CUL John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512-535-5266 Fax512-233-5143 www.flex-radio.com -Original Message- From: Bill Winkis [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:48 PM To: john; [EMAIL PROTECTED]; FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Buffer / Sample Rate I agree ... my best preformance is 512/192 .. but it runs fine at 256/192 ..now this is a Intel dual/6700 with 4 Gigs..and the only item on the machine is the 5000A. John: I upgraded SVN today and see that there are now Buffers for TX RX ..explain the merits...?? This was to allow us to set smaller
Re: [Flexradio] Buffer / Sample Rate
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/ FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/
[Flexradio] Buffer / Sample Rate
Ken, I wish I could comment on the F5000 in the config you speak of however I can state that the SDR-1000 runs without issue for me at a DSP buffer setting of 256 and 512 both at 192k. The key for me was two-fold effectively fine-tuning the buffers for smooth operation. First, make sure your running PowerSDR in a above normal process priority setting. I'm not sure what the equivalent setting equates to with the F5000 however the same concept should apply. Secondly, set the DSP buffer and sampling rate parameters *first*, running the receive buffers at 4096 to maintain filter performance while reducing the receive buffers to 256 (cw) or 512. Next, tweak your audio and driver buffers until you find a combination that works well with the DSP buffers/sampling values defined above. As John mentioned, the two (audio and driver buffers) should initially be of the same value. Depending on your PC platform you will want to reduce (or increase) those two values in concert (and then individually) until you have hitless audio and no snapping on tx/rx change-over. My hardware config here is pretty mainstream; Dedicated XP box running a Pentium D dual-core (3.60 Ghz) and 2 MB of RAM. The split DSP buffers (Tx/Rx) is for a cw op, like having your cake and eating it too. In previous implementations of the code, one would have to accept a certain amount of transmit and timing latency to ensure that receiver performance was not impacted too greatly with overly smallish buffers. Cheers 73! Kirb - VE6IV --- Hello and thanks for the replies. However I must be missing something here. I am still running 1.10.2 with XP along with the Flex5000, and I don't see where my question actually had gotten answered. My CPU is a duel 2.4 Intel Processor with 4 gigs of memory. My statement and question was that some people are using 192K sampling rate with 256k for buffering. Are these settings being used in Safe Mode 1 or in Normal Mode? The reason I had asked, I can only run 192k sampling rate at (512k Buffering) When I try to go to 256k buffering, the program crashes. Again, other people were using 192/256 before any new SVNs. How were they able to achieve these settings without any issues? My head is thick, so you have to pound harder!! Ken K3YI ___ 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/
Re: [Flexradio] Buffer / Sample Rate
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/ 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/ FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/
[Flexradio] Buffer / Sample Rate
I hear some people are using 192k sampling rate with 256k buffering. Are they doing this in safe mode 1 or in the normal mode? I am running an Intel duel processor 2.4 with 4 gigs of memory with the two high speed 7200 rpm western digital hard drives in a Raid 0 configuration using XP for the operator system. The rig is the new Flex5000. The Power SDR seems to run its best at 192K sampling rate but at 512K for the Buffer in the Normal mode. I have tried the 256k buffering and it ends up crashing. Any input on all of this would be a great help to aid towards my understanding! Thank you. Ken K3YI ___ 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/
Re: [Flexradio] Buffer / Sample Rate
Ken, Try increasing the Driver buffer size. John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512 535-5266 FAX512 233-5143 www.flex-radio.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Monday, October 22, 2007 8:03 AM To: FlexRadio@flex-radio.biz Subject: [Flexradio] Buffer / Sample Rate I hear some people are using 192k sampling rate with 256k buffering. Are they doing this in safe mode 1 or in the normal mode? I am running an Intel duel processor 2.4 with 4 gigs of memory with the two high speed 7200 rpm western digital hard drives in a Raid 0 configuration using XP for the operator system. The rig is the new Flex5000. The Power SDR seems to run its best at 192K sampling rate but at 512K for the Buffer in the Normal mode. I have tried the 256k buffering and it ends up crashing. Any input on all of this would be a great help to aid towards my understanding! Thank you. Ken K3YI ___ 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/ ___ 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/
Re: [Flexradio] Buffer / Sample Rate
I agree ... my best preformance is 512/192 .. but it runs fine at 256/192 ..now this is a Intel dual/6700 with 4 Gigs..and the only item on the machine is the 5000A. John: I upgraded SVN today and see that there are now Buffers for TX RX ..explain the merits...?? Also I sweep the the headphone and the Line Out (out to 7K) and they both are flat, with one of the best return audio's I have ever heard from a transceiver...(Even better then the Kenwood 870) With out a print I am assuming the line out is mono and unbalanced...the headphone is Stereo. But what is the pick up on the headphone's right left Channels..?? Bill KC4PE - Original Message - From: john [EMAIL PROTECTED] To: [EMAIL PROTECTED]; FlexRadio@flex-radio.biz Sent: Monday, October 22, 2007 5:00 PM Subject: Re: [Flexradio] Buffer / Sample Rate Ken, Try increasing the Driver buffer size. John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512 535-5266 FAX512 233-5143 www.flex-radio.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Monday, October 22, 2007 8:03 AM To: FlexRadio@flex-radio.biz Subject: [Flexradio] Buffer / Sample Rate I hear some people are using 192k sampling rate with 256k buffering. Are they doing this in safe mode 1 or in the normal mode? I am running an Intel duel processor 2.4 with 4 gigs of memory with the two high speed 7200 rpm western digital hard drives in a Raid 0 configuration using XP for the operator system. The rig is the new Flex5000. The Power SDR seems to run its best at 192K sampling rate but at 512K for the Buffer in the Normal mode. I have tried the 256k buffering and it ends up crashing. Any input on all of this would be a great help to aid towards my understanding! Thank you. Ken K3YI ___ 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/ ___ 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/ ___ 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/
