Re: [Discuss-gnuradio] Profiling GNU Radio flow graphs

[Carles Fernandez]

Hi Felix,

we have some notes on code profiling here:
http://gnss-sdr.org/documentation/how-profile-code

We use the tools described there in a C++-only flowgraph, but I hope
some of them will also work for you.

Best regards,
Carles




On Fri, Aug 24, 2012 at 8:28 AM, Qing Yang  wrote:
> Hi Felix,
>
> Currently I also need to profile and optimize my system. Now I just add some
> some sentences to print the processing time of each block, but this is
> definitely not a good method. Could you describe your profiling method in
> more details, perhaps your results can be a reference for me.
>
> Hi Tim,
>
> Have you tried this Kcachegrind on GNU Radio flow graphs? Does it works
> well? I want to see the profile of each gr module (in python).
>
>
> --
> Yang, Qing
> Information Engineering, CUHK
>
>
>
> 2012/8/24 
>
>> Hi all,
>>
>> I am currently trying to optimize the performance of my DRM transmitter
>> and for this purpose I want to profile my flow graphs.
>>
>> After some googling and searching the archives I stumbled upon oprofile
>> which looks quite nice to me. However, a first try did not really provide
>> very significant results. But that could also be due to misconfiguration,
>> I did not read the manual very carefully...
>>
>> Just wanted to know if there are other/better solutions for profiling you
>> would recommend. Any comments are appreciated!
>>
>> Best regards,
>> Felix
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A silly question

[sumitstop]

Hi Community ,
Whenever we open a UHD device following message appears on the terminal :

linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 100 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 100 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 100 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
Using Volk machine: sse4_1_32
gain = 35.0
@@

And after that the program continues. I have made my own customized spectrum
sensing python script which is controlled by another bash script. I need to
make a screencast when the whole process goes, but this much long warning at
the beginning of every iteration is kind of irritating. I tried to find form
where these are been echoed or printed but no help.

If any body know the location of those files kindly help me out. I need to
temporarily disable this echo.
** I tried >/dev/null thing but it is suppressing all the required contents
also.
Thanks :working:
   

-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/A-silly-question-tp34343561p34343561.html
Sent from the GnuRadio mailing list archive at Nabble.com.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A silly question

[Ryan Wolfarth]

If you execute the following commands you will get rid of those warnings.
These adjust the maximum read and write buffer sizes allowed that the OS is
allowed to use for network interfaces.  See more here:
http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php

sudo sysctl -w net.core.rmem_max=5000
sudo sysctl -w net.core.wmem_max=1048576

You could add these lines in "/etc/sysctl.conf" if you don't want to type
those lines every time your system restarts.

Regards,
Ryan

On Fri, Aug 24, 2012 at 6:41 AM, sumitstop
wrote:

>
> Hi Community ,
> Whenever we open a UHD device following message appears on the terminal :
> 
> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 100 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 100 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 100 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
> Using Volk machine: sse4_1_32
> gain = 35.0
> @@
>
> And after that the program continues. I have made my own customized
> spectrum
> sensing python script which is controlled by another bash script. I need to
> make a screencast when the whole process goes, but this much long warning
> at
> the beginning of every iteration is kind of irritating. I tried to find
> form
> where these are been echoed or printed but no help.
>
> If any body know the location of those files kindly help me out. I need to
> temporarily disable this echo.
> ** I tried >/dev/null thing but it is suppressing all the required contents
> also.
> Thanks :working:
>
>
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India
> --
> View this message in context:
> http://old.nabble.com/A-silly-question-tp34343561p34343561.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Profiling GNU Radio flow graphs

[Felix Wunsch]

Hi,

using oprofile is quite easy. Basically you configure your profiler, 
start it, start your application, kill it after some time, kill the 
profiler and look at the results. You don't have to set any special 
compiler flags. However, if you want to get annotated source, you need 
to compile with debug symbols. All this can be done in a simple shell 
script what makes it very convenient.


For more details I'd like to refer you to the oprofile manual [1] as 
it's good to read and not too extensive.


