Re: [Discuss-gnuradio] Trouble building (32-bit Linux, volk-related?)

[Tom Rondeau]

On Fri, Mar 16, 2012 at 2:07 AM, Ian Cullinan
wrote:

> Hi all,
>
> I'm having trouble building gnuradio from git on my 32-bit Ubuntu 10.10
> machine. The error I'm getting is:
>
> $ make
> [  0%] Generating ../include/volk/volk.h, volk.c,
> volk_init.h, ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h,
> volk_cpu.c, ../include/volk/volk_config_fixed.h, volk_environment_init.c,
> volk_environment_init.h, volk_machines.h, volk_machines.c,
> volk_machine_generic.c, volk_machine_sse2_only.c, volk_machine_sse2_32.c,
> volk_machine_sse3_32.c, volk_machine_ssse3_32.c, volk_machine_sse4_a_32.c,
> volk_machine_sse4_1_32.c, volk_machine_sse4_2_32.c, volk_machine_avx_32.c,
> volk_machine_avx_only.c
> [  0%] Generating volk_32f_x2_min_32f_a_orc_impl.c
> [  0%] Generating volk_32fc_x2_multiply_32fc_a_orc_impl.c
> ERROR: unknown token[0]: x2
> ERROR: unknown token[0]: splitql
> ERROR: unknown token[0]: swaplq
> ERROR: unknown token[0]: x2
> ERROR: unknown token[0]: splitql
> ERROR: unknown token[0]: mergelq
> Failed to compile volk_32fc_x2_multiply_32fc_a_orc_impl
> Failed to compile volk_32fc_x2_multiply_32fc_a_orc_impl
> make[2]: *** [volk/lib/volk_32fc_x2_multiply_32fc_a_orc_impl.c] Error 1
> make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
> make: *** [all] Error 2
>
>
> I successfully built and installed from git late last year without any
> problems, so my first thought was that I had old code lying around
> screwing things up so I deleted my whole gnuradio source tree and `git
> clone`d a new one to no avail. I also get the same error if I `git
> checkout` any of the v3.5 tags so I don't think it's a recent code
> change that's broken things.
>
> I assume this means there's something wrong with my system - does anyone
> have suggestions as where to look?
>
> Thanks,
> Ian Cullinan
>

What version of Orc is installed on your system?

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

Re: [Discuss-gnuradio] Reference documents for the interpolation filter in the digital clock recovery block

[Tom Rondeau]

On Wed, Mar 14, 2012 at 10:42 PM, Anh Duc Nguyen  wrote:

> Hi all,
>
> I am a new one to GnuRadio. Now I am studying some implemented techniques
> in GnuRadio, one of them is the digital clock recovery. I would like to ask
> you a question that what are the reference documents or papers you used for
> the interpolation filter in that task (digital clock recovery). When I
> traced back the source files - digital_clock_recovery_mm_ff and
> then gri_mmse_fir_interpolator, I found only a little information:
>
>  * This implements a Mininum Mean Squared Error interpolator with 8 taps.
>  * It is suitable for signals where the bandwidth of interest B = 1/(4*Ts)
>  * Where Ts is the time between samples.
>
> I find it tough to understand the algorithm you selected, so could you
> please help me on this problem. I make a guess with the key words " Mininum
> Mean Squared Error", the implementation may have some link to those below
> papers:
> [1]. G. Watkins, “Optimal Farrow coefficients for symbol timing
> recovery,” *IEEE Communications Letters*, vol. 5, no. 9, pp. 381–383,
> Sep. 2001.
> [2] Daeyoung Kim, M. J. Narasimba, and D. C. Coc, “Design of optimal
> interpolation filter for symbol timing recovery,” IEEE Transactions on
> Communications, vol. 45, no. 7, pp. 877–884, Jul. 1997.
>
>  I would like to thank you very much in advance,
>
> With best regards,
>
> Nguyen Anh Duc
>

I'm afraid that's before my time. I'm not sure we have the corporate
knowledge on that anymore.

If you find a good paper to describe it, let me know and I'll put it into
the documentation like we've done elsewhere.

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

[Discuss-gnuradio] Try to understand the stream in Gnu Radio

[Zhonghua]

Hi all,

After a period of using gnu radio, I have a problem of how to understand 
the stream. I got an information from a literature says: 'From the high 
level point-of-view, infinite streams of data flow through the ports. At 
the C++ level,streams are dealt with in convenient sized pieces, 
represented as contiguous arrays of the underlying type.' In almost each 
signal processing block we can see the definition of 'general_work' has 
this format:

 general_work(int noutput_items,
 gr_vector_int &ninput_items,
 gr_vector_const_void_star &input_items,
 gr_vector_void_star &output_items)
Some literatures say the 'noutput_items' variable represents the items 
number of one piece of the stream.  So the first question is what on 
earth the size of this variable? where dose it be specified? For example 
if A block connects to B block, how can ensure the 'noutput_items' of A 
block equal to the 'ninput_items' (presume B block only has one input 
stream).
In an concrete instance, in gr_squelch_base_cc.cc, we can see the last 
program as:

if (d_state != ST_MUTED)
   out[j++] = in[i]*gr_complex(d_envelope, 0.0);
else
   if (!d_gate)
  out[j++] = 0.0;
If we set d_gate as False(Actually in case of high sample rate it has to 
be set as False), when the input power is lower than the threshold(means 
the d_state should be as ST_MUTED), the out[j] shall get nothing. That 
means at this point there is no output data. So how the sequential block 
recognise this point? For instance the sequential block is 
ieee802_15_4_demod, how could it know where is this lost point? If only 
one point lost from the squelch block, is that means the whole piece of 
stream and even the whole package could not be demodulated correctly?
We can set the instance in more precise condition. If there are two 
pieces of stream: stream A and stream B. Assume each noutput_items is 
10, that is to say we have A[0], A[1] to A[9] and B[0] to B[9]. If 
A[0] has lost, then the stream entering into the sequential demodulation 
block is A[0](lost),A[1]A[9]? Or is A[1],A[2]B[0]?
If A[0] is valid, A[1] has lost, dose that mean the first piece of 
stream would not be demodulated correctly? If one package need both 
these two pieces of stream, dose it mean this package would not be 
demodulated correctly?


Any answer is greatly appreciated.

Sincerely,

Zhonghua

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

Re: [Discuss-gnuradio] Problem with new blocks

[Loic Danceg]

Hi Ben

Thank you for your help.
I am really familiar with Python, i think is more an error with the file .i
or another error but i don't find my error :-(

Le 14 mars 2012 21:34, Ben Hilburn  a écrit :

> Loic -
>
> That is a Python error, telling you that your class 'rfid' doesn't have
> the member 'test'.  This is an error in your code.
>
> How familiar are you with Python?  You may want to read up on some Python
> documentation to help you understand how that all works.
>
> http://docs.python.org/tutorial/classes.html
>
> Cheers,
> Ben
>
>
>
> On Tue, Mar 13, 2012 at 9:37 AM, Loic Danceg  wrote:
>
>> Hi everybody!
>>
>> I try to create my own block in a current project (rfid). So there are
>> currently other blocks which works correctly.
>> I had create my file.cc, my file.h and add the part that i need to add in
>> the file rfid.i
>>
>> After that, I enter the following command line:
>>
>> ./configure
>> make
>> make configure
>>
>> But when i use my application.py i have this error:
>>
>> *Traceback (most recent call last):
>>   File "./test.py", line 215, in 
>> main ()
>>   File "./test.py", line 65, in main
>> tb = my_top_block()
>>   File "./test.py", line 43, in __init__
>> d1 = rfid.test()
>> AttributeError: 'module' object has no attribute 'test'
>> *
>> Someone know why?
>>
>> Thank you a lot for your time!
>>
>>
>> ___
>> 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] Problem with new blocks

[Martin Braun]

On Tue, Mar 13, 2012 at 01:37:48PM -0300, Loic Danceg wrote:
> Hi everybody!
> 
> I try to create my own block in a current project (rfid). So there are
> currently other blocks which works correctly.
> I had create my file.cc, my file.h and add the part that i need to add in the
> file rfid.i
> 
> After that, I enter the following command line:
> 
> ./configure
> make
> make configure

