RE: [Discuss-gnuradio] Intel Atom is NICE.

[Bob McGwier]

And GPU's are going to become commodity priced quickly and possibly even move 
into the GPP and replace older ways of doing floating point.  With Nvidia CUDA, 
you can write code for your GPP, call GPU with intrinsics to get pretty quick 
payback while a better longer term strategy is worked on.

The future of really hard to program heterogeneous/not symmetric multiple core 
processors,  irrespective of how great the bandwidth is,  I don't think is 
looking all that rosy.  It simply cannot take months and months to get speed to 
make the processor pay or the cost per flop, when ALL COSTS are amortized 
(expensive people, etc.) begins to look bad.

Bob



ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-----Original Message-----
From: Newman, Timothy [mailto:address@hidden 
Sent: Monday, December 29, 2008 10:05 AM
To: Marcus D. Leech; Bob McGwier
Cc: address@hidden; address@hidden; address@hidden; address@hidden; 
address@hidden
Subject: RE: [Discuss-gnuradio] Intel Atom is NICE.

There are many more ways than just lumping everything onto a single GPP.  A 
good example is a recent thread on the GNU radio mailing list where the poster 
is using the USRP2 as a standalone radio with no PC.  Pushing key elements to 
other reconfigurable processors, e.g. the USRP2 FPGA, will greatly ease the 
burden of the GPP.  My point is that "big iron" isn't always necessary if 
you're willing to put some work into distributing the work load to other 
processors (a major research issue currently).

Tim


> -----Original Message-----
> From: address@hidden [mailto:discuss-gnuradio-
> address@hidden On Behalf Of Marcus D. Leech
> Sent: Monday, December 29, 2008 8:14 AM
> To: Bob McGwier
> Cc: address@hidden; address@hidden; address@hidden; discuss-
> address@hidden
> Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.


> While I can heartily agree that for the expansion of SDR into the
> consumer space, you want it to run on low-power processors, etc, I can't
>   agree that "for most operations" you don't need a high-end CPU.
> 
> For example, 802.11 at anywhere approaching 802.11b bitrates needs some
> serious iron, and yet in our world (the world of SDR
>   geeks), wanting to build SDR/GnuRadio-based 802.11b implementations
> seems a fairly common goal.
> 
> In my work in radio astronomy, I've found that despite the relative
> simplicity of the basic functions my software provides--full-bandwidth
>   spectral display, and total power, for one or two channels, big iron
> is necessary.   I recently upgraded to a quad-core Q6600 to replace
>   a dual-core Pentium D 940.  The quad core loses against the dual-core
> because of a difference in maximum clock speed.  I can
>   run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of
> dual-channel, complex bandwidth.  The Q6600, on the other hand,
>   is unstable above 2.85Ghz or so, and can't sustain more than about
> 5.3Mhz of dual-complex-channel bandwidth without incurring
>   massive USRP overruns.
> 
> Despite the wonderful new multi-threaded Gnu Radio framework, it seems
> that at least one of those threads really needs as many
>   MIPs as the processor can throw at it, because it has to keep up with
> a real-time data source.
> 
> Any time you're dealing with having to suck in (or send out) as much
> bandwidth as the USRP can tolerate, and
>   *actually doing something* with the entire bandwidth, you need
> ManyMIPS(tm).
>   Which means spending $$$ (although, my dual/quad-core system was much
> less than the $1000.00 you quote above).
> 
> --
> Marcus Leech
> Principal Investigator, Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio