Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[West, Nathan]

On Tue, Nov 25, 2014 at 11:47 AM, madengr  wrote:
> Sorry, the boostrapping was a guess on my part, as I recall having a similar
> issue a while back and seeing this:
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-07/msg00486.html
>
> Lou
>
>
> West, Nathan wrote
>> On Tue, Nov 25, 2014 at 10:50 AM, West, Nathan
>> <
>
>> natw@.okstate
>
>> > wrote:
>>
>> Forgot to hit reply-all the first time.
>>
>> I'm not sure where this suggestion is coming from, but installing VOLK
>> has nothing to do with the QA. There is no bootstrapping VOLK, in fact
>> the there's something like a 99% overlap between code executed when
>> runing 'make test' on VOLK and volk_profile.
>>
>> If you have experience where make test fails on VOLK, but passes
>> after installing I would like to hear about it because it's the sign of a
>> bug.
>>
>> Nathan
>>

Ah, yes. That was to test a bug. If you ever have to run volk_profile
to make QA pass then there's a bug and it should be reported. The
normal operating procedure should be to install, then run volk_profile
and be done.

Nathan

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

Re: [Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

That fixed it! Thanks!!

2014-11-25 18:48 GMT+01:00 Marcus Müller :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Does increasing kernel.shmmni using sysctl to let's say 16k improve
> the situation?
>
> On 11/25/2014 06:37 PM, Marcus Müller wrote:
> > Hi Felix,
> >
> >
> > On 11/25/2014 06:15 PM, Felix W. wrote:
> >> Between every run, I call tb.stop() followed by tb.wait().
> >> Unfortunately, after a few runs (around 20), I get the following
> >> error message:
> >
> >> gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
> > I have a suspicion. First of all, I know this sounds basic, but
> > you're not using a 32bit GR on your 64 bit machine, are you? (that
> > would explain running out of RAM faster, just because process
> > memory is so very limited for 32bit processes)
> >
> > then: vmcircbuf is one of the things I always was kind of hesitant
> > to touch (or even try to understand in depth), just because it
> > deals with a lot of POSIX/OS specifics that I'm not an expert in,
> > but:
> >
> > Maybe tb.stop()/wait doesn't actually successfully unmap the
> > shared memory segments of the buffers; there's a global maximum of
> > segments, and it 4096 by default (/proc/sys/kernel/shmmni).
> > However, this shouldn't be the problem at hand: there's an error
> > number for this condition. And it would be: ENOSPC. Great. The same
> > thing as for "No space left on device"; Thank you, Posix.1...
> >
> > Cheers, Marcus
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUdMD0AAoJEAFxB7BbsDrL88sIAKE8Ic6WLuvIXcjVl9Rtiwrk
> OMGx6iL07PpWDlZBJfU5Twy0O4T+VYSQiwp5DtyMAe60zUH1uBP3eUQ/e9fyFLsN
> VV89J9MB4lGlhg8m73kjj8yV2RrM9TttccU9yXHyUiVTQGQ838GRE5QS/CULv3bv
> A2hZXX+IVfZLPuxmbd1fuiVDHcX5fxrlPHgLcZRWtOGJkVuvkRYip7mwtHInaVFD
> xO6bI8CuujYUAJPKvUbRe3QIyKkxzLi2SPe4Vzn52KqAagwVy1fb8BK109fQ97fU
> EPDMedpv5sTbRcB9mhY8SSi3bXaY01C5bLQIT8mw61Tp4D2/AUVdXSJykEc/0HQ=
> =o6F6
> -END PGP SIGNATURE-
>
> ___
> 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] Install: qa_volk_test_all fails

[madengr]

Sorry, the boostrapping was a guess on my part, as I recall having a similar
issue a while back and seeing this:

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-07/msg00486.html

Lou


West, Nathan wrote
> On Tue, Nov 25, 2014 at 10:50 AM, West, Nathan
> <

> natw@.okstate

> > wrote:
> 
> Forgot to hit reply-all the first time.
> 
> I'm not sure where this suggestion is coming from, but installing VOLK
> has nothing to do with the QA. There is no bootstrapping VOLK, in fact
> the there's something like a 99% overlap between code executed when
> runing 'make test' on VOLK and volk_profile.
> 
> If you have experience where make test fails on VOLK, but passes
> after installing I would like to hear about it because it's the sign of a
> bug.
> 
> Nathan
> 
> ___
> Discuss-gnuradio mailing list

> Discuss-gnuradio@

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51442.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] Running out of memory during BER simulations

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Does increasing kernel.shmmni using sysctl to let's say 16k improve
the situation?

On 11/25/2014 06:37 PM, Marcus Müller wrote:
> Hi Felix,
> 
> 
> On 11/25/2014 06:15 PM, Felix W. wrote:
>> Between every run, I call tb.stop() followed by tb.wait(). 
>> Unfortunately, after a few runs (around 20), I get the following 
>> error message:
> 
>> gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
> I have a suspicion. First of all, I know this sounds basic, but
> you're not using a 32bit GR on your 64 bit machine, are you? (that
> would explain running out of RAM faster, just because process
> memory is so very limited for 32bit processes)
> 
> then: vmcircbuf is one of the things I always was kind of hesitant
> to touch (or even try to understand in depth), just because it
> deals with a lot of POSIX/OS specifics that I'm not an expert in,
> but:
> 
> Maybe tb.stop()/wait doesn't actually successfully unmap the
> shared memory segments of the buffers; there's a global maximum of
> segments, and it 4096 by default (/proc/sys/kernel/shmmni).
> However, this shouldn't be the problem at hand: there's an error
> number for this condition. And it would be: ENOSPC. Great. The same
> thing as for "No space left on device"; Thank you, Posix.1...
> 
> Cheers, Marcus
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdMD0AAoJEAFxB7BbsDrL88sIAKE8Ic6WLuvIXcjVl9Rtiwrk
OMGx6iL07PpWDlZBJfU5Twy0O4T+VYSQiwp5DtyMAe60zUH1uBP3eUQ/e9fyFLsN
VV89J9MB4lGlhg8m73kjj8yV2RrM9TttccU9yXHyUiVTQGQ838GRE5QS/CULv3bv
A2hZXX+IVfZLPuxmbd1fuiVDHcX5fxrlPHgLcZRWtOGJkVuvkRYip7mwtHInaVFD
xO6bI8CuujYUAJPKvUbRe3QIyKkxzLi2SPe4Vzn52KqAagwVy1fb8BK109fQ97fU
EPDMedpv5sTbRcB9mhY8SSi3bXaY01C5bLQIT8mw61Tp4D2/AUVdXSJykEc/0HQ=
=o6F6
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

I built GR from source on the machine and the machine is running Ubuntu
14.04 64-bit. So I guess my GR is 64-bit, too.

Actually, while watching the simulation running at the moment, I noticed
that memory usage is indeed increasing slowly (but at a rate that wouldn't
fill up the system memory in days...).

2014-11-25 18:37 GMT+01:00 Marcus Müller :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Felix,
>
>
> On 11/25/2014 06:15 PM, Felix W. wrote:
> > Between every run, I call tb.stop() followed by tb.wait().
> > Unfortunately, after a few runs (around 20), I get the following
> > error message:
> >
> > gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
> I have a suspicion.
> First of all, I know this sounds basic, but you're not using a 32bit
> GR on your 64 bit machine, are you? (that would explain running out of
> RAM faster, just because process memory is so very limited for 32bit
> processes)
>
> then: vmcircbuf is one of the things I always was kind of hesitant to
> touch (or even try to understand in depth), just because it deals with
> a lot of POSIX/OS specifics that I'm not an expert in, but:
>
> Maybe tb.stop()/wait doesn't actually successfully unmap the shared
> memory segments of the buffers; there's a global maximum of segments,
> and it 4096 by default (/proc/sys/kernel/shmmni). However, this
> shouldn't be the problem at hand: there's an error number for this
> condition. And it would be: ENOSPC. Great. The same thing as for "No
> space left on device"; Thank you, Posix.1...
>
> Cheers,
> Marcus
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUdL5ZAAoJEAFxB7BbsDrLaIcH/3GZa562FhMLZ7vqafSEQnBG
> o3DWr54Wmq1NFbWGVuLTdT4+QFFn5UN5s7RKCdmhJ+KVeqxisV/nCSbH/WfShx8Y
> DIq5o28BWsudwNsxtkq94mo57ELgj27fnHItIthqSsPGcUuIX4xszL7YTxsD++ai
> Fz6wikE7rt0+01sP5OeIXKpJkXAvWB7VLX+M89tlDCWceF9Nr0nJCleLZCLXSeIq
> 0n+u7RR3iXU6+RSyDLgK9KNCtNiUyb0p24L4m+jqsAQ/IfT6J/Ip0X5CFLoXg1A3
> ocBj6+kT1bq9aztRE2j92ZLVk//CKiuWANCo2lahNUatVehQJ0kANT2DDwp8rNU=
> =32+6
> -END PGP SIGNATURE-
>
> ___
> 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] Running out of memory during BER simulations

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Felix,


On 11/25/2014 06:15 PM, Felix W. wrote:
> Between every run, I call tb.stop() followed by tb.wait().
> Unfortunately, after a few runs (around 20), I get the following
> error message:
> 
> gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
I have a suspicion.
First of all, I know this sounds basic, but you're not using a 32bit
GR on your 64 bit machine, are you? (that would explain running out of
RAM faster, just because process memory is so very limited for 32bit
processes)

then: vmcircbuf is one of the things I always was kind of hesitant to
touch (or even try to understand in depth), just because it deals with
a lot of POSIX/OS specifics that I'm not an expert in, but:

Maybe tb.stop()/wait doesn't actually successfully unmap the shared
memory segments of the buffers; there's a global maximum of segments,
and it 4096 by default (/proc/sys/kernel/shmmni). However, this
shouldn't be the problem at hand: there's an error number for this
condition. And it would be: ENOSPC. Great. The same thing as for "No
space left on device"; Thank you, Posix.1...

Cheers,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdL5ZAAoJEAFxB7BbsDrLaIcH/3GZa562FhMLZ7vqafSEQnBG
o3DWr54Wmq1NFbWGVuLTdT4+QFFn5UN5s7RKCdmhJ+KVeqxisV/nCSbH/WfShx8Y
DIq5o28BWsudwNsxtkq94mo57ELgj27fnHItIthqSsPGcUuIX4xszL7YTxsD++ai
Fz6wikE7rt0+01sP5OeIXKpJkXAvWB7VLX+M89tlDCWceF9Nr0nJCleLZCLXSeIq
0n+u7RR3iXU6+RSyDLgK9KNCtNiUyb0p24L4m+jqsAQ/IfT6J/Ip0X5CFLoXg1A3
ocBj6+kT1bq9aztRE2j92ZLVk//CKiuWANCo2lahNUatVehQJ0kANT2DDwp8rNU=
=32+6
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Running out of memory during BER simulations

[Felix W.]

Hi list,

I'm currently performing BER measurements for an IEEE 802.15.4 system. In
order to do so, I have created a flowgraph (in GRC/python) that is executed
for different SNR values until a certain number of bits has been processed.
Between every run, I call tb.stop() followed by tb.wait(). Unfortunately,
after a few runs (around 20), I get the following error message:

gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

sysctl says:
kernel.shmall = 2097152
kernel.shmmax = 2147483648

I don't really understand why this happens as my memory usage is very
stable and < 20% of total RAM throughout the simulation. In my
understanding, calling, tb.stop() and tb.wait() should delete anything the
flowgraph allocated before. I also noticed that the block numbers (which
are displayed because I call set_min_output_buffer() ) are monotonically
increasing during the simulation even though the top block is stopped
multiple times. This might be completely unrelated, however it indicates
that my understanding might not be correct.

Any ideas?

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[West, Nathan]