Just making sure here, but do you also do 'make install' or at least
bend the PYTHONPATH to your temporary libraries?

MB
> 
> But when i use my application.py i have this error:
> 
> Traceback (most recent call last):
>   File "./test.py", line 215, in 
>     main ()
>   File "./test.py", line 65, in main
>     tb = my_top_block()
>   File "./test.py", line 43, in __init__
>     d1 = rfid.test()
> AttributeError: 'module' object has no attribute 'test'
> 
> Someone know why?
> 
> Thank you a lot for your time!
> 

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


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpYMGofcRqam.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with new blocks

[Zhonghua]

On 03/16/2012 02:37 PM, Loic Danceg wrote:

Hi Ben

Thank you for your help.
I am really familiar with Python, i think is more an error with the 
file .i or another error but i don't find my error :-(


Le 14 mars 2012 21:34, Ben Hilburn > a écrit :


Loic -

That is a Python error, telling you that your class 'rfid' doesn't
have the member 'test'.  This is an error in your code.

How familiar are you with Python?  You may want to read up on some
Python documentation to help you understand how that all works.

http://docs.python.org/tutorial/classes.html

Cheers,
Ben



On Tue, Mar 13, 2012 at 9:37 AM, Loic Danceg mailto:loicdan...@gmail.com>> wrote:

Hi everybody!

I try to create my own block in a current project (rfid). So
there are currently other blocks which works correctly.
I had create my file.cc, my file.h and add the part that i
need to add in the file rfid.i

After that, I enter the following command line:

./configure
make
make configure

But when i use my application.py i have this error:

/Traceback (most recent call last):
  File "./test.py", line 215, in 
main ()
  File "./test.py", line 65, in main
tb = my_top_block()
  File "./test.py", line 43, in __init__
d1 = rfid.test()
AttributeError: 'module' object has no attribute 'test'
/
Someone know why?

Thank you a lot for your time!


___
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
Did you change your Makefile.am? You should add your .i, .h and .cc file 
into the Makefile.am.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Frederick Stevens]

Hello,

Not sure if this is the right place to post this but I have had this 
error with 3.5.2 and later (git and 3.5.2.1) on Slackware 13.37 on a 
dual athlon 32 bit machine.  The problem is not present on an Intel Atom 
(32 bit dual core) machine with exactly the same configuration and 
libraries installed.  Here is the python error report from 
gnuradio-companion:


Executing: "/home/fred/gnuradio/top_block.py"

Using Volk machine: generic
Traceback (most recent call last):
  File "/home/fred/gnuradio/top_block.py", line 169, in 
tb = top_block()
  File "/home/fred/gnuradio/top_block.py", line 101, in __init__
self.gr_multiply_xx_3 = gr.multiply_vff(1)
  File 
"/usr/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_general.py", 
line 8783, in multiply_ff

return _gnuradio_core_general.multiply_ff(vlen)
RuntimeError: gr_block::set_alignment_multiple


When running volk_profile from the git sources, the application produces 
a segfault when it reaches volk_32fc_x2_multiply_32fc_a


I did a trace using ddd and it traced the error back to libvolk.so.0.0.0

Cheers,

Fred



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

Re: [Discuss-gnuradio] Reference documents for the interpolation filter in the digital clock recovery block

[Johnathan Corgan]

On Fri, Mar 16, 2012 at 05:36, Tom Rondeau  wrote:

> I'm afraid that's before my time. I'm not sure we have the corporate
> knowledge on that anymore.
>
> If you find a good paper to describe it, let me know and I'll put it into
> the documentation like we've done elsewhere.

A wee bit of archaelogical digging recovers these two ancient
documents from the lowermost layer of strata in the code (from back in
2002):

http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/gen_interpolator_taps/README
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/gen_interpolator_taps/praxis.txt

Johnathan

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

Re: [Discuss-gnuradio] Problem with new blocks

[Ben Hilburn]

Aha - you suspect a SWIG error?  That may indeed be the issue.

Check out Martin's advice, and let us know how it goes.  Have you generally
tested the SWIG for your class?

Cheers,
Ben

On Fri, Mar 16, 2012 at 6:37 AM, Loic Danceg  wrote:

> Hi Ben
>
> Thank you for your help.
> I am really familiar with Python, i think is more an error with the file
> .i or another error but i don't find my error :-(
>
> Le 14 mars 2012 21:34, Ben Hilburn  a écrit :
>
> Loic -
>>
>> That is a Python error, telling you that your class 'rfid' doesn't have
>> the member 'test'.  This is an error in your code.
>>
>> How familiar are you with Python?  You may want to read up on some Python
>> documentation to help you understand how that all works.
>>
>> http://docs.python.org/tutorial/classes.html
>>
>> Cheers,
>> Ben
>>
>>
>>
>> On Tue, Mar 13, 2012 at 9:37 AM, Loic Danceg wrote:
>>
>>>  Hi everybody!
>>>
>>> I try to create my own block in a current project (rfid). So there are
>>> currently other blocks which works correctly.
>>> I had create my file.cc, my file.h and add the part that i need to add
>>> in the file rfid.i
>>>
>>> After that, I enter the following command line:
>>>
>>> ./configure
>>> make
>>> make configure
>>>
>>> But when i use my application.py i have this error:
>>>
>>> *Traceback (most recent call last):
>>>   File "./test.py", line 215, in 
>>> main ()
>>>   File "./test.py", line 65, in main
>>> tb = my_top_block()
>>>   File "./test.py", line 43, in __init__
>>> d1 = rfid.test()
>>> AttributeError: 'module' object has no attribute 'test'
>>> *
>>> Someone know why?
>>>
>>> Thank you a lot for your time!
>>>
>>>
>>> ___
>>> 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] Reference documents for the interpolation filter in the digital clock recovery block

[Tom Rondeau]

On Fri, Mar 16, 2012 at 12:20 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:

> On Fri, Mar 16, 2012 at 05:36, Tom Rondeau  wrote:
>
> > I'm afraid that's before my time. I'm not sure we have the corporate
> > knowledge on that anymore.
> >
> > If you find a good paper to describe it, let me know and I'll put it into
> > the documentation like we've done elsewhere.
>
> A wee bit of archaelogical digging recovers these two ancient
> documents from the lowermost layer of strata in the code (from back in
> 2002):
>
>
> http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/gen_interpolator_taps/README
>
> http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/gen_interpolator_taps/praxis.txt
>
> Johnathan
>


Good catch. I'm just going to put a pointer into the documentation of the
gri_mmse_fir_interpolator to those files.

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

Re: [Discuss-gnuradio] Problem with new blocks

[Ben Hilburn]

Sorry, last e-mail should have said, "Check out Martin's and Zhonghua's
advice..."

Cheers,
Ben

On Fri, Mar 16, 2012 at 10:17 AM, Ben Hilburn  wrote:

> Aha - you suspect a SWIG error?  That may indeed be the issue.
>
> Check out Martin's advice, and let us know how it goes.  Have you
> generally tested the SWIG for your class?
>
> Cheers,
> Ben
>
>
> On Fri, Mar 16, 2012 at 6:37 AM, Loic Danceg  wrote:
>
>> Hi Ben
>>
>> Thank you for your help.
>> I am really familiar with Python, i think is more an error with the file
>> .i or another error but i don't find my error :-(
>>
>> Le 14 mars 2012 21:34, Ben Hilburn  a écrit :
>>
>> Loic -
>>>
>>> That is a Python error, telling you that your class 'rfid' doesn't have
>>> the member 'test'.  This is an error in your code.
>>>
>>> How familiar are you with Python?  You may want to read up on some
>>> Python documentation to help you understand how that all works.
>>>
>>> http://docs.python.org/tutorial/classes.html
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>>
>>> On Tue, Mar 13, 2012 at 9:37 AM, Loic Danceg wrote:
>>>
  Hi everybody!

 I try to create my own block in a current project (rfid). So there are
 currently other blocks which works correctly.
 I had create my file.cc, my file.h and add the part that i need to add
 in the file rfid.i

 After that, I enter the following command line:

 ./configure
 make
 make configure

 But when i use my application.py i have this error:

 *Traceback (most recent call last):
   File "./test.py", line 215, in 
 main ()
   File "./test.py", line 65, in main
 tb = my_top_block()
   File "./test.py", line 43, in __init__
 d1 = rfid.test()
 AttributeError: 'module' object has no attribute 'test'
 *
 Someone know why?

 Thank you a lot for your time!


 ___
 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] Segfault with volk on 32 bit AMD

