[hpsdr] HPSDR / PowerSDR hardware selection

[Michael White]

I totally agree Glenn.

I am aware that with mainframe computing "Page Faults" i.e. access to  
virtual memory is a sin to be avoided at all costs, yet with Windows  
even if you furnish the machine with insane amounts of memory the vm  
access continues. At a guess I would say the page faults you are  
seeing are coming from a periodic garbage collection routine designed  
to keep the vm access as efficient as possible.

To me this is a problem with these type of OS we can only really guess  
what is going on under the hood. It is so difficult to properly  
engineer a real time system using Windows or even Linux, because the  
guts of the system is inaccessible  (to most people),  and getting a  
setup that has a low probability of buffer overrun is something of a  
black art. You would think that throwing sheer horsepower at the  
problem would gradually ease the difficulty but of course the OS's  
just become more bloated as the new hardware resource is simply  
squandered by the next version of the OS.

Unix to my mind is the best PC OS in that regard.

However I stand by my earlier comments. I doubt if linux can be  
engineered to be deterministic.

To my mind to build a real-time SDR we would need to engineer an  
embedded processor either for stand alone use or possibly using the PC  
for GUI  with some command and control. This embedded solution,  
(Sasquatch concept) , would benefit from a floating point math co- 
processor for the heavy lifting.

HPSDR contributors have studied and reviewed what is available in the  
DSP market. I personally believe the TI..... 6713 is a pretty good  
compromise and has a low cost tool chain available.  (See previous  
postings.)

Or there are a whole host of powerful and useful embedded processors  
and RTOS options out there, it is a very  interesting area to study.  
Overall I think the Saquatch concept as it stands is pretty good and  
personally I would encourage and support its development.

73
Michael White
G3WOE.


On 24 May 2008, at 00:07, hpsdr-request at lists.hpsdr.org wrote:

> Send Hpsdr mailing list submissions to
> 	hpsdr at lists.hpsdr.org
>
>
> Message: 22
> Date: Fri, 23 May 2008 16:07:27 -0800
> From: Glenn Thomas <glennt at charter.net>
> Subject: Re: [hpsdr] HPSDR / PowerSDR hardware selection
> To: hpsdr at lists.hpsdr.org
> Message-ID: <7.0.1.0.2.20080523153230.02390fc0 at charter.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> 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
>
>
>
> ------------------------------
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>
> End of Hpsdr Digest, Vol 27, Issue 20
> *************************************


 1211722106.0