On Tue, Nov 25, 2014 at 10:50 AM, West, Nathan
 wrote:
> On Tue, Nov 25, 2014 at 7:46 AM, madengr  wrote:
>>
>> Try my other suggestion if the above does not work.  My guess is the VOLK
>> tests won't work since this is your first time installing gnuradio, and you
>> have not run the volk_profile. In which case you need to bootstrap by
>> installing it first, run volk_profile, then you can run the tests.
>>
>>
>> Lou
>

Forgot to hit reply-all the first time.

I'm not sure where this suggestion is coming from, but installing VOLK
has nothing to do with the QA. There is no bootstrapping VOLK, in fact
the there's something like a 99% overlap between code executed when
runing 'make test' on VOLK and volk_profile.

If you have experience where make test fails on VOLK, but passes
after installing I would like to hear about it because it's the sign of a bug.

Nathan

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[West, Nathan]

On Tue, Nov 25, 2014 at 9:56 AM, Cocacola93  wrote:
> I try volk_profile
>
> but
>
> 98% tests passed, 4 tests failed out of 193
>
> Total Test time (real) = 258.68 sec
>
> The following tests FAILED:
>   1 - qa_volk_test_all (Failed)
>  31 - qa_udp_source_sink (Failed)
> 181 - qa_trellis (Failed)
> 187 - qa_codec2_vocoder (Failed)
> Errors while running CTest
> make: *** [test] Error 8
>
> Thank you for instructions.

A) Since you don't have much experience I recommend using a binary
distribution of GNU Radio provided by your distribution. See the
official recommendation here:
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR

B) Inside your build direction can you run the following commands and
send the output? If it's long copy it to a website like fpaste.org

ctest -V -R volk | grep -C 5 offset
cat /proc/cpuinfo | grep 'model name'

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[Cocacola93]

Thank you for instructions
 I haven't already acquired a lot of experience  
I need more advice



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51435.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] Install: qa_volk_test_all fails

[Cocacola93]

I try volk_profile 

but  

98% tests passed, 4 tests failed out of 193

Total Test time (real) = 258.68 sec

The following tests FAILED:
  1 - qa_volk_test_all (Failed)
 31 - qa_udp_source_sink (Failed)
181 - qa_trellis (Failed)
187 - qa_codec2_vocoder (Failed)
Errors while running CTest
make: *** [test] Error 8

Thank you for instructions.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51434.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] Inconsistant Gain in X310

[Daigle, Andrew - 1008 - MITLL]

Marcus,

The FFT plots for power levels below and above this non-linear power response 
threshold in Channel 2 have been provided below. Here a 50.1 MHz tone was 
channeled into the USRP via a splitter. The USRP channels were set with a rate 
of 1M samples per second and a 50 MHz CF. I’ve tried this in multiple X310s 
with multiple different basic RX cards and they all have the same response and 
always in the second channel around ~-45 dBm.

[cid:image006.jpg@01D00897.1A139800]

Here Channel 1 acts exactly as you would expect with the peak 100kHz above DC. 
The Channel 2 response is almost identical to Channel 1 for powers below -50 
dBm and then jumps quite dramatically around -44 dBm. At -40 dBm there is a 
significant constant difference between the channels. This behavior is mirrored 
in the time domain (below) where in the first viewgraph the two channels of IQ 
pairs are identical. Once the power exceeds the power threshold the second 
channel (purple here) varies wildly compared to channel one. It is almost as if 
I was saturating an amplifier and the signal is being coupled to a higher order 
mode? The thing that confuses me the most is that nothing here is changing 
other than the input power. There is nothing in the software or hardware that I 
can tell that would be affected by an increasing input power level. Especially 
one so low compared to the input power limit of -15 dBm? I would also expect 
the RF chains within the USRP to be identical for each channel so I don’t see 
why it is only happening in CH2.

[cid:image007.jpg@01D00897.1A139800]

Thanks!

-Andrew