[Tom Rondeau]

On Fri, Mar 16, 2012 at 11:38 AM, Frederick Stevens
wrote:

> Hello,
>
> Not sure if this is the right place to post this but I have had this error
> with 3.5.2 and later (git and 3.5.2.1) on Slackware 13.37 on a dual athlon
> 32 bit machine.  The problem is not present on an Intel Atom (32 bit dual
> core) machine with exactly the same configuration and libraries installed.
>  Here is the python error report from gnuradio-companion:
>
> Executing: "/home/fred/gnuradio/top_**block.py"
>
> Using Volk machine: generic
> Traceback (most recent call last):
>  File "/home/fred/gnuradio/top_**block.py", line 169, in 
>tb = top_block()
>  File "/home/fred/gnuradio/top_**block.py", line 101, in __init__
>self.gr_multiply_xx_3 = gr.multiply_vff(1)
>  File 
> "/usr/lib/python2.6/site-**packages/gnuradio/gr/gnuradio_**core_general.py",
> line 8783, in multiply_ff
>return _gnuradio_core_general.**multiply_ff(vlen)
> RuntimeError: gr_block::set_alignment_**multiple
>
>
> When running volk_profile from the git sources, the application produces a
> segfault when it reaches volk_32fc_x2_multiply_32fc_a
>
> I did a trace using ddd and it traced the error back to libvolk.so.0.0.0
>
> Cheers,
>
> Fred
>


Well, that doesn't make me happy at all. Especially since we just patched
the release yesterday...

Sounds like the AMD chip is handling something wrong (or differently) with
the alignment. All vectors passed using volk_profile are supposed to be
properly byte aligned.

Fred, can you just check for me what happens when you run it under gdb?
Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
results of the backtrace here.

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

Re: [Discuss-gnuradio] Try to understand the stream in Gnu Radio

[Tom Rondeau]

On Fri, Mar 16, 2012 at 8:41 AM, Zhonghua  wrote:

> Hi all,
>
> After a period of using gnu radio, I have a problem of how to understand
> the stream. I got an information from a literature says: 'From the high
> level point-of-view, infinite streams of data flow through the ports. At
> the C++ level,streams are dealt with in convenient sized pieces,
> represented as contiguous arrays of the underlying type.' In almost each
> signal processing block we can see the definition of 'general_work' has
> this format:
> general_work(int noutput_items,
> gr_vector_int &ninput_items,
> gr_vector_const_void_star &input_items,
> gr_vector_void_star &output_items)
> Some literatures say the 'noutput_items' variable represents the items
> number of one piece of the stream.  So the first question is what on earth
> the size of this variable? where dose it be specified? For example if A
> block connects to B block, how can ensure the 'noutput_items' of A block
> equal to the 'ninput_items' (presume B block only has one input stream).
> In an concrete instance, in gr_squelch_base_cc.cc, we can see the last
> program as:
>if (d_state != ST_MUTED)
>   out[j++] = in[i]*gr_complex(d_envelope, 0.0);
>else
>   if (!d_gate)
>  out[j++] = 0.0;
> If we set d_gate as False(Actually in case of high sample rate it has to
> be set as False), when the input power is lower than the threshold(means
> the d_state should be as ST_MUTED), the out[j] shall get nothing. That
> means at this point there is no output data. So how the sequential block
> recognise this point? For instance the sequential block is
> ieee802_15_4_demod, how could it know where is this lost point? If only one
> point lost from the squelch block, is that means the whole piece of stream
> and even the whole package could not be demodulated correctly?
> We can set the instance in more precise condition. If there are two pieces
> of stream: stream A and stream B. Assume each noutput_items is 10, that is
> to say we have A[0], A[1] to A[9] and B[0] to B[9]. If A[0] has lost,
> then the stream entering into the sequential demodulation block is
> A[0](lost),A[1]A[9]? Or is A[1],A[2]B[0]?
> If A[0] is valid, A[1] has lost, dose that mean the first piece of stream
> would not be demodulated correctly? If one package need both these two
> pieces of stream, dose it mean this package would not be demodulated
> correctly?
>
> Any answer is greatly appreciated.
>
> Sincerely,
>
> Zhonghua
>

Zhonghua,

This is a really complicated question to answer without giving you a full
essay. All of this happens in the scheduler, so if you want to know more,
study the code for the thread-per-block scheduler in
gnuradio-core/src/lib/runtime. It's the gr_block_executor that looks at the
read/write pointers to each blocks buffer and determines how many samples
are available to be read and how many samples a block can write.

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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Rafael Diniz]

Also using the gdb "disassemble" command you could trace which instruction
raised the fault.

Cheers,
Rafael Diniz

>
> Well, that doesn't make me happy at all. Especially since we just patched
> the release yesterday...
>
> Sounds like the AMD chip is handling something wrong (or differently) with
> the alignment. All vectors passed using volk_profile are supposed to be
> properly byte aligned.
>
> Fred, can you just check for me what happens when you run it under gdb?
> Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
> results of the backtrace here.
>
> Thanks,
> Tom



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

[Discuss-gnuradio] No-go on the GSoC

[Tom Rondeau]

Sorry gang, GNU Radio was not accepted as a mentor organization for the
GSoC this year. I'm very disappointed, as I'm sure everyone who helped out
here is, too. I thought we had great project ideas and application, but it
apparently wasn't enough.

Well, on to the next big thing!

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

Re: [Discuss-gnuradio] Segfault

[Stefan Ott]

On Thu, Mar 15, 2012 at 19:58, Philip Balister  wrote:
>
> Can you look carefully at what data is being passed to the driver? We
> may need to range check the data before we use it in the driver.

I had a look and it what I could find out so far is that offset=1276
and count=1.

cheers
-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Frederick Stevens]

Rafael,

Here is the output from gdb:

RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a

Program received signal SIGSEGV, Segmentation fault.
0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
   from /home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0



Dump of assembler code for function volk_32fc_32f_multiply_32fc_a_generic:
   0xb7f2c6c0 <+0>: push   %ebp
   0xb7f2c6c1 <+1>: mov%esp,%ebp
   0xb7f2c6c3 <+3>: push   %edi
   0xb7f2c6c4 <+4>: push   %esi
   0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
   0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
   0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
   0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
   0xb7f2c6d1 <+17>:test   %esi,%esi
   0xb7f2c6d3 <+19>:je 0xb7f2c6fc 


   0xb7f2c6d5 <+21>:xor%eax,%eax
   0xb7f2c6d7 <+23>:mov%esi,%esi
   0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
=> 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
   0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
   0xb7f2c6e6 <+38>:fmul   %st(1),%st
   0xb7f2c6e8 <+40>:fxch   %st(1)
   0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
   0xb7f2c6ee <+46>:fxch   %st(1)
   0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
   0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
   0xb7f2c6f7 <+55>:inc%eax
   0xb7f2c6f8 <+56>:cmp%eax,%esi
   0xb7f2c6fa <+58>:ja 0xb7f2c6e0 


   0xb7f2c6fc <+60>:pop%esi
   0xb7f2c6fd <+61>:pop%edi
   0xb7f2c6fe <+62>:pop%ebp
   0xb7f2c6ff <+63>:ret
End of assembler dump.

I omitted the first part of the program execution since everything 
seemed to be working fine.  Hope this helps.  Let me know if you would 
like me to try something else.


Cheers,


Fred