In my case, most CPU time is used by memmove (about 40%!). 
Unfortunately, I wasn't able to figure out where it gets called from.


Best regards,
Felix

[1] http://oprofile.sourceforge.net/doc/index.html


Am 24.08.2012 08:28, schrieb Qing Yang:

Hi Felix,


Currently I also need to profile and optimize my system. Now I just 
add some some sentences to print the processing time of each block, 
but this is definitely not a good method. Could you describe your 
profiling method in more details, perhaps your results can be a 
reference for me.



Hi Tim,


Have you tried this Kcachegrind on GNU Radio flow graphs? Does it 
works well? I want to see the profile of each gr module (in python).




--

Yang, Qing

Information Engineering, CUHK


2012/8/24 >


Hi all,

I am currently trying to optimize the performance of my DRM
transmitter
and for this purpose I want to profile my flow graphs.

After some googling and searching the archives I stumbled upon
oprofile
which looks quite nice to me. However, a first try did not really
provide
very significant results. But that could also be due to
misconfiguration,
I did not read the manual very carefully...

Just wanted to know if there are other/better solutions for
profiling you
would recommend. Any comments are appreciated!

Best regards,
Felix


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A silly question

[sumitstop]

Thanks Ryan...it worked for the three UHD warnings. Now I shall do something
about

~
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

~~
 

Wolfarth, Ryan wrote:
> 
> If you execute the following commands you will get rid of those warnings.
> These adjust the maximum read and write buffer sizes allowed that the OS
> is
> allowed to use for network interfaces.  See more here:
> http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php
> 
> sudo sysctl -w net.core.rmem_max=5000
> sudo sysctl -w net.core.wmem_max=1048576
> 
> You could add these lines in "/etc/sysctl.conf" if you don't want to type
> those lines every time your system restarts.
> 
> Regards,
> Ryan
> 
> On Fri, Aug 24, 2012 at 6:41 AM, sumitstop
> wrote:
> 
>>
>> Hi Community ,
>> Whenever we open a UHD device following message appears on the terminal :
>> 
>> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2
>>
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>>
>> UHD Warning:
>> The recv buffer could not be resized sufficiently.
>> Target sock buff size: 5000 bytes.
>> Actual sock buff size: 100 bytes.
>> See the transport application notes on buffer resizing.
>> Please run: sudo sysctl -w net.core.rmem_max=5000
>>
>> UHD Warning:
>> The recv buffer could not be resized sufficiently.
>> Target sock buff size: 5000 bytes.
>> Actual sock buff size: 100 bytes.
>> See the transport application notes on buffer resizing.
>> Please run: sudo sysctl -w net.core.rmem_max=5000
>>
>> UHD Warning:
>> The send buffer could not be resized sufficiently.
>> Target sock buff size: 1048576 bytes.
>> Actual sock buff size: 100 bytes.
>> See the transport application notes on buffer resizing.
>> Please run: sudo sysctl -w net.core.wmem_max=1048576
>> Using Volk machine: sse4_1_32
>> gain = 35.0
>> @@
>>
>> And after that the program continues. I have made my own customized
>> spectrum
>> sensing python script which is controlled by another bash script. I need
>> to
>> make a screencast when the whole process goes, but this much long warning
>> at
>> the beginning of every iteration is kind of irritating. I tried to find
>> form
>> where these are been echoed or printed but no help.
>>
>> If any body know the location of those files kindly help me out. I need
>> to
>> temporarily disable this echo.
>> ** I tried >/dev/null thing but it is suppressing all the required
>> contents
>> also.
>> Thanks :working:
>>
>>
>> -
>> Sumit Kr.
>> Research Assistant
>> Communication Research center
>> IIIT Hyderabad
>> India
>> --
>> View this message in context:
>> http://old.nabble.com/A-silly-question-tp34343561p34343561.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/A-silly-question-tp34343561p34344165.html
Sent from the GnuRadio mailing list archive at Nabble.com.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] get_gpio() help

[Frederick Lee]

