discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Try to improve E100's performance at high sample


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate
Date: Tue, 17 Jan 2012 11:26:25 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0

>> You can time individual work functions by adding some code before an
>> after. We have some high resolution timers in
>> gruel/include/gruel/high_res_timers.h
>>
> 
> So I call the timer functions of high_res_timers.h before and after the
> operation in the work function, is that right?
> 

Yes. Its the standard way to time things. Save the begin time, then the
end time. Average the difference in begin/end times. Its probably more
practical for you to put the timer operations *in* the work function, at
the beginning and end (before return).

>> I have also seen people time the block in a simple flow graph with a
>> null source, head, your_block, null_sink. You can time tb.run() and
>> compare run duration vs the non-vectorized code.
>>
>> -Josh
>>
> 
> I got two questions about this:
> 
> 1) Is the "head" block for generating data for the processing block?
> 

head shutdowns the flow graph after it passes N items.

> 2) The initialization of uhd is done first after tb.run(), so how could
> I isolate the processing time from the time between tb.run() - tb.stop() ?
> 

tb.run(), executes the flowgraph until completions. This is different
than the start/stop/wait model. So in this case, just time the run()
call. run() will exit when head block completes.

Second, you dont want to put UHD in this flowgraph. The goal is to time
the processing of a single block. The more blocks you add, the less
accurate the measurement of the individual block you are measuring: So
the flow graph is like: null source, head, quad_demod, null_sink

-Josh



reply via email to

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