[hpsdr] HPSDR / PowerSDR hardware selection

[Glenn Thomas]

Well... I don't agree. On my SDR1000, I was having occasional drops 
and hiccups during both RX and TX. After shutting down everything 
else that might be running, including anti-virus and numerous system 
services that I don't think I need (i.e. indexing), the problem did 
not go away. Running the XP performance monitor at length I learned 
that every so often, for no apparent reason (nothing running other 
than PowerSDR and performance monitor), XP chooses to do something 
with its page and swap file, thus generating a LOT of page faults and 
the resulting disk activity. Apparently page fault activity 
occasionally out-prioritized the application (PowerSDR) for a 
sufficiently extended period of time to cause the drops and hiccups.

The fix here was to set up a different, faster, processor with more 
memory. That fixed the problem - most of the time - though XP still 
wants to do it's page fault thing every so often. The difference in 
my newer system is that with more physical memory, fewer page faults 
should occur. FWIW, I saw nothing that leads me to believe the 
PowerSDR was gobbling so much memory that it was causing the paging 
storm. This is because SDR ran just fine with no page fault activity. 
Also, XP likes to do its page fault trick with nothing running at all 
(except performance monitor).

Thus it is clear that a rogue service routine - or possibly even XP 
itself - can indeed sneak in and corrupt timing by causing an 
unreasonably large number of page faults. In this respect, it is not 
clear that XP is capable of being properly configured.

73 de Glenn WB6W



At 11:08 AM 5/23/2008, Frank Brickle wrote:

>On Fri, May 23, 2008 at 4:30 AM, Michael White 
><<mailto:michael.white at zytac.com>michael.white at zytac.com> wrote:
>
>I think you're vastly overimpressed with what even the best current 
>QSK radios are actually doing, and that you're vastly underimpressed 
>with what current off-the-shelf hardware and software are actually 
>doing in practice all the time these days.
>
>In any case, the idea that a rogue service routine can sneak in 
>behind you and corrupt your timing is, on a properly configured 
>system, just silly.
>
>73
>Frank
>AB2KT


 1211587647.0