On Thu, Aug 23, 2012 at 5:54 PM, Samuel Ibarra  wrote:

> Hello,
>
> Thank you for your help Frederick. The problem that I am having is that I
> don't really understand how I can get the read_gpio() value into my python
> code. Once I get the value to my python code, then I will be able to create
> a loop that continuously reads the pins.
>

 I'm not 100% sure, but I think all c++ files has to go through SWIG in
order to be used in python. Have you tried to importing the class?

example: from uhd import dboard_iface   or   imort dboard_iface
or something along those lines.

After importing you can probably run something like:

gpio_value = read_gpio( unit )

and that should give you your value. Perhaps someone that know this better
can give a more complete answer.

Regards,

Frederick
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] LLLL error printout

[Anisha Gorur]

Hello,
Very quick question, I'm trying to transmit a signal that I have created,
and in the console output at the beginning of the transmission, I get this
printout: LL. The error is not continuous, it stops after about 10
L's. What does this mean?
Thanks,
-Anisha
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] LLLL error printout

[Josh Blum]

On 08/24/2012 09:12 AM, Anisha Gorur wrote:
> Hello,
> Very quick question, I'm trying to transmit a signal that I have created,
> and in the console output at the beginning of the transmission, I get this
> printout: LL. The error is not continuous, it stops after about 10
> L's. What does this mean?

The transmitted packet had a timestamp that was late, ie the packet time
was > the time on the USRP.

-josh

> Thanks,
> -Anisha
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] get_gpio() help

[Josh Blum]

On 08/24/2012 09:00 AM, Frederick Lee wrote:
> On Thu, Aug 23, 2012 at 5:54 PM, Samuel Ibarra  wrote:
> 
>> Hello,
>>
>> Thank you for your help Frederick. The problem that I am having is that I
>> don't really understand how I can get the read_gpio() value into my python
>> code. Once I get the value to my python code, then I will be able to create
>> a loop that continuously reads the pins.
>>
> 
>  I'm not 100% sure, but I think all c++ files has to go through SWIG in
> order to be used in python. Have you tried to importing the class?
> 
> example: from uhd import dboard_iface   or   imort dboard_iface
> or something along those lines.
> 
> After importing you can probably run something like:
> 
> gpio_value = read_gpio( unit )
> 
> and that should give you your value. Perhaps someone that know this better
> can give a more complete answer.
> 

Thats the idea. You can call get_dboard_iface on the source or sink
object:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n474

This is available in python or c++ and all the same function calls
should work.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A silly question

[Josh Blum]

On 08/24/2012 06:26 AM, sumitstop wrote:
> 
> Thanks Ryan...it worked for the three UHD warnings. Now I shall do something
> about
> 

http://files.ettus.com/uhd_docs/manual/html/general.html#disabling-or-redirecting-prints-to-stdout

Make this one-time call in c++ at the start of your process.

-josh