On 03/16/2012 12:39 PM, Rafael Diniz wrote:

Also using the gdb "disassemble" command you could trace which instruction
raised the fault.

Cheers,
Rafael Diniz


Well, that doesn't make me happy at all. Especially since we just patched
the release yesterday...

Sounds like the AMD chip is handling something wrong (or differently) with
the alignment. All vectors passed using volk_profile are supposed to be
properly byte aligned.

Fred, can you just check for me what happens when you run it under gdb?
Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
results of the backtrace here.

Thanks,
Tom



___
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] Segfault with volk on 32 bit AMD

[Nick Foster]

On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens
wrote:

> Rafael,
>
> Here is the output from gdb:
>
> RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_**generic ()
>   from /home/fred/extras/gnuradio/**gnuradio/build/volk/lib/**
> libvolk.so.0.0.0
>
>
>
> Dump of assembler code for function volk_32fc_32f_multiply_32fc_a_**
> generic:
>   0xb7f2c6c0 <+0>: push   %ebp
>   0xb7f2c6c1 <+1>: mov%esp,%ebp
>   0xb7f2c6c3 <+3>: push   %edi
>   0xb7f2c6c4 <+4>: push   %esi
>   0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
>   0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
>   0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
>   0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
>   0xb7f2c6d1 <+17>:test   %esi,%esi
>   0xb7f2c6d3 <+19>:je 0xb7f2c6fc  a_generic+60>
>   0xb7f2c6d5 <+21>:xor%eax,%eax
>   0xb7f2c6d7 <+23>:mov%esi,%esi
>   0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
> => 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
>   0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
>   0xb7f2c6e6 <+38>:fmul   %st(1),%st
>   0xb7f2c6e8 <+40>:fxch   %st(1)
>   0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
>   0xb7f2c6ee <+46>:fxch   %st(1)
>   0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
>   0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
>   0xb7f2c6f7 <+55>:inc%eax
>   0xb7f2c6f8 <+56>:cmp%eax,%esi
>   0xb7f2c6fa <+58>:ja 0xb7f2c6e0  a_generic+32>
>   0xb7f2c6fc <+60>:pop%esi
>   0xb7f2c6fd <+61>:pop%edi
>   0xb7f2c6fe <+62>:pop%ebp
>   0xb7f2c6ff <+63>:ret
> End of assembler dump.
>
> I omitted the first part of the program execution since everything seemed
> to be working fine.  Hope this helps.  Let me know if you would like me to
> try something else.
>
> Cheers,
>
>
> Fred


OK, that's weird as hell. That's the generic implementation, which is just
a std::complex multiply in a for loop. Can you give me your gcc version?

--n


>
>
>
>
> On 03/16/2012 12:39 PM, Rafael Diniz wrote:
>
>> Also using the gdb "disassemble" command you could trace which instruction
>> raised the fault.
>>
>> Cheers,
>> Rafael Diniz
>>
>>  Well, that doesn't make me happy at all. Especially since we just patched
>>> the release yesterday...
>>>
>>> Sounds like the AMD chip is handling something wrong (or differently)
>>> with
>>> the alignment. All vectors passed using volk_profile are supposed to be
>>> properly byte aligned.
>>>
>>> Fred, can you just check for me what happens when you run it under gdb?
>>> Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
>>> results of the backtrace here.
>>>
>>> Thanks,
>>> Tom
>>>
>>
>>
>> __**_
>> 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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Tom Rondeau]

On Fri, Mar 16, 2012 at 2:50 PM, Nick Foster  wrote:

> On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens  > wrote:
>
>> Rafael,
>>
>> Here is the output from gdb:
>>
>> RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_**generic ()
>>   from /home/fred/extras/gnuradio/**gnuradio/build/volk/lib/**
>> libvolk.so.0.0.0
>>
>>
>>
>> Dump of assembler code for function volk_32fc_32f_multiply_32fc_a_**
>> generic:
>>   0xb7f2c6c0 <+0>: push   %ebp
>>   0xb7f2c6c1 <+1>: mov%esp,%ebp
>>   0xb7f2c6c3 <+3>: push   %edi
>>   0xb7f2c6c4 <+4>: push   %esi
>>   0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
>>   0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
>>   0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
>>   0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
>>   0xb7f2c6d1 <+17>:test   %esi,%esi
>>   0xb7f2c6d3 <+19>:je 0xb7f2c6fc > a_generic+60>
>>   0xb7f2c6d5 <+21>:xor%eax,%eax
>>   0xb7f2c6d7 <+23>:mov%esi,%esi
>>   0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
>> => 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
>>   0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
>>   0xb7f2c6e6 <+38>:fmul   %st(1),%st
>>   0xb7f2c6e8 <+40>:fxch   %st(1)
>>   0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
>>   0xb7f2c6ee <+46>:fxch   %st(1)
>>   0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
>>   0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
>>   0xb7f2c6f7 <+55>:inc%eax
>>   0xb7f2c6f8 <+56>:cmp%eax,%esi
>>   0xb7f2c6fa <+58>:ja 0xb7f2c6e0 > a_generic+32>
>>   0xb7f2c6fc <+60>:pop%esi
>>   0xb7f2c6fd <+61>:pop%edi
>>   0xb7f2c6fe <+62>:pop%ebp
>>   0xb7f2c6ff <+63>:ret
>> End of assembler dump.
>>
>> I omitted the first part of the program execution since everything seemed
>> to be working fine.  Hope this helps.  Let me know if you would like me to
>> try something else.
>>
>> Cheers,
>>
>>
>> Fred
>
>
> OK, that's weird as hell. That's the generic implementation, which is just
> a std::complex multiply in a for loop. Can you give me your gcc version?
>
> --n
>


Yep, that shouldn't be a problem. Fred, can you also give us the backtrace?

You might have to recompile volk with debugging turned on (passing
-DCMAKE_BUILD_TYPE="Debug" to cmake).

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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Rafael Diniz]

Is your system a stock slack 13.37 32bits?

>> OK, that's weird as hell. That's the generic implementation, which is
>> just
>> a std::complex multiply in a for loop. Can you give me your gcc version?
>>
>> --n
>>
>
>
> Yep, that shouldn't be a problem. Fred, can you also give us the
> backtrace?
>
> You might have to recompile volk with debugging turned on (passing
> -DCMAKE_BUILD_TYPE="Debug" to cmake).

regards,
Rafael Diniz


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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Frederick Stevens]

Here is the gcc info.  It will take me a bit to re compile gnuradio but 
I will turn on debugging in cmake.


gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I am running kernel 3.2.7 from slackware-current and swig 2.0.4 
everything else is from slackbuilds.  I will have to get versions for 
you if you need them.


Cheers,

Fred

On 03/16/2012 01:50 PM, Nick Foster wrote:
On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens 
mailto:sk8tesgr...@gmail.com>> wrote:


Rafael,

Here is the output from gdb:

RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a

Program received signal SIGSEGV, Segmentation fault.
0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
  from
/home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0



Dump of assembler code for function
volk_32fc_32f_multiply_32fc_a_generic:
  0xb7f2c6c0 <+0>: push   %ebp
  0xb7f2c6c1 <+1>: mov%esp,%ebp
  0xb7f2c6c3 <+3>: push   %edi
  0xb7f2c6c4 <+4>: push   %esi
  0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
  0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
  0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
  0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
  0xb7f2c6d1 <+17>:test   %esi,%esi
  0xb7f2c6d3 <+19>:je 0xb7f2c6fc

  0xb7f2c6d5 <+21>:xor%eax,%eax
  0xb7f2c6d7 <+23>:mov%esi,%esi
  0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
=> 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
  0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
  0xb7f2c6e6 <+38>:fmul   %st(1),%st
  0xb7f2c6e8 <+40>:fxch   %st(1)
  0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
  0xb7f2c6ee <+46>:fxch   %st(1)
  0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
  0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
  0xb7f2c6f7 <+55>:inc%eax
  0xb7f2c6f8 <+56>:cmp%eax,%esi
  0xb7f2c6fa <+58>:ja 0xb7f2c6e0

  0xb7f2c6fc <+60>:pop%esi
  0xb7f2c6fd <+61>:pop%edi
  0xb7f2c6fe <+62>:pop%ebp
  0xb7f2c6ff <+63>:ret
End of assembler dump.

I omitted the first part of the program execution since everything
seemed to be working fine.  Hope this helps.  Let me know if you
would like me to try something else.

Cheers,


Fred


OK, that's weird as hell. That's the generic implementation, which is 
just a std::complex multiply in a for loop. Can you give me your gcc 
version?


--n





On 03/16/2012 12:39 PM, Rafael Diniz wrote:

Also using the gdb "disassemble" command you could trace which
instruction
raised the fault.

Cheers,
Rafael Diniz

Well, that doesn't make me happy at all. Especially since
we just patched
the release yesterday...

Sounds like the AMD chip is handling something wrong (or
differently) with
the alignment. All vectors passed using volk_profile are
supposed to be
properly byte aligned.

Fred, can you just check for me what happens when you run
it under gdb?
Just run "gdb volk_profile" and when it crashes, do a "bt"
and post the
results of the backtrace here.

Thanks,
Tom



___
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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Tom Rondeau]

On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens wrote:

>  Here is the gcc info.  It will take me a bit to re compile gnuradio but I
> will turn on debugging in cmake.
>
> gcc (GCC) 4.5.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I am running kernel 3.2.7 from slackware-current and swig 2.0.4 everything
> else is from slackbuilds.  I will have to get versions for you if you need
> them.
>
> Cheers,
>
> Fred
>

While you're doing the rebuild, can you set the optimization flag to -O2?
It's -O3 right now by default, and every now and then it can be a problem
(haven't heard of one in a while, but it's been a thing).

It should be setting '-DCMAKE_CXXFLAGS="-O2"'.

Tom




>  On 03/16/2012 01:50 PM, Nick Foster wrote:
>
> On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens  > wrote:
>
>> Rafael,
>>
>> Here is the output from gdb:
>>
>> RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
>>   from /home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0
>>
>>
>>
>> Dump of assembler code for function volk_32fc_32f_multiply_32fc_a_generic:
>>   0xb7f2c6c0 <+0>: push   %ebp
>>   0xb7f2c6c1 <+1>: mov%esp,%ebp
>>   0xb7f2c6c3 <+3>: push   %edi
>>   0xb7f2c6c4 <+4>: push   %esi
>>   0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
>>   0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
>>   0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
>>   0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
>>   0xb7f2c6d1 <+17>:test   %esi,%esi
>>   0xb7f2c6d3 <+19>:je 0xb7f2c6fc
>> 
>>   0xb7f2c6d5 <+21>:xor%eax,%eax
>>   0xb7f2c6d7 <+23>:mov%esi,%esi
>>   0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
>> => 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
>>   0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
>>   0xb7f2c6e6 <+38>:fmul   %st(1),%st
>>   0xb7f2c6e8 <+40>:fxch   %st(1)
>>   0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
>>   0xb7f2c6ee <+46>:fxch   %st(1)
>>   0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
>>   0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
>>   0xb7f2c6f7 <+55>:inc%eax
>>   0xb7f2c6f8 <+56>:cmp%eax,%esi
>>   0xb7f2c6fa <+58>:ja 0xb7f2c6e0
>> 
>>   0xb7f2c6fc <+60>:pop%esi
>>   0xb7f2c6fd <+61>:pop%edi
>>   0xb7f2c6fe <+62>:pop%ebp
>>   0xb7f2c6ff <+63>:ret
>> End of assembler dump.
>>
>> I omitted the first part of the program execution since everything seemed
>> to be working fine.  Hope this helps.  Let me know if you would like me to
>> try something else.
>>
>> Cheers,
>>
>>
>> Fred
>
>
>  OK, that's weird as hell. That's the generic implementation, which is
> just a std::complex multiply in a for loop. Can you give me your gcc
> version?
>
>  --n
>
>
>>
>>
>>
>>
>> On 03/16/2012 12:39 PM, Rafael Diniz wrote:
>>
>>> Also using the gdb "disassemble" command you could trace which
>>> instruction
>>> raised the fault.
>>>
>>> Cheers,
>>> Rafael Diniz
>>>
>>>  Well, that doesn't make me happy at all. Especially since we just
 patched
 the release yesterday...

 Sounds like the AMD chip is handling something wrong (or differently)
 with
 the alignment. All vectors passed using volk_profile are supposed to be
 properly byte aligned.

 Fred, can you just check for me what happens when you run it under gdb?
 Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
 results of the backtrace here.

 Thanks,
 Tom

>>>
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Frederick Stevens]

I've added your suggested changes.  It will be an hour or so until 
compilation is finished. Slackware CFLAGS or CXXFLAGS are usually -O2 by 
default.


Cheers,

Fred

On 03/16/2012 02:09 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens 
mailto:sk8tesgr...@gmail.com>> wrote:


Here is the gcc info.  It will take me a bit to re compile
gnuradio but I will turn on debugging in cmake.

gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. 
There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

I am running kernel 3.2.7 from slackware-current and swig 2.0.4
everything else is from slackbuilds.  I will have to get versions
for you if you need them.

Cheers,

Fred


While you're doing the rebuild, can you set the optimization flag to 
-O2? It's -O3 right now by default, and every now and then it can be a 
problem (haven't heard of one in a while, but it's been a thing).


It should be setting '-DCMAKE_CXXFLAGS="-O2"'.

Tom


On 03/16/2012 01:50 PM, Nick Foster wrote:

On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens
mailto:sk8tesgr...@gmail.com>> wrote:

Rafael,

Here is the output from gdb:

RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a

Program received signal SIGSEGV, Segmentation fault.
0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
  from
/home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0



Dump of assembler code for function
volk_32fc_32f_multiply_32fc_a_generic:
  0xb7f2c6c0 <+0>: push   %ebp
  0xb7f2c6c1 <+1>: mov%esp,%ebp
  0xb7f2c6c3 <+3>: push   %edi
  0xb7f2c6c4 <+4>: push   %esi
  0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
  0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
  0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
  0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
  0xb7f2c6d1 <+17>:test   %esi,%esi
  0xb7f2c6d3 <+19>:je 0xb7f2c6fc

  0xb7f2c6d5 <+21>:xor%eax,%eax
  0xb7f2c6d7 <+23>:mov%esi,%esi
  0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
=> 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
  0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
  0xb7f2c6e6 <+38>:fmul   %st(1),%st
  0xb7f2c6e8 <+40>:fxch   %st(1)
  0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
  0xb7f2c6ee <+46>:fxch   %st(1)
  0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
  0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
  0xb7f2c6f7 <+55>:inc%eax
  0xb7f2c6f8 <+56>:cmp%eax,%esi
  0xb7f2c6fa <+58>:ja 0xb7f2c6e0

  0xb7f2c6fc <+60>:pop%esi
  0xb7f2c6fd <+61>:pop%edi
  0xb7f2c6fe <+62>:pop%ebp
  0xb7f2c6ff <+63>:ret
End of assembler dump.

I omitted the first part of the program execution since
everything seemed to be working fine.  Hope this helps.  Let
me know if you would like me to try something else.

Cheers,


Fred


OK, that's weird as hell. That's the generic implementation,
which is just a std::complex multiply in a for loop. Can you give
me your gcc version?

--n





On 03/16/2012 12:39 PM, Rafael Diniz wrote:

Also using the gdb "disassemble" command you could trace
which instruction
raised the fault.

Cheers,
Rafael Diniz

Well, that doesn't make me happy at all. Especially
since we just patched
the release yesterday...

Sounds like the AMD chip is handling something wrong
(or differently) with
the alignment. All vectors passed using volk_profile
are supposed to be
properly byte aligned.

Fred, can you just check for me what happens when you
run it under gdb?
Just run "gdb volk_profile" and when it crashes, do a
"bt" and post the
results of the backtrace here.

Thanks,
Tom



___
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-gnurad

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Tom Rondeau]

On Fri, Mar 16, 2012 at 3:11 PM, Frederick Stevens wrote:

>  I've added your suggested changes.  It will be an hour or so until
> compilation is finished. Slackware CFLAGS or CXXFLAGS are usually -O2 by
> default.
>
> Cheers,
>
> Fred
>

Thanks. GNU Radio resets these flag to -O3 right now, though.

Also, can't you run 'make -jN' to speed up the compilation?

Tom



> On 03/16/2012 02:09 PM, Tom Rondeau wrote:
>
> On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens 
> wrote:
>
>>  Here is the gcc info.  It will take me a bit to re compile gnuradio but
>> I will turn on debugging in cmake.
>>
>> gcc (GCC) 4.5.2
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> I am running kernel 3.2.7 from slackware-current and swig 2.0.4
>> everything else is from slackbuilds.  I will have to get versions for you
>> if you need them.
>>
>> Cheers,
>>
>> Fred
>>
>
>  While you're doing the rebuild, can you set the optimization flag to
> -O2? It's -O3 right now by default, and every now and then it can be a
> problem (haven't heard of one in a while, but it's been a thing).
>
>  It should be setting '-DCMAKE_CXXFLAGS="-O2"'.
>
>  Tom
>
>
>
>
>>   On 03/16/2012 01:50 PM, Nick Foster wrote:
>>
>> On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens <
>> sk8tesgr...@gmail.com> wrote:
>>
>>> Rafael,
>>>
>>> Here is the output from gdb:
>>>
>>> RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
>>>   from
>>> /home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0
>>>
>>>
>>>
>>> Dump of assembler code for function
>>> volk_32fc_32f_multiply_32fc_a_generic:
>>>   0xb7f2c6c0 <+0>: push   %ebp
>>>   0xb7f2c6c1 <+1>: mov%esp,%ebp
>>>   0xb7f2c6c3 <+3>: push   %edi
>>>   0xb7f2c6c4 <+4>: push   %esi
>>>   0xb7f2c6c5 <+5>: mov0x8(%ebp),%edx
>>>   0xb7f2c6c8 <+8>: mov0xc(%ebp),%ecx
>>>   0xb7f2c6cb <+11>:mov0x10(%ebp),%edi
>>>   0xb7f2c6ce <+14>:mov0x14(%ebp),%esi
>>>   0xb7f2c6d1 <+17>:test   %esi,%esi
>>>   0xb7f2c6d3 <+19>:je 0xb7f2c6fc
>>> 
>>>   0xb7f2c6d5 <+21>:xor%eax,%eax
>>>   0xb7f2c6d7 <+23>:mov%esi,%esi
>>>   0xb7f2c6d9 <+25>:lea0x0(%edi,%eiz,1),%edi
>>> => 0xb7f2c6e0 <+32>:flds   (%edi,%eax,8)
>>>   0xb7f2c6e3 <+35>:flds   (%ecx,%eax,8)
>>>   0xb7f2c6e6 <+38>:fmul   %st(1),%st
>>>   0xb7f2c6e8 <+40>:fxch   %st(1)
>>>   0xb7f2c6ea <+42>:fmuls  0x4(%ecx,%eax,8)
>>>   0xb7f2c6ee <+46>:fxch   %st(1)
>>>   0xb7f2c6f0 <+48>:fstps  (%edx,%eax,8)
>>>   0xb7f2c6f3 <+51>:fstps  0x4(%edx,%eax,8)
>>>   0xb7f2c6f7 <+55>:inc%eax
>>>   0xb7f2c6f8 <+56>:cmp%eax,%esi
>>>   0xb7f2c6fa <+58>:ja 0xb7f2c6e0
>>> 
>>>   0xb7f2c6fc <+60>:pop%esi
>>>   0xb7f2c6fd <+61>:pop%edi
>>>   0xb7f2c6fe <+62>:pop%ebp
>>>   0xb7f2c6ff <+63>:ret
>>> End of assembler dump.
>>>
>>> I omitted the first part of the program execution since everything
>>> seemed to be working fine.  Hope this helps.  Let me know if you would like
>>> me to try something else.
>>>
>>> Cheers,
>>>
>>>
>>> Fred
>>
>>
>>  OK, that's weird as hell. That's the generic implementation, which is
>> just a std::complex multiply in a for loop. Can you give me your gcc
>> version?
>>
>>  --n
>>
>>
>>>
>>>
>>>
>>>
>>> On 03/16/2012 12:39 PM, Rafael Diniz wrote:
>>>
 Also using the gdb "disassemble" command you could trace which
 instruction
 raised the fault.

 Cheers,
 Rafael Diniz

  Well, that doesn't make me happy at all. Especially since we just
> patched
> the release yesterday...
>
> Sounds like the AMD chip is handling something wrong (or differently)
> with
> the alignment. All vectors passed using volk_profile are supposed to be
> properly byte aligned.
>
> Fred, can you just check for me what happens when you run it under gdb?
> Just run "gdb volk_profile" and when it crashes, do a "bt" and post the
> results of the backtrace here.
>
> Thanks,
> Tom
>


 ___
 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 mailing list
> Discuss-gnuradio@gnu.org
> https://lists

Re: [Discuss-gnuradio] Try to understand the stream in Gnu Radio

[Zhonghua]

On 03/16/2012 06:37 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 8:41 AM, Zhonghua > wrote:


Hi all,

After a period of using gnu radio, I have a problem of how to
understand the stream. I got an information from a literature
says: 'From the high level point-of-view, infinite streams of data
flow through the ports. At the C++ level,streams are dealt with in
convenient sized pieces, represented as contiguous arrays of the
underlying type.' In almost each signal processing block we can
see the definition of 'general_work' has this format:
general_work(int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
Some literatures say the 'noutput_items' variable represents the
items number of one piece of the stream.  So the first question is
what on earth the size of this variable? where dose it be
specified? For example if A block connects to B block, how can
ensure the 'noutput_items' of A block equal to the 'ninput_items'
(presume B block only has one input stream).
In an concrete instance, in gr_squelch_base_cc.cc, we can see the
last program as:
   if (d_state != ST_MUTED)
  out[j++] = in[i]*gr_complex(d_envelope, 0.0);
   else
  if (!d_gate)
 out[j++] = 0.0;
If we set d_gate as False(Actually in case of high sample rate it
has to be set as False), when the input power is lower than the
threshold(means the d_state should be as ST_MUTED), the out[j]
shall get nothing. That means at this point there is no output
data. So how the sequential block recognise this point? For
instance the sequential block is ieee802_15_4_demod, how could it
know where is this lost point? If only one point lost from the
squelch block, is that means the whole piece of stream and even
the whole package could not be demodulated correctly?
We can set the instance in more precise condition. If there are
two pieces of stream: stream A and stream B. Assume each
noutput_items is 10, that is to say we have A[0], A[1] to A[9]
and B[0] to B[9]. If A[0] has lost, then the stream entering into
the sequential demodulation block is A[0](lost),A[1]A[9]? Or
is A[1],A[2]B[0]?
If A[0] is valid, A[1] has lost, dose that mean the first piece of
stream would not be demodulated correctly? If one package need
both these two pieces of stream, dose it mean this package would
not be demodulated correctly?

Any answer is greatly appreciated.

Sincerely,

Zhonghua


Zhonghua,

This is a really complicated question to answer without giving you a 
full essay. All of this happens in the scheduler, so if you want to 
know more, study the code for the thread-per-block scheduler in 
gnuradio-core/src/lib/runtime. It's the gr_block_executor that looks 
at the read/write pointers to each blocks buffer and determines how 
many samples are available to be read and how many samples a block can 
write.


Tom


Hi Tom,

Thank you for your information. I think you have answered the first 
question that where and how dose the size be determined. To the detailed 
question, do you think if one item lost, all this package will lose? And 
in my last instance, do you think which assemblage will be sent to the 
sequential block? Thank you again!


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

[Discuss-gnuradio] moving common swig stuff to gruel?

[Josh Blum]

I suppose a common swig file in gruel would be the best place to have
this. The following commit is my attempt to create such a file and use
it throughout the code base, in this case gruel and gr-core.

Common swig file for reference:
http://gnuradio.org/cgit/jblum.git/diff/gruel/src/swig/gruel_common.i?h=gruel_common_swig

Here is the commit:
http://gnuradio.org/cgit/jblum.git/commit/?h=gruel_common_swig

Can we have this or something like this on the official next/master branch?

-Josh

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

Re: [Discuss-gnuradio] Try to understand the stream in Gnu Radio

[Tom Rondeau]

On Fri, Mar 16, 2012 at 3:28 PM, Zhonghua  wrote:

> **
> On 03/16/2012 06:37 PM, Tom Rondeau wrote:
>
> On Fri, Mar 16, 2012 at 8:41 AM, Zhonghua  wrote:
>
>> Hi all,
>>
>> After a period of using gnu radio, I have a problem of how to understand
>> the stream. I got an information from a literature says: 'From the high
>> level point-of-view, infinite streams of data flow through the ports. At
>> the C++ level,streams are dealt with in convenient sized pieces,
>> represented as contiguous arrays of the underlying type.' In almost each
>> signal processing block we can see the definition of 'general_work' has
>> this format:
>> general_work(int noutput_items,
>> gr_vector_int &ninput_items,
>> gr_vector_const_void_star &input_items,
>> gr_vector_void_star &output_items)
>> Some literatures say the 'noutput_items' variable represents the items
>> number of one piece of the stream.  So the first question is what on earth
>> the size of this variable? where dose it be specified? For example if A
>> block connects to B block, how can ensure the 'noutput_items' of A block
>> equal to the 'ninput_items' (presume B block only has one input stream).
>> In an concrete instance, in gr_squelch_base_cc.cc, we can see the last
>> program as:
>>if (d_state != ST_MUTED)
>>   out[j++] = in[i]*gr_complex(d_envelope, 0.0);
>>else
>>   if (!d_gate)
>>  out[j++] = 0.0;
>> If we set d_gate as False(Actually in case of high sample rate it has to
>> be set as False), when the input power is lower than the threshold(means
>> the d_state should be as ST_MUTED), the out[j] shall get nothing. That
>> means at this point there is no output data. So how the sequential block
>> recognise this point? For instance the sequential block is
>> ieee802_15_4_demod, how could it know where is this lost point? If only one
>> point lost from the squelch block, is that means the whole piece of stream
>> and even the whole package could not be demodulated correctly?
>> We can set the instance in more precise condition. If there are two
>> pieces of stream: stream A and stream B. Assume each noutput_items is 10,
>> that is to say we have A[0], A[1] to A[9] and B[0] to B[9]. If A[0] has
>> lost, then the stream entering into the sequential demodulation block is
>> A[0](lost),A[1]A[9]? Or is A[1],A[2]B[0]?
>> If A[0] is valid, A[1] has lost, dose that mean the first piece of stream
>> would not be demodulated correctly? If one package need both these two
>> pieces of stream, dose it mean this package would not be demodulated
>> correctly?
>>
>> Any answer is greatly appreciated.
>>
>> Sincerely,
>>
>> Zhonghua
>>
>
>  Zhonghua,
>
>  This is a really complicated question to answer without giving you a
> full essay. All of this happens in the scheduler, so if you want to know
> more, study the code for the thread-per-block scheduler in
> gnuradio-core/src/lib/runtime. It's the gr_block_executor that looks at the
> read/write pointers to each blocks buffer and determines how many samples
> are available to be read and how many samples a block can write.
>
>  Tom
>
>   Hi Tom,
>
> Thank you for your information. I think you have answered the first
> question that where and how dose the size be determined. To the detailed
> question, do you think if one item lost, all this package will lose? And in
> my last instance, do you think which assemblage will be sent to the
> sequential block? Thank you again!
>
> Zhonghua
>

I'm honestly not sure what you are getting at. Where/how would you lose an
item?

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

Re: [Discuss-gnuradio] moving common swig stuff to gruel?

[Johnathan Corgan]

I'll take a look at it.

On Fri, Mar 16, 2012 at 13:24, Josh Blum  wrote:
> I suppose a common swig file in gruel would be the best place to have
> this. The following commit is my attempt to create such a file and use
> it throughout the code base, in this case gruel and gr-core.
>
> Common swig file for reference:
> http://gnuradio.org/cgit/jblum.git/diff/gruel/src/swig/gruel_common.i?h=gruel_common_swig
>
> Here is the commit:
> http://gnuradio.org/cgit/jblum.git/commit/?h=gruel_common_swig
>
> Can we have this or something like this on the official next/master branch?
>
> -Josh
>
> ___
> 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] set clock source not implemented in this version

[sirjanselot]

Hello I am trying to synchronize two USRPs together using the MIMO cable.

I tried to set the clock and time source to the MIMO cable and it says that
this feature is not available in this version.

Is this true or am I missing something?

How do this?  

-- Opening a USRP2/N-Series device...
Traceback (most recent call last):
  File "/home/jacosta/iCAN Demo GRC files/top_block.py", line 214, in

tb = top_block()
  File "/home/jacosta/iCAN Demo GRC files/top_block.py", line 107, in
__init__
self.uhd_usrp_source_1.set_clock_source("mimo", 0)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py",
line 1887, in set_clock_source
return _uhd_swig.uhd_usrp_source_sptr_set_clock_source(self, *args,
**kwargs)
RuntimeError: not implemented in this version
-- 
View this message in context: 
http://old.nabble.com/set-clock-source-not-implemented-in-this-version-tp33519986p33519986.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] moving common swig stuff to gruel?

[Tom Rondeau]

On Fri, Mar 16, 2012 at 4:24 PM, Josh Blum  wrote:

> I suppose a common swig file in gruel would be the best place to have
> this. The following commit is my attempt to create such a file and use
> it throughout the code base, in this case gruel and gr-core.
>
> Common swig file for reference:
>
> http://gnuradio.org/cgit/jblum.git/diff/gruel/src/swig/gruel_common.i?h=gruel_common_swig
>
> Here is the commit:
> http://gnuradio.org/cgit/jblum.git/commit/?h=gruel_common_swig
>
> Can we have this or something like this on the official next/master branch?
>
> -Josh
>

Josh,

These look good. This and your other gruel QA code fix have been merged in.

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

Re: [Discuss-gnuradio] set clock source not implemented in this version

[Josh Blum]

On 03/16/2012 01:57 PM, sirjanselot wrote:
> 
> Hello I am trying to synchronize two USRPs together using the MIMO cable.
> 
> I tried to set the clock and time source to the MIMO cable and it says that
> this feature is not available in this version.
> 
> Is this true or am I missing something?
> 
> How do this?  
> 
> -- Opening a USRP2/N-Series device...
> Traceback (most recent call last):
>   File "/home/jacosta/iCAN Demo GRC files/top_block.py", line 214, in
> 
> tb = top_block()
>   File "/home/jacosta/iCAN Demo GRC files/top_block.py", line 107, in
> __init__
> self.uhd_usrp_source_1.set_clock_source("mimo", 0)
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1887, in set_clock_source
> return _uhd_swig.uhd_usrp_source_sptr_set_clock_source(self, *args,
> **kwargs)
> RuntimeError: not implemented in this version

The set_clock_source() call requires the master branch of UHD. This will
be tagged as release very shortly. The previous call was
set_clock_config(), this should still work, but GRC will not generate
calls to set_clock_config() on the version of gnuradio you have.

Can I recommend you marcus's build script as an easy way to install uhd
and gnuradio master branches?
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Gnuradio-UHD

-Josh

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

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

[Frederick Stevens]

Well, after a few restarts, here is my output.  I did a fresh pull from 
git because I was getting some errors with missing *.h files in 
gruel/src/swig or something like that.  Hope this helps!


RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a

Program received signal SIGSEGV, Segmentation fault.
0xb7edbb74 in volk_32fc_32f_multiply_32fc_a_generic (cVector=0xb7448008,
aVector=0xb7768008, bVector=0xb78f8008, num_points=204600)
at 
/home/fred/extras/gnuradio/gnuradio/volk/include/volk/volk_32fc_32f_multiply_32fc_a.h:74

74  *cPtr++ = (*aPtr++) * (*bPtr++);
(gdb) bt
#0  0xb7edbb74 in volk_32fc_32f_multiply_32fc_a_generic 
(cVector=0xb7448008,

aVector=0xb7768008, bVector=0xb78f8008, num_points=204600)
at 
/home/fred/extras/gnuradio/gnuradio/volk/include/volk/volk_32fc_32f_multiply_32fc_a.h:74

#1  0xb7ed4d68 in volk_32fc_32f_multiply_32fc_a_manual (cVector=0xb7448008,
aVector=0xb7768008, bVector=0xb78f8008, num_points=204600,
arch=0x8079ac4 "generic")
at /home/fred/extras/gnuradio/gnuradio/build/volk/lib/volk.c:749
#2  0x08064533 in run_cast_test3 (
func=0x80595c0 , buffs=...,
vlen=204600, iter=999, arch=...)
at /home/fred/extras/gnuradio/gnuradio/volk/lib/qa_utils.cc:182
#3  0x08062770 in run_volk_tests (desc=...,
manual_func=0x80595c0 ,
name=..., tol=9.9975e-05, scalar=..., vlen=204600, iter=1000,
best_arch_vector=0xbfffe714)
at /home/fred/extras/gnuradio/gnuradio/volk/lib/qa_utils.cc:351
#4  0x0805b3d3 in main (argc=1, argv=0xb204)
at /home/fred/extras/gnuradio/gnuradio/volk/apps/volk_profile.cc:38
(gdb)


Dump of assembler code for function volk_32fc_32f_multiply_32fc_a_generic:
   0xb7edbb39 <+0>: push   %ebp
   0xb7edbb3a <+1>: mov%esp,%ebp
   0xb7edbb3c <+3>: sub$0x14,%esp
   0xb7edbb3f <+6>: mov0x8(%ebp),%eax
   0xb7edbb42 <+9>: mov%eax,-0x4(%ebp)
   0xb7edbb45 <+12>:mov0xc(%ebp),%eax
   0xb7edbb48 <+15>:mov%eax,-0x8(%ebp)
   0xb7edbb4b <+18>:mov0x10(%ebp),%eax
   0xb7edbb4e <+21>:mov%eax,-0xc(%ebp)
   0xb7edbb51 <+24>:movl   $0x0,-0x10(%ebp)
   0xb7edbb58 <+31>:movl   $0x0,-0x10(%ebp)
   0xb7edbb5f <+38>:jmp0xb7edbbae 


   0xb7edbb61 <+40>:mov-0x8(%ebp),%eax
   0xb7edbb64 <+43>:mov(%eax),%ecx
   0xb7edbb66 <+45>:mov0x4(%eax),%edx
   0xb7edbb69 <+48>:mov%ecx,%eax
   0xb7edbb6b <+50>:mov%eax,-0x14(%ebp)
   0xb7edbb6e <+53>:flds   -0x14(%ebp)
   0xb7edbb71 <+56>:mov-0xc(%ebp),%eax
=> 0xb7edbb74 <+59>:flds   (%eax)
   0xb7edbb76 <+61>:fmulp  %st,%st(1)
   0xb7edbb78 <+63>:mov%edx,-0x14(%ebp)
   0xb7edbb7b <+66>:flds   -0x14(%ebp)
   0xb7edbb7e <+69>:mov-0xc(%ebp),%eax
   0xb7edbb81 <+72>:flds   (%eax)
   0xb7edbb83 <+74>:fmulp  %st,%st(1)
   0xb7edbb85 <+76>:fxch   %st(1)
   0xb7edbb87 <+78>:fstps  -0x14(%ebp)
   0xb7edbb8a <+81>:mov-0x14(%ebp),%ecx
   0xb7edbb8d <+84>:fstps  -0x14(%ebp)
   0xb7edbb90 <+87>:mov-0x14(%ebp),%edx
   0xb7edbb93 <+90>:mov-0x4(%ebp),%eax
   0xb7edbb96 <+93>:mov%ecx,(%eax)
   0xb7edbb98 <+95>:mov%edx,0x4(%eax)
   0xb7edbb9b <+98>:addl   $0x8,-0x4(%ebp)
   0xb7edbb9f <+102>:   addl   $0x8,-0x8(%ebp)
   0xb7edbba3 <+106>:   addl   $0x4,-0xc(%ebp)
   0xb7edbba7 <+110>:   addl   $0x4,-0xc(%ebp)
   0xb7edbbab <+114>:   incl   -0x10(%ebp)
   0xb7edbbae <+117>:   mov-0x10(%ebp),%eax
   0xb7edbb78 <+63>:mov%edx,-0x14(%ebp)
   0xb7edbb7b <+66>:flds   -0x14(%ebp)
   0xb7edbb7e <+69>:mov-0xc(%ebp),%eax
   0xb7edbb81 <+72>:flds   (%eax)
   0xb7edbb83 <+74>:fmulp  %st,%st(1)
   0xb7edbb85 <+76>:fxch   %st(1)
   0xb7edbb87 <+78>:fstps  -0x14(%ebp)
   0xb7edbb8a <+81>:mov-0x14(%ebp),%ecx
   0xb7edbb8d <+84>:fstps  -0x14(%ebp)
   0xb7edbb90 <+87>:mov-0x14(%ebp),%edx
   0xb7edbb93 <+90>:mov-0x4(%ebp),%eax
   0xb7edbb96 <+93>:mov%ecx,(%eax)
   0xb7edbb98 <+95>:mov%edx,0x4(%eax)
   0xb7edbb9b <+98>:addl   $0x8,-0x4(%ebp)
   0xb7edbb9f <+102>:   addl   $0x8,-0x8(%ebp)
   0xb7edbba3 <+106>:   addl   $0x4,-0xc(%ebp)
   0xb7edbba7 <+110>:   addl   $0x4,-0xc(%ebp)
   0xb7edbbab <+114>:   incl   -0x10(%ebp)
   0xb7edbbae <+117>:   mov-0x10(%ebp),%eax
   0xb7edbbb1 <+120>:   cmp0x14(%ebp),%eax
   0xb7edbbb4 <+123>:   jb 0xb7edbb61 


   0xb7edbbb6 <+125>:   leave
   0xb7edbbb7 <+126>:   ret
End of assembler dump.

Cheers,

Fred
On 03/16/2012 02:15 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 3:11 PM, Frederick Stevens 
mailto:sk8tesgr...@gmail.com>> wrote:


I've added your suggested changes.  It will be an hour or so until
compilation is finished. Slackware CFLAGS or CXXFLAGS are usually
-O2 by default.

Cheers,

Fred


Thanks. GNU Radio resets these flag to -O3 right now, though.

Also, can't you run 'make -jN' to speed up the compilation?

Tom

On 03/16/2012 02:09 PM, Tom Rondea

[Discuss-gnuradio] 50Msps performance

[Marcus D. Leech]

I thought I'd try a simple 50Msps flow-graph with the latest Gnu Radio 
to see how well it now works.


I've attached it.  As you can see, it doesn't do very much.  A UHD 
source, a single multiply, then a null sink.


On a 6-core machine running at 3.2GHz, it gets overruns, nearly 
continuously.  This isn't noticeably different from prior to the
  latest performance changes in Gnu Radio, except that the overruns 
happen at perhaps a somewhat lower rate. A single
  data point in a very complicated space, but I think processing very 
high sample rates in Gnu Radio is going to be tough.
  Although I know that the CASPER folks have done this in the past, as 
have the GMRT folks in India.  But they don't
  use Gnu Radio, but rather highly-customized stuff that doesn't 
necessarily do much processing on the samples.


This was on a AMD Phenom II X6 1090T.  Not the highest performance 
machine on the planet, but not the worst, either.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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