Re: [Discuss-gnuradio] diagnosing overflows

2017-08-19 Thread Marcus Müller 
ha, that's a bit surprising, as Debian usually keeps their "linux-tools"
package up to date, but for pretty new kernels, yes, might be necessary
to build it yourself.

Cheers,

Marcus


On 20.08.2017 00:08, Philip Hahn wrote:
> Thank you Marcus and apologies for the late reply. As it turns out
> perf is not included with Raspbian but can be compiled fairly
> easily: http://jireren.github.io/blog/2016/09/19/Compile-Perf/
>
> -philip
>
> On Thu, Aug 10, 2017 at 9:15 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi philip,
>
> to identify such bottlenecks, it's often a nice clue to know which
> block consumes the most CPU. I don't know it the Linux perf
> counters work well on ARM (simply haven't tried), but if they do:
> There's a program called perf. Usage in short
>
> sudo sysctl kernel.perf_event_paranoid=-1
> perf record -ag python yourflowgraph.py
> perf report
>
> Best regards,
> Marcus
>
>
> On 08/10/2017 03:28 AM, Philip Hahn wrote:
>> Sean - OK, I understand what you mean now, thank you - the
>> overflow is not reported until the pressure hits the source block.
>> Cinaed - In this case it is not my flowgraph but gnss-sdr which
>> I've run successfully on several platforms. In this case it is
>> running on a Raspberry Pi 3. I anticipate hitting some roadblocks
>> although reportedly it's been done before; I am trying to
>> determine the current bottleneck.
>>
>> thanks 
>>
>> philip
>>
>> On Wed, Aug 9, 2017 at 3:15 PM, Cinaed Simson
>> mailto:cinaed.sim...@gmail.com>> wrote:
>>
>> On 08/08/2017 07:56 PM, Philip Hahn wrote:
>> > Folks,
>> >
>> >  Is there a way to diagnose which block first reports an
>> overflow in a
>> > flowgraph?
>> >
>> >  In my particular instance I am running a flowgraph which
>> is overflowing
>> > without pegging either RAM or CPU.
>>
>> It could also be an error in the plumbing of your flowgraph.
>>
>> -- Cinaed
>>
>>
>>
>> >
>> >  Thank you,
>> >
>> > philip
>> >
>> >
>> > ___
>> > 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
> 
>
>

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

Re: [Discuss-gnuradio] diagnosing overflows

2017-08-19 Thread Philip Hahn 
Thank you Marcus and apologies for the late reply. As it turns out perf is
not included with Raspbian but can be compiled fairly easily:
http://jireren.github.io/blog/2016/09/19/Compile-Perf/

-philip

On Thu, Aug 10, 2017 at 9:15 AM, Marcus Müller 
wrote:

> Hi philip,
>
> to identify such bottlenecks, it's often a nice clue to know which block
> consumes the most CPU. I don't know it the Linux perf counters work well on
> ARM (simply haven't tried), but if they do: There's a program called perf.
> Usage in short
>
> sudo sysctl kernel.perf_event_paranoid=-1
> perf record -ag python yourflowgraph.py
> perf report
> Best regards,
> Marcus
>
>
> On 08/10/2017 03:28 AM, Philip Hahn wrote:
>
> Sean - OK, I understand what you mean now, thank you - the overflow is not
> reported until the pressure hits the source block.
> Cinaed - In this case it is not my flowgraph but gnss-sdr which I've run
> successfully on several platforms. In this case it is running on a
> Raspberry Pi 3. I anticipate hitting some roadblocks although reportedly
> it's been done before; I am trying to determine the current bottleneck.
>
> thanks
>
> philip
>
> On Wed, Aug 9, 2017 at 3:15 PM, Cinaed Simson 
> wrote:
>
>> On 08/08/2017 07:56 PM, Philip Hahn wrote:
>> > Folks,
>> >
>> >  Is there a way to diagnose which block first reports an overflow in a
>> > flowgraph?
>> >
>> >  In my particular instance I am running a flowgraph which is overflowing
>> > without pegging either RAM or CPU.
>>
>> It could also be an error in the plumbing of your flowgraph.
>>
>> -- Cinaed
>>
>>
>>
>> >
>> >  Thank you,
>> >
>> > philip
>> >
>> >
>> > ___
>> > 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 
> listDiscuss-gnuradio@gnu.orghttps://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] diagnosing overflows

2017-08-10 Thread Marcus Müller 
Hi philip,

to identify such bottlenecks, it's often a nice clue to know which block
consumes the most CPU. I don't know it the Linux perf counters work well
on ARM (simply haven't tried), but if they do: There's a program called
perf. Usage in short

sudo sysctl kernel.perf_event_paranoid=-1
perf record -ag python yourflowgraph.py
perf report

Best regards,
Marcus

On 08/10/2017 03:28 AM, Philip Hahn wrote:
> Sean - OK, I understand what you mean now, thank you - the overflow is
> not reported until the pressure hits the source block.
> Cinaed - In this case it is not my flowgraph but gnss-sdr which I've
> run successfully on several platforms. In this case it is running on a
> Raspberry Pi 3. I anticipate hitting some roadblocks although
> reportedly it's been done before; I am trying to determine the current
> bottleneck.
>
> thanks 
>
> philip
>
> On Wed, Aug 9, 2017 at 3:15 PM, Cinaed Simson  > wrote:
>
> On 08/08/2017 07:56 PM, Philip Hahn wrote:
> > Folks,
> >
> >  Is there a way to diagnose which block first reports an
> overflow in a
> > flowgraph?
> >
> >  In my particular instance I am running a flowgraph which is
> overflowing
> > without pegging either RAM or CPU.
>
> It could also be an error in the plumbing of your flowgraph.
>
> -- Cinaed
>
>
>
> >
> >  Thank you,
> >
> > philip
> >
> >
> > ___
> > 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] diagnosing overflows

2017-08-09 Thread Philip Hahn 
Sean - OK, I understand what you mean now, thank you - the overflow is not
reported until the pressure hits the source block.
Cinaed - In this case it is not my flowgraph but gnss-sdr which I've run
successfully on several platforms. In this case it is running on a
Raspberry Pi 3. I anticipate hitting some roadblocks although reportedly
it's been done before; I am trying to determine the current bottleneck.

thanks

philip

On Wed, Aug 9, 2017 at 3:15 PM, Cinaed Simson 
wrote:

> On 08/08/2017 07:56 PM, Philip Hahn wrote:
> > Folks,
> >
> >  Is there a way to diagnose which block first reports an overflow in a
> > flowgraph?
> >
> >  In my particular instance I am running a flowgraph which is overflowing
> > without pegging either RAM or CPU.
>
> It could also be an error in the plumbing of your flowgraph.
>
> -- Cinaed
>
>
>
> >
> >  Thank you,
> >
> > philip
> >
> >
> > ___
> > 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] diagnosing overflows

2017-08-09 Thread Cinaed Simson 
On 08/08/2017 07:56 PM, Philip Hahn wrote:
> Folks,
> 
>  Is there a way to diagnose which block first reports an overflow in a
> flowgraph? 
> 
>  In my particular instance I am running a flowgraph which is overflowing
> without pegging either RAM or CPU. 

It could also be an error in the plumbing of your flowgraph.

-- Cinaed



> 
>  Thank you,
> 
> philip
> 
> 
> ___
> 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] diagnosing overflows

2017-08-08 Thread Sean Horton 
Hi Philip,

Check out line 188:
https://github.com/osmocom/gr-osmosdr/blob/master/lib/osmosdr/osmosdr_src_c.cc


It would appear that other driver writers have followed the lead of Ettus
and use the same letters to indicate the same error. I've only looked at
this code for an entire five minutes, but it looks like the code is
initialized with a string that is fed to a dictionary, and after that,
_buf_len's size is set from the dictionary, or if there's no entry in the
dictionary, sets it to 15. Perhaps you could increase your buffer size?
Also, if you're building from source, perhaps you can use -O2 or -O3 when
you build it? I don't see any optimization flags set in the top-level
CMakeLists.txt

In my limited experience with overflows, the two solutions I have used are
1) sample the input at a lower rate, or if the input sample rate has to be
at whatever level it is, 2) decimate the samples as soon as possible.

Regards,
Sean

On Tue, Aug 8, 2017 at 8:53 PM, Philip Hahn  wrote:

> Hi Sean,
>
>  I am not using UHD blocks, I am using osmocom source/sinks. I did not see
> any warnings about changing buffer sizes.
>
>  Thank you,
>
> philip
>
> On Tue, Aug 8, 2017 at 8:42 PM, Sean Horton 
> wrote:
>
>> Unless I'm mistaken, only the usrp sink/source blocks report overflow
>> (source) or underflow (sink). You can see this mentioned in
>> uhd/docs/general.dox (uhd github repo).
>>
>> Did you listen to the warnings you get on startup about changing buffer
>> sizes with a series of commands requiring sudo? That helped me resolve some
>> overflow, otherwise it sounds like you'll need to drop your sample rate
>> unless you need it as high as it currently is.
>>
>> Regards,
>> Sean
>>
>> On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn  wrote:
>>
>>> Folks,
>>>
>>>  Is there a way to diagnose which block first reports an overflow in a
>>> flowgraph?
>>>
>>>  In my particular instance I am running a flowgraph which is overflowing
>>> without pegging either RAM or CPU.
>>>
>>>  Thank you,
>>>
>>> philip
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> Sean Horton
>>
>>
>


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

Re: [Discuss-gnuradio] diagnosing overflows

2017-08-08 Thread Philip Hahn 
Hi Sean,

 I am not using UHD blocks, I am using osmocom source/sinks. I did not see
any warnings about changing buffer sizes.

 Thank you,

philip

On Tue, Aug 8, 2017 at 8:42 PM, Sean Horton  wrote:

> Unless I'm mistaken, only the usrp sink/source blocks report overflow
> (source) or underflow (sink). You can see this mentioned in
> uhd/docs/general.dox (uhd github repo).
>
> Did you listen to the warnings you get on startup about changing buffer
> sizes with a series of commands requiring sudo? That helped me resolve some
> overflow, otherwise it sounds like you'll need to drop your sample rate
> unless you need it as high as it currently is.
>
> Regards,
> Sean
>
> On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn  wrote:
>
>> Folks,
>>
>>  Is there a way to diagnose which block first reports an overflow in a
>> flowgraph?
>>
>>  In my particular instance I am running a flowgraph which is overflowing
>> without pegging either RAM or CPU.
>>
>>  Thank you,
>>
>> philip
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Sean Horton
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] diagnosing overflows

2017-08-08 Thread Sean Horton 
Unless I'm mistaken, only the usrp sink/source blocks report overflow
(source) or underflow (sink). You can see this mentioned in
uhd/docs/general.dox (uhd github repo).

Did you listen to the warnings you get on startup about changing buffer
sizes with a series of commands requiring sudo? That helped me resolve some
overflow, otherwise it sounds like you'll need to drop your sample rate
unless you need it as high as it currently is.

Regards,
Sean

On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn  wrote:

> Folks,
>
>  Is there a way to diagnose which block first reports an overflow in a
> flowgraph?
>
>  In my particular instance I am running a flowgraph which is overflowing
> without pegging either RAM or CPU.
>
>  Thank you,
>
> philip
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

[Discuss-gnuradio] diagnosing overflows

2017-08-08 Thread Philip Hahn 
Folks,

 Is there a way to diagnose which block first reports an overflow in a
flowgraph?

 In my particular instance I am running a flowgraph which is overflowing
without pegging either RAM or CPU.

 Thank you,

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