From: discuss-gnuradio-bounces+andrew.daigle=ll.mit@gnu.org 
[mailto:discuss-gnuradio-bounces+andrew.daigle=ll.mit@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Monday, November 24, 2014 4:58 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Inconsistant Gain in X310

On 11/24/2014 10:26 AM, Daigle, Andrew - 1008 - MITLL wrote:
Ben,

I have tried injecting both a 50.0 MHz and a 50.1 MHz tone and setting the USRP 
with a center frequency of 50 MHz and a sampling rate of 1 MSps. The signal 
generator I am using is clocked with the same 10 MHz reference as the USRP 
(octoclock). I am currently setting the digital gain to zero (though I have 
tried a number of different values with no noticeable differences in terms of 
this non-linearity to input power). I have also tried inserting a LO offset, 
but haven’t had any real success with that either (outside of removing the 
small peak at DC). I tried disabling the DC offset but that didn’t do anything 
either.

Looking in the time domain at the IQ for each of the channels I see two things 
which appear strange to me. First, when I set the USRP center frequency to the 
same frequency as my tone (50 MHz) I would expect a flat line, but instead I 
see a triangular wave with a non-zero amplitude (actually it is quite large). 
When I offset the frequencies I see a very noisy sinusoid which has the wave on 
it. As the power increases, the channels scale evenly in both noise and 
intensity, but at a threshold power level (~45 dBm) it appears as though 
leakage occurs between the main sinusoidal wave and this secondary carrier 
signal.

[cid:image005.jpg@01D00894.8887AF40]

Thoughts? Thanks for taking the time to look at this.

-Andrew
Andrew:

What does the following test flow-graph yield?   With the same signal input to 
both sides (via a splitter):

http://www.sbrac.org/files/test_x310_basicrx.grc

If you're injecting a -50dBm test tone at 50.1MHz, you should see it at 100kHz 
in the FFT display of each half, and within 1dB of each other.




From: Ben Hilburn [mailto:b...@ettus.com]
Sent: Friday, November 21, 2014 7:36 PM
To: Daigle, Andrew - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Inconsistant Gain in X310

Hi Andrew -

What you describe is very strange. There is nothing in the USRP that changes 
dynamically based on the input power level (there isn't even AGC). The only 
thing I can think of is that somehow the built-in DC offset calibration is 
going haywire. Are you setting the center frequency directly to the frequency 
of your input signal? If you tune with an LO offset, do you see the same 
behavior?

Another question: what is your signal source? Can you lock the USRP and your 
signal source to the same reference, and then tune such that your input signal 
is directly "over an FFT bin"? Do you still see different behavior between the 
two channels?

Also, the decimation is done in the FPGA, and must be the same for each channel.

Cheers,
Ben

On Fri, Nov 21, 2014 at 7:17 AM, Daigle, Andrew - 1008 - MITLL 
mailto:andrew.dai...@ll.mit.edu>> wrote:
Hello,

I am running into a small issue with the X310 USRP. My basic setup involves 
receiving from two antennas (or at this point CW tones from signal generators) 
using two basic RX daughter cards.

My problem is that when I pump in a -50 dBm CW tone to chann

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cocacola93,

On 11/25/2014 01:45 PM, Cocacola93 wrote:
> openbts@nujmee:~/gnuradio/build$ Run volk_profile Run: command not
> found

running a command means executing the same; instead of doing "Run
volk_profile", you should just have typed "volk_profile".

I don't mean to discourage you, but it might be wise to first spend
some time getting to grips with your linux machine before trying to do
GNU Radio, or even openBTS, as these are fairly complex systems; if
left alone with all the problems you'll encounter on the way to
getting everything to run, it seems that you haven't already acquired
a lot of experience in understanding helpful instructions.

Greetings,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdIyCAAoJEAFxB7BbsDrLiEIH/AxRyVywZChsS8iklLvaj4GO
AwwpfkZu+GPNQn8lEKP7FAa75H8OiprhxRTQBZUfgI+la1oppOtYyVoHx+jYEhu5
hs9yvvO0hb37FgpG22HpRgXWVMDalDYg4kflx/ElGJ3+PLhnZAQxX82BLwYcEBuN
n+1cdPfHcqwMQk7oz9B6ZiFp76WGHG1pA99S3rm3v3h75Q6XJbV+nmHWI3c1bTCK
wAQvNeTLesstv+66rqdRnx8ToiLZ29oeSO1BxdIfVVzBd+J6J2aGxSJ1fYCcLWHb
MtwsWzvD+ejtPtLZ7OV4zDVT6tD8hTnZM/g60sL2UDASmHx+BYzAnPQCKu1AC/A=
=9zwZ
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails

[madengr]

No, do not type:
Run volk_profile

Type this:
volk_profile

Try my other suggestion if the above does not work.  My guess is the VOLK
tests won't work since this is your first time installing gnuradio, and you
have not run the volk_profile. In which case you need to bootstrap by
installing it first, run volk_profile, then you can run the tests.

If that does not work, I'm not sure what to do and maybe someone else has an
idea.

By the way, the "udp source sink" fails for me too.

Lou
  


Cocacola93 wrote
> openbts@nujmee:~/gnuradio/build$ Run volk_profile
> Run: command not found





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51431.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] Install: qa_volk_test_all fails

[madengr]

I assume this is your first install and VOLK has not been profiled already,
in which case you need to do a:  

sudo make install
sudo ldconfig
volk_profile
make test


Cocacola93 wrote
> openbts@nujmee:~/gnuradio/build$ Run volk_profile
> Run: command not found





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51430.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] Install: qa_volk_test_all fails

[Cocacola93]

openbts@nujmee:~/gnuradio/build$ Run volk_profile
Run: command not found





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51429.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] QT GUI Time Sink text scale bug

[Martin Braun]

On 11/25/2014 04:08 AM, madengr wrote:
> Marcus,
> 
> OK; dumb question.  How do I apply that, other an editing the source
> manually?  I tried the following, but it didn't like it:
> 
> cd /usr/local/src/gnuradio/
> patch < 0001-qtgui-fixed-non-changing-from-sec-to-ms.patch

$ git apply foo.patch

M


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

Re: [Discuss-gnuradio] GNURadio retrictions

[Martin Braun]

On 11/25/2014 07:37 AM, Mostafa Alizadeh wrote:
> No, it doesn't. At least the GNU Radio scheduler won't interrupt a work
> function
> 
> I believe in what I see in GNURadio! It forsakes the work's routine
> somewhere in amidst of it!!

It really doesn't. Other works() are also running, though.

> Underneath, of course, lies a runtime environment (boost threads), which
> uses underlying threading libraries (on unixoids usually pthreads),
> which use the underlying operating system's multithreading routines
> (aka. the OS's scheduler) , which will execute blocks interleaved
> (depending on system architecture, number of CPUs etc).
> 
> OK, these information doesn't solve the problem at least for me who
> don't know anything about boost.

Boost implements fairly standard multithreading paradigms, which you
should make yourself acquainted with if you want to do multithreading stuff.

However, you don't *need* to do this. Our stuff is designed to work
thread-safely. If you stick to all the rules and build blocks the way
they should be written, you will only run into issues if there's
actually a bug, which it doesn't sound like reading your emails.


> This is also so complicated, I forgot to add, that sometime calling the
> produce() function before add_item_tag() increments the nitems_written()
> and sometime doesn't why??

It doesn't. See here:

  void
  block_detail::produce(int which_output, int how_many_items)
  {
if(how_many_items > 0) {
  d_output[which_output]->update_write_pointer(how_many_items);
  d_produce_or |= how_many_items;
}
  }

and here:

  void
  buffer::update_write_pointer(int nitems)
  {
gr::thread::scoped_lock guard(*mutex());
d_write_index = index_add(d_write_index, nitems);
d_abs_write_offset += nitems; // == nitems_written()
  }

My guess is your debugging and inspection methods are inadequate.

M

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

Re: [Discuss-gnuradio] GNURadio retrictions

[Marcus Müller]

Hi Mostafa

On 11/25/2014 07:37 AM, Mostafa Alizadeh wrote:
>> No, it doesn't. At least the GNU Radio scheduler won't interrupt a work
>> function
>>
> 
> I believe in what I see in GNURadio! It forsakes the work's routine
> somewhere in amidst of it!!
This would *really* surprise me. What does "forsake" mean here? Does the
computer then execute another work function, just to come back to the
current one later?

>>
> OK, these information doesn't solve the problem at least for me who don't
> know anything about boost.
Well, the point here is that it's not about knowing boost, it's about
understanding multithreading on current operating systems, which is
quite a bit more theoretical. However, you're describing problems that
neither Sylvain nor me can reproduce and I'm afraid you have some
misconception about how things in GR work together, and how a thread works.

> I swear that I wrote a clean code :), I see what I see.
The code you shared did two different things, though you claimed it
should do the same. Sylvain and me *both* pointed out that it *should
not* do the same and the code works as designed. I swear your code does
what it should by definition. You just wrote the wrong code if you want
something else :)
> 
> This is also so complicated, I forgot to add, that sometime calling the
> produce() function before add_item_tag() increments the nitems_written()
> and sometime doesn't why??
produce() will always instantly increase the value nitems_written()
returns, because that is the only job of produce().
block::nitems_written() just calls block_detail::nitems_written() which
returns its underlying buffer::nitems_written() which is defined in
buffer.h as
uint64_t nitems_written() { return d_abs_write_offset; }
The delegate chain for produce is block::produce returning
block_detail::produce which calls buffer::update_write_pointer which is
defined in buffer.cc as
d_abs_write_offset += nitems;
There's no ambiguity anywhere here, no if()s, not a single point where
we don't increase the return value of nitems_written() by the amount of
samples you produce(). I don't see how that "sometimes" could increase
and sometimes not. Pretty sure you're not really seeing GNU Radio misbehave.

Best regards,
Marcus

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

Re: [Discuss-gnuradio] GNURadio retrictions

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As Sylvain said, produce() actually means "hey, I'm finished with
producing these items, so do what you want in another block (ie. in
another thread", so obviously, the things like nitems_written must
reflect this.

On 11/25/2014 07:42 AM, Mostafa Alizadeh wrote:
> On Mon, Nov 24, 2014 at 4:11 PM, Sylvain Munaut <246...@gmail.com>
> wrote:
> 
>>> Please help me find the rational reason!
>> 
>> Because calling "produce" means, "I'm done, go ahead and take
>> those sample". Don't call it until you are reall done ...
>> 
>> GR is a multi-threaded applications, each work() function is
>> executed in different threads and as soon as you call produce(),
>> other threads are signalled that the samples are ready.
>> 
>> 
>> Cheers,
>> 
>> Sylvain
>> 
> 
> 
> Hi Sylvain,
> 
> I infer from what you said that what I see is true and logical! In
> another word, the nitems_written can be updated permanently in the
> middle of the work's routine. OK
> 
> But I still think that this is not logical to update the number of
> items written before returning from work call.
> 
> Thank you, Mostafa
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdDu+AAoJEAFxB7BbsDrL/ZoH/jhy/Mqgfe6EyU2gA1fId11o
fi9CMUYGd0n0vbqgqHap4+qYbDeKdFNk81jp2KgOyqPC8Al/JPlVQJNX3QwFW+w3
O4a1hMqHbGIf9ktP45kpuQH/PgH1yMJD805IueJYjxBqrU2VDXTuGr9P8dqfbfz9
xCrbkHMDLIV0eJEiZ67d3U3ldFUj1XSYBsPRdpAs+hnsmsfmyUB6fJHGxucil1DW
o6a0FxU4dZvAfdcjSUTkz2Kq8N9NUekPcMfBeTDDZqMctdDUtv0+Ggr8cqZ++uHd
SqscQLEbS8XXnTrSEXb3PLij/wz2f+4AZFkPlzRDc/0R4jHiCdW/E1lpkWznwtQ=
=N8Wx
-END PGP SIGNATURE-

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