Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing

[Tom Rondeau]

On Thu, Jul 11, 2013 at 7:17 PM, LD Zhang <address@hidden> wrote:
> Great, these discussions actually help a lot, I am going to initially design
> it to be a factor of 10 less than the theoretical limit.
>
> There is another question: in the case of no floating point operations at
> all, there must be a limit of how fast the data can stream through the
> Gnuradio environment. So is the limit like 10 Msps, or like 50 Msps? A 1
> Msps data stream fed through 10 parallel ports is like 10 Msps data stream,
> correct?
>
> Thanks,
>
> LD


Being able to calculate the cost of an SDR application running on a
GPP would be fantastic, but it would only ever be an approximation.

Instead, we've introduced the Performance Counters and a Performance
Monitor application with GNU Radio 3.7.0 that simply measures the
amount of time a block takes during a call to work. The paper that
I'll be presenting at the SRIF workshop in August introduces this
concept. I've also just written some documentation that will go into
the manual soon that describes them better.

The point of this tool is to see how well your application is running
and to identify which blocks might be using too much CPU time to be
singled out for optimization. It could also potentially be used to
develop an understanding of how each block might work on your machine,
which you could then use to extrapolate how much your system could
process.

Tom



> -----Original Message-----
> From: Nathan West [mailto:address@hidden
> Sent: Thursday, July 11, 2013 3:35 PM
> To: LD Zhang
> Cc: Nathan West; address@hidden
> Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming
> processing
>
> On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang <address@hidden> wrote:
>> Hi, Please my comment below:
>>
>> You can probably get a rough estimate of the lower limit of your
>> processors ability to do something like an FIR filter with some simple
>> calculations:
>> A 10-point FIR filter needs to do 10 multiplies and 9 additions.
>> Blissfully ignoring branching that's 19 instructions for each output.
>> So let's say we've got a simple FIR filter that outputs the same
>> sample rate as it inputs.
>>
>> Using the table in here:
>> http://en.wikipedia.org/wiki/Instructions_per_second it looks like
>> modern CPUs clocked around 1GHz should expect between 2-5 IPS / (1/clock
> speed).
>> Pick your favorite (I'm guessing you're on older hardware so let's go
>> with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through a
>> very poorly implemented 10-tap FIR filter. That in itself is also a
>> pretty poor estimate. I see Marcus just replied as well and as he
>> said, the best way to
>> *know* is just to try it out on your hardware; there's no substitute
>> for that.
>>
>>
>>>>> I am confused: 10-tap FIR according to the above is 19 IPs, so 1M
>> samples correspond to 19 MIPS, much below the 2000 MIPS limit?
>> Am I missing something?
>>
>> LD
>>
>
> Hmm, I guess you're right. It's not too important because the actual
> estimate wouldn't be close to anything close to what you would see.
> The point is there is no easy answer (other than just running something to
> see if it works), but you might be able to come up with a rough estimate if
> you really need to and your application is really simple. You should
> probably ignore my lousy attempt :-P. I came up with it on the fly...
> There's also the issue of how long it takes those instructions to execute.
>
> -Nathan
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio