discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: LD Zhang
Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing
Date: Tue, 16 Jul 2013 14:42:20 -0700

Fantastic! Let us know if there are docs/links and code examples now. Or
maybe we will wait till the August presentation?

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Tom
Rondeau
Sent: Tuesday, July 16, 2013 2:30 PM
To: LD Zhang
Cc: Nathan West; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming
processing

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]