Re: [Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the absence of samples

[Eric Statzer]

On Wed, Sep 9, 2015 at 12:41 PM Tom Rondeau  wrote:

> On Thu, Sep 3, 2015 at 7:17 AM, Eric Statzer 
> wrote:
>
>> I'm attempting to use ctrlport_probe2_x and gr-ctrlport-monitor to probe
>> points in a bursty flowgraph.  When I place a ctrlport_probe2_x probe
>> somewhere in the part of my flowgraph that process samples only upon
>> reception of a burst, gr-ctrlport-monitor doesn't fully initialize
>> (populate its list of controlport "knobs") until after all
>> ctrlport_probe2_x blocks have performed at least one call to work().
>> Furthermore, the gr-ctrlport-monitor GUI is only responsive to user input
>> if all ctrlport_probe2_x blocks in the flowgraph are regularly making calls
>> to work() (i.e. gr-ctrlport-monitor query latency becomes equal to the time
>> that elapses between processing individual bursts), so if for some reason
>> bursts ever stop trickling to one of the probes, gr-ctrlport-monitor
>> becomes unresponsive to user input.
>>
>> The gr-ctrlport-monitor behavior can be recreated with any simple
>> flowgraph that contains a ctrlport_probe2_x that will never (or
>> infrequently) make a call to work, such as: random_pdu ->
>> pdu_to_tagged_stream -> ctrlport_probe2_b, where the "generate" port of the
>> random_pdu block is left unconnected.  Attempting to connect
>> gr-ctrlport-monitor to this flowgraph will cause gr-ctrlport-monitor to be
>> unresponsive (have to kill it) almost immediately after the GUI is
>> displayed.
>>
>> I wasn't sure if this is a limitation of ctrlport_probe2_x or
>> gr-ctrlport-monitor, but I wanted to see if t was was possible to make the
>> combination play nicely together when applied to a bursty flowgraph.
>>
>> Relevant system info:
>>   GNU Radio 3.7.8
>>   Thrift 0.9.2
>>   Ubuntu 15.04
>>
>> Thanks in advance,
>> Eric
>>
>
> Eric,
>
> Have you tried increasing the number of threads in the thrift server? Try
> making/modifying ~/.gnuradio/thrift.conf with:
>
> [thrift]
> nthreads = 10 (or some number greater than the number of probe blocks you
> have)
>
> (and make sure you have set "[ControlPort] config=~/.gnuradio/thrift.conf"
> so it gets picked up.)
>
> I'm wondering if it's just blocking on all endpoints in a single thread
> right now before allowing any of them to return.
>
> Tom
>
>
Tom,
I tried the config changes for the toy flowgraph I described above (and for
my bursty flowgraph), but I did not notice a difference in behavior.  I
have a high level of confidence that the config changes were getting sucked
in because the thrift server would change ports when I altered the port
number in thrift.conf.

Also, this issue seems specific to ctrlport_probe2_x.  gr-ctrlport-monitor
initializes fine and is responsive to user input as expected even without
data flowing if I try the toy flowgraph above with the older
ctrlport_probe_c block instead:  random_pdu -> pdu_to_tagged_stream ->
ctrlport_probe_c

On a side note, I re-built from git master today before I tried the config
changes and played with ctrlport_probe_c:

$ gnuradio-config-info -v
3.7.9git-88-g8e19986c
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the absence of samples

[Tom Rondeau]

On Thu, Sep 3, 2015 at 7:17 AM, Eric Statzer  wrote:

> I'm attempting to use ctrlport_probe2_x and gr-ctrlport-monitor to probe
> points in a bursty flowgraph.  When I place a ctrlport_probe2_x probe
> somewhere in the part of my flowgraph that process samples only upon
> reception of a burst, gr-ctrlport-monitor doesn't fully initialize
> (populate its list of controlport "knobs") until after all
> ctrlport_probe2_x blocks have performed at least one call to work().
> Furthermore, the gr-ctrlport-monitor GUI is only responsive to user input
> if all ctrlport_probe2_x blocks in the flowgraph are regularly making calls
> to work() (i.e. gr-ctrlport-monitor query latency becomes equal to the time
> that elapses between processing individual bursts), so if for some reason
> bursts ever stop trickling to one of the probes, gr-ctrlport-monitor
> becomes unresponsive to user input.
>
> The gr-ctrlport-monitor behavior can be recreated with any simple
> flowgraph that contains a ctrlport_probe2_x that will never (or
> infrequently) make a call to work, such as: random_pdu ->
> pdu_to_tagged_stream -> ctrlport_probe2_b, where the "generate" port of the
> random_pdu block is left unconnected.  Attempting to connect
> gr-ctrlport-monitor to this flowgraph will cause gr-ctrlport-monitor to be
> unresponsive (have to kill it) almost immediately after the GUI is
> displayed.
>
> I wasn't sure if this is a limitation of ctrlport_probe2_x or
> gr-ctrlport-monitor, but I wanted to see if t was was possible to make the
> combination play nicely together when applied to a bursty flowgraph.
>
> Relevant system info:
>   GNU Radio 3.7.8
>   Thrift 0.9.2
>   Ubuntu 15.04
>
> Thanks in advance,
> Eric
>

Eric,

Have you tried increasing the number of threads in the thrift server? Try
making/modifying ~/.gnuradio/thrift.conf with:

[thrift]
nthreads = 10 (or some number greater than the number of probe blocks you
have)

(and make sure you have set "[ControlPort] config=~/.gnuradio/thrift.conf"
so it gets picked up.)

I'm wondering if it's just blocking on all endpoints in a single thread
right now before allowing any of them to return.

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

[Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the absence of samples

[Eric Statzer]

I'm attempting to use ctrlport_probe2_x and gr-ctrlport-monitor to probe
points in a bursty flowgraph.  When I place a ctrlport_probe2_x probe
somewhere in the part of my flowgraph that process samples only upon
reception of a burst, gr-ctrlport-monitor doesn't fully initialize
(populate its list of controlport "knobs") until after all
ctrlport_probe2_x blocks have performed at least one call to work().
Furthermore, the gr-ctrlport-monitor GUI is only responsive to user input
if all ctrlport_probe2_x blocks in the flowgraph are regularly making calls
to work() (i.e. gr-ctrlport-monitor query latency becomes equal to the time
that elapses between processing individual bursts), so if for some reason
bursts ever stop trickling to one of the probes, gr-ctrlport-monitor
becomes unresponsive to user input.

The gr-ctrlport-monitor behavior can be recreated with any simple flowgraph
that contains a ctrlport_probe2_x that will never (or infrequently) make a
call to work, such as: random_pdu -> pdu_to_tagged_stream ->
ctrlport_probe2_b, where the "generate" port of the random_pdu block is
left unconnected.  Attempting to connect gr-ctrlport-monitor to this
flowgraph will cause gr-ctrlport-monitor to be unresponsive (have to kill
it) almost immediately after the GUI is displayed.

I wasn't sure if this is a limitation of ctrlport_probe2_x or
gr-ctrlport-monitor, but I wanted to see if t was was possible to make the
combination play nicely together when applied to a bursty flowgraph.

Relevant system info:
  GNU Radio 3.7.8
  Thrift 0.9.2
  Ubuntu 15.04

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