> ~
> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2
> 
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> 
> ~~
>  
> 
> Wolfarth, Ryan wrote:
>>
>> If you execute the following commands you will get rid of those warnings.
>> These adjust the maximum read and write buffer sizes allowed that the OS
>> is
>> allowed to use for network interfaces.  See more here:
>> http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php
>>
>> sudo sysctl -w net.core.rmem_max=5000
>> sudo sysctl -w net.core.wmem_max=1048576
>>
>> You could add these lines in "/etc/sysctl.conf" if you don't want to type
>> those lines every time your system restarts.
>>
>> Regards,
>> Ryan
>>
>> On Fri, Aug 24, 2012 at 6:41 AM, sumitstop
>> wrote:
>>
>>>
>>> Hi Community ,
>>> Whenever we open a UHD device following message appears on the terminal :
>>> 
>>> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-177-g584b7ae2
>>>
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>>
>>> UHD Warning:
>>> The recv buffer could not be resized sufficiently.
>>> Target sock buff size: 5000 bytes.
>>> Actual sock buff size: 100 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.rmem_max=5000
>>>
>>> UHD Warning:
>>> The recv buffer could not be resized sufficiently.
>>> Target sock buff size: 5000 bytes.
>>> Actual sock buff size: 100 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.rmem_max=5000
>>>
>>> UHD Warning:
>>> The send buffer could not be resized sufficiently.
>>> Target sock buff size: 1048576 bytes.
>>> Actual sock buff size: 100 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.wmem_max=1048576
>>> Using Volk machine: sse4_1_32
>>> gain = 35.0
>>> @@
>>>
>>> And after that the program continues. I have made my own customized
>>> spectrum
>>> sensing python script which is controlled by another bash script. I need
>>> to
>>> make a screencast when the whole process goes, but this much long warning
>>> at
>>> the beginning of every iteration is kind of irritating. I tried to find
>>> form
>>> where these are been echoed or printed but no help.
>>>
>>> If any body know the location of those files kindly help me out. I need
>>> to
>>> temporarily disable this echo.
>>> ** I tried >/dev/null thing but it is suppressing all the required
>>> contents
>>> also.
>>> Thanks :working:
>>>
>>>
>>> -
>>> Sumit Kr.
>>> Research Assistant
>>> Communication Research center
>>> IIIT Hyderabad
>>> India
>>> --
>>> View this message in context:
>>> http://old.nabble.com/A-silly-question-tp34343561p34343561.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 
> 
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] seg fault in volk_32f_s32f_multiply_32f_a_sse gnuradio v 3.6.1

[ikjtel]

At the moment it's easily reproducible.  Same app runs under GR v3.3 with no 
trouble. Let me know if I can provide any more info - in particular, perhaps 
there's a special GDB command to dump the "xmm" register set?

Best Regards

Max
~

(gdb) i stack
#0  0x0747ce98 in volk_32f_s32f_multiply_32f_a_sse () from 
/usr/local/lib/libvolk.so.0.0.0
#1  0x0191cd84 in gr_multiply_const_ff::work(int, std::vector >&, std::vector >&) () 
from /usr/local/lib/libgnuradio-core-3.6.1.so.0.0.0
#2  0x018afb57 in gr_sync_block::general_work(int, std::vector >&, std::vector 
>&, std::vector >&) () from 
/usr/local/lib/libgnuradio-core-3.6.1.so.0.0.0
#3  0x01890bb5 in gr_block_executor::run_one_iteration() () from 
/usr/local/lib/libgnuradio-core-3.6.1.so.0.0.0
#4  0x018b2780 in 
gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr, int) () 
from /usr/local/lib/libgnuradio-core-3.6.1.so.0.0.0
#5  0x018abe36 in 
boost::detail::function::void_function_obj_invoker0,
 void>::invoke(boost::detail::function::function_buffer&) () from 
/usr/local/lib/libgnuradio-core-3.6.1.so.0.0.0
#6  0x0466c732 in boost::detail::thread_data >::run() () 
from /usr/local/lib/libgruel-3.6.1.so.0.0.0
#7  0x07fde029 in thread_proxy () from /usr/lib/libboost_thread.so.1.42.0
#8  0x00c26e99 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#9  0x005f673e in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) x/10ib 0x0747ce98
=> 0x747ce98 :  movaps 
(%ecx,%esi,1),%xmm0 0x747ce9c :add
$0x1,%edi 0x747ce9f :   mulps  
%xmm1,%xmm0 0x747cea2 :  movaps 
%xmm0,(%eax,%esi,1) 0x747cea6 :add
$0x10,%esi 0x747cea9 :  cmp
%edi,%edx 0x747ceab :ja 
0x747ce98  0x747cead 
:mov%edx,%edi 0x747ceaf 
:   shl$0x4,%edi 0x747ceb2 
:   add%edi,%ecx
(gdb) i r
eax0xb1974c08   -1315484664
ecx0xb190ec08   -1315902456
edx0xaf 175
ebx0x19d9ff427107316
esp0xaf00efe4   0xaf00efe4
ebp0xaf00f008   0xaf00f008
esi0x0  0
edi0x0  0
eip0x747ce980x747ce98 
eflags 0x210246 [ PF ZF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio