Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-11-05 Thread Andy Walls 
On Sun, 2016-04-03 at 13:01 -0400, Andy Walls wrote:
> >On April 3, 2016 11:31:02 AM EDT, Tom Rondeau wrote:
> >>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik wrote:

[snip]

>  Here is some good info on how GRNURadio's control port works at a
> >>high
>  level:
>  https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
> 
> >>
>  https://gnuradio.org/doc/doxygen/page_ctrlport.html
> 
> >>
> 
>  From that second page, it appears that running two flowgraphs on
> >the
>  same machine has a problem caused by Apache Thrift and GNURadio's
>  configuration of the Control Port network port (default of 9090).
> 
> >>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
> 
> >>
> 
>  So please only run on flowgraph at a time, at first, to
> >troubleshoot
>  this issue.
> 
>  Second, you may want to try setting the GR_CONF_THRIFT_PORT
> >>environment
>  variable to something other than 9090, a port that you know is open
> >>on
>  your machine, for each separate flowgraph that you run.
> 
>  FYI, the modulate_vector block runs a "mini"-flowgraph, before the
> >>main
>  flowgraph actually runs:
> 
> 
> 
> >>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
> 
> >>
> 
>  Hopefully, there isn't some sort of weird race condition with the
> >>Thrift
>  port being open for the modulate_vector block's mini-flowgraph and
> >>the
>  main flowgraph.
> 
> 
>  Hi Tom,
> 
>  Do you have any comments or insights on Arik's Thrift error message
>  and/or the possibility of modulate_vector's mini-flowgraph causing
>  problems with Thrift's network port and the main flowgraph?
> 
>  Regards,
>  Andy
> 
> >>>
> >>> Andy,
> >>>
> >>> I think you've got it on the Thrift issue. However, running the
> >>modulate
> >>> vector mini flowgraph first should kill itself immediately and free
> >>up the
> >>> port, so I don't think that's the problem. On the other hand, I've
> >>been
> >>> seeing issues recently where every time I launch GRC, it seems to
> >>cause a
> >>> conflict with whatever port I'm setting. Almost as though GRC is
> >>launching
> >>> something and holding on to the port specified in the thrift.conf
> >>file. I
> >>> thought this could just be a problem on my laptop (I've been
> >>traveling a
> >>> lot -- more than usual even -- and developing on my laptop can lead
> >>to me
> >>> doing a lot of crazy things), but I think I've since seen it on my
> >>office
> >>> workstation as well. That could be a problem here, too. We'll have
> >to
> >>track
> >>> that down.
> >>>
> >>> Using the GR_CONF_THRIFT_PORT variable is a good idea to set the
> >port
> >>per
> >>> flowgraph you're running. Another option is to set the port to 0 in
> >>> thrift.conf, which will cause Thrift to open an ephemeral port for
> >>each
> >>> server is creates. You'll just have to pay attention to the message
> >>output
> >>> that announces the ControlPort endpoint to find out what port it's
> >>running
> >>> on.
> >>>
> >>> Tom

OK, some I'm getting this runtime error at flowgraph startup
consistently:

"rpcmanager: Aggregator not in use, and a rpc booter is already registered"

strace shows that when the assetion stops the program, some block
threads have been spawned, but they are all waiting.  It's the main
program thread which emits this.

Running the flowgraph in gdb, and checking some of the relevant
variables in the stack frame:

(gdb) frame 6
#6  0x7fffeacc3376 in rpcmanager::register_booter (booter=)
at 
/home/andy/work/pybombs/src/gnuradio/gnuradio-runtime/lib/controlport/rpcmanager.cc:66
66  throw std::runtime_error("rpcmanager: Aggregator not in use, and a 
rpc booter is already registered\n");
(gdb) info locals
No locals.
(gdb) print rpcmanager::booter_registered
$1 = true
(gdb) print rpcmanager::aggregator_registered
$2 = false
(gdb) print rpcmanager::make_aggregator
$3 = false
(gdb)  print rpcmanager::aggregator
$4 = {_M_ptr = 0x0}
(gdb) print rpcmanager::boot
$5 = {_M_ptr = 0x0}


So two things strike me as a problem here:
1. booter_registered == true, but rpcmanager::boot == NULL
2. make_aggregator == false, and nowhere in

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
fair enough :)

From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, April 03, 2016 1:01 PM
To: Landsman, Arik; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

Well, on that machine (Fedora 20) I never built thrift.  No problem. ;)

On April 3, 2016 12:51:31 PM EDT, "Landsman, Arik"  
wrote:
>setting port=0 in thrift.conf did the trick, GRC now runs all
>flowgraphs as expected.
>
>Andy, still at odds on how you got yours to work.. did you modify
>thrift.conf in any way?
>
>From: Andy Walls [a...@silverblocksystems.net]
>Sent: Sunday, April 03, 2016 11:36 AM
>To: Tom Rondeau; Landsman, Arik
>Cc: discuss-gnuradio@gnu.org
>Subject: Re: Debugging ControlPort/Thrift problem (Re:
>[Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>qpsk)
>
>Hmm.  Maybe GRC trying to evaluate the block for the sake of values in
>other blocks is spawning and keeping the mini flowgraph open.
>
>Weird.
>
>On April 3, 2016 11:31:02 AM EDT, Tom Rondeau  wrote:
>>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik
>>
>>wrote:
>>
>>> Hi Tom,
>>>
>>> Where is thrift.conf usually located?..
>>>
>>> Thanks,
>>> Arik
>>>
>>
>>
>>In ~/.gnuradio/thrift.conf
>>
>>
>>And interesting observation about having to remove Modulate Vector
>>completely. That might be the same problem I'm experiencing. Strange
>it
>>should matter just by being there.
>>
>>Tom
>>
>>
>>
>>> --
>>> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of
>>Tom
>>> Rondeau [t...@trondeau.com]
>>> *Sent:* Sunday, April 03, 2016 11:22 AM
>>> *To:* Andy Walls
>>> *Cc:* Landsman, Arik; discuss-gnuradio@gnu.org
>>> *Subject:* Re: Debugging ControlPort/Thrift problem (Re:
>>> [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>>qpsk)
>>>
>>> On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls

>>
>>> > wrote:
>>>

 > Otherwise, you didn't drop a control port related block on the
 > flowgraph did you?


 Here is some good info on how GRNURadio's control port works at a
>>high
 level:
 https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort

>>
 https://gnuradio.org/doc/doxygen/page_ctrlport.html

>>

 From that second page, it appears that running two flowgraphs on
>the
 same machine has a problem caused by Apache Thrift and GNURadio's
 configuration of the Control Port network port (default of 9090).

>>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

>>

 So please only run on flowgraph at a time, at first, to
>troubleshoot
 this issue.

 Second, you may want to try setting the GR_CONF_THRIFT_PORT
>>environment
 variable to something other than 9090, a port that you know is open
>>on
 your machine, for each separate flowgraph that you run.

 FYI, the modulate_vector block runs a "mini"-flowgraph, before the
>>main
 flowgraph actually runs:



>>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

>>

 Hopefully, there isn't some sort of weird race condition with the
>>Thrift
 port being open for the modulate_vector block's mini-flowgraph and
>>the
 main flowgraph.


 Hi Tom,

 Do you have any comments or insights on Arik's Thrift error message
 and/or the possibility of modulate_vector's mini-flowgraph causing
 problems with Thrift's network port and the main flowgraph?

 Regards,
 Andy

>>>
>>> Andy,
>>>
>>> I think you've got it on the Thrift issue. However, running the
>>modulate
>>> vector mini flowgraph first should kill itself immediately and free
>>up the
>>> port, so I don't think that's the problem. On the other hand, I've
>>been
>>> seeing issues recently where every time I launch GRC, it seems to
>>cause a
>>> conflict with whatever port I'm setting. Almost as though GRC is
>>launching
>>> something and holding on to the port specified in the thrift.co

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Andy Walls 
Well, on that machine (Fedora 20) I never built thrift.  No problem. ;)

On April 3, 2016 12:51:31 PM EDT, "Landsman, Arik"  
wrote:
>setting port=0 in thrift.conf did the trick, GRC now runs all
>flowgraphs as expected. 
>
>Andy, still at odds on how you got yours to work.. did you modify
>thrift.conf in any way? 
>
>From: Andy Walls [a...@silverblocksystems.net]
>Sent: Sunday, April 03, 2016 11:36 AM
>To: Tom Rondeau; Landsman, Arik
>Cc: discuss-gnuradio@gnu.org
>Subject: Re: Debugging ControlPort/Thrift problem (Re:
>[Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>qpsk)
>
>Hmm.  Maybe GRC trying to evaluate the block for the sake of values in
>other blocks is spawning and keeping the mini flowgraph open.
>
>Weird.
>
>On April 3, 2016 11:31:02 AM EDT, Tom Rondeau  wrote:
>>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik
>>
>>wrote:
>>
>>> Hi Tom,
>>>
>>> Where is thrift.conf usually located?..
>>>
>>> Thanks,
>>> Arik
>>>
>>
>>
>>In ~/.gnuradio/thrift.conf
>>
>>
>>And interesting observation about having to remove Modulate Vector
>>completely. That might be the same problem I'm experiencing. Strange
>it
>>should matter just by being there.
>>
>>Tom
>>
>>
>>
>>> --
>>> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of
>>Tom
>>> Rondeau [t...@trondeau.com]
>>> *Sent:* Sunday, April 03, 2016 11:22 AM
>>> *To:* Andy Walls
>>> *Cc:* Landsman, Arik; discuss-gnuradio@gnu.org
>>> *Subject:* Re: Debugging ControlPort/Thrift problem (Re:
>>> [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>>qpsk)
>>>
>>> On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls

>>
>>> > wrote:
>>>

 > Otherwise, you didn't drop a control port related block on the
 > flowgraph did you?


 Here is some good info on how GRNURadio's control port works at a
>>high
 level:
 https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort

>>
 https://gnuradio.org/doc/doxygen/page_ctrlport.html

>>

 From that second page, it appears that running two flowgraphs on
>the
 same machine has a problem caused by Apache Thrift and GNURadio's
 configuration of the Control Port network port (default of 9090).

>>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

>>

 So please only run on flowgraph at a time, at first, to
>troubleshoot
 this issue.

 Second, you may want to try setting the GR_CONF_THRIFT_PORT
>>environment
 variable to something other than 9090, a port that you know is open
>>on
 your machine, for each separate flowgraph that you run.

 FYI, the modulate_vector block runs a "mini"-flowgraph, before the
>>main
 flowgraph actually runs:



>>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

>>

 Hopefully, there isn't some sort of weird race condition with the
>>Thrift
 port being open for the modulate_vector block's mini-flowgraph and
>>the
 main flowgraph.


 Hi Tom,

 Do you have any comments or insights on Arik's Thrift error message
 and/or the possibility of modulate_vector's mini-flowgraph causing
 problems with Thrift's network port and the main flowgraph?

 Regards,
 Andy

>>>
>>> Andy,
>>>
>>> I think you've got it on the Thrift issue. However, running the
>>modulate
>>> vector mini flowgraph first should kill itself immediately and free
>>up the
>>> port, so I don't think that's the problem. On the other hand, I've
>>been
>>> seeing issues recently where every time I launch GRC, it seems to
>>cause a
>>> conflict with whatever port I'm setting. Almost as though GRC is
>>launching
>>> something and holding on to the port specified in the thrift.conf
>>file. I
>>> thought this could just be a problem on my laptop (I've been
>>traveling a
>>> lot -- more than usual even -- and developing on my laptop can lead
>>to me
>>> doing a lot of crazy things), but I think I've since seen it on my
>>office
>>> workstation as well. That could be a problem here, too. We'll have
>to
>>t

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
setting port=0 in thrift.conf did the trick, GRC now runs all flowgraphs as 
expected. 

Andy, still at odds on how you got yours to work.. did you modify thrift.conf 
in any way? 

From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, April 03, 2016 11:36 AM
To: Tom Rondeau; Landsman, Arik
Cc: discuss-gnuradio@gnu.org
Subject: Re: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

Hmm.  Maybe GRC trying to evaluate the block for the sake of values in other 
blocks is spawning and keeping the mini flowgraph open.

Weird.

On April 3, 2016 11:31:02 AM EDT, Tom Rondeau  wrote:
>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik
>
>wrote:
>
>> Hi Tom,
>>
>> Where is thrift.conf usually located?..
>>
>> Thanks,
>> Arik
>>
>
>
>In ~/.gnuradio/thrift.conf
>
>
>And interesting observation about having to remove Modulate Vector
>completely. That might be the same problem I'm experiencing. Strange it
>should matter just by being there.
>
>Tom
>
>
>
>> --
>> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of
>Tom
>> Rondeau [t...@trondeau.com]
>> *Sent:* Sunday, April 03, 2016 11:22 AM
>> *To:* Andy Walls
>> *Cc:* Landsman, Arik; discuss-gnuradio@gnu.org
>> *Subject:* Re: Debugging ControlPort/Thrift problem (Re:
>> [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>qpsk)
>>
>> On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls
>>
>
>> > wrote:
>>
>>>
>>> > Otherwise, you didn't drop a control port related block on the
>>> > flowgraph did you?
>>>
>>>
>>> Here is some good info on how GRNURadio's control port works at a
>high
>>> level:
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>
>
>>> https://gnuradio.org/doc/doxygen/page_ctrlport.html
>>>
>
>>>
>>> From that second page, it appears that running two flowgraphs on the
>>> same machine has a problem caused by Apache Thrift and GNURadio's
>>> configuration of the Control Port network port (default of 9090).
>>>
>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
>>>
>
>>>
>>> So please only run on flowgraph at a time, at first, to troubleshoot
>>> this issue.
>>>
>>> Second, you may want to try setting the GR_CONF_THRIFT_PORT
>environment
>>> variable to something other than 9090, a port that you know is open
>on
>>> your machine, for each separate flowgraph that you run.
>>>
>>> FYI, the modulate_vector block runs a "mini"-flowgraph, before the
>main
>>> flowgraph actually runs:
>>>
>>>
>>>
>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
>>>
>
>>>
>>> Hopefully, there isn't some sort of weird race condition with the
>Thrift
>>> port being open for the modulate_vector block's mini-flowgraph and
>the
>>> main flowgraph.
>>>
>>>
>>> Hi Tom,
>>>
>>> Do you have any comments or insights on Arik's Thrift error message
>>> and/or the possibility of modulate_vector's mini-flowgraph causing
>>> problems with Thrift's network port and the main flowgraph?
>>>
>>> Regards,
>>> Andy
>>>
>>
>> Andy,
>>
>> I think you've got it on the Thrift issue. However, running the
>modulate
>> vector mini flowgraph first should kill itself immediately and free
>up the
>> port, so I don't think that's the problem. On the other hand, I've
>been
>> seeing issues recently where every time I launch GRC, it seems to
>cause a
>> conflict with whatever port I'm setting. Almost as though GRC is
>launching
>> something and holding on to the port specified in the thrift.conf
>file. I
>> thought this could just be a problem on my laptop (I've been
>traveling a
>> lot -- more than usual even -- and developing on my laptop can lead
>to me
>> doing a lot of crazy things), but I think I've since seen it on my
>office
>> workstation as well. That could be a problem here, too. We'll have to
>track
>> that down.
>>
>> Using the GR_CONF_THRIFT_PORT variable is a good idea to set the port
>per
>> flowgraph you're running. Another option is to set the port to 0 in
>> thrift.conf, which will cause Thrift to open an ephemeral port for
>each
>> server is creates. You'll

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Andy Walls 
Hmm.  Maybe GRC trying to evaluate the block for the sake of values in other 
blocks is spawning and keeping the mini flowgraph open.

Weird.

On April 3, 2016 11:31:02 AM EDT, Tom Rondeau  wrote:
>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik
>
>wrote:
>
>> Hi Tom,
>>
>> Where is thrift.conf usually located?..
>>
>> Thanks,
>> Arik
>>
>
>
>In ~/.gnuradio/thrift.conf
>
>
>And interesting observation about having to remove Modulate Vector
>completely. That might be the same problem I'm experiencing. Strange it
>should matter just by being there.
>
>Tom
>
>
>
>> --
>> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of
>Tom
>> Rondeau [t...@trondeau.com]
>> *Sent:* Sunday, April 03, 2016 11:22 AM
>> *To:* Andy Walls
>> *Cc:* Landsman, Arik; discuss-gnuradio@gnu.org
>> *Subject:* Re: Debugging ControlPort/Thrift problem (Re:
>> [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
>qpsk)
>>
>> On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls
>>
>
>> > wrote:
>>
>>>
>>> > Otherwise, you didn't drop a control port related block on the
>>> > flowgraph did you?
>>>
>>>
>>> Here is some good info on how GRNURadio's control port works at a
>high
>>> level:
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>
>
>>> https://gnuradio.org/doc/doxygen/page_ctrlport.html
>>>
>
>>>
>>> From that second page, it appears that running two flowgraphs on the
>>> same machine has a problem caused by Apache Thrift and GNURadio's
>>> configuration of the Control Port network port (default of 9090).
>>>
>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
>>>
>
>>>
>>> So please only run on flowgraph at a time, at first, to troubleshoot
>>> this issue.
>>>
>>> Second, you may want to try setting the GR_CONF_THRIFT_PORT
>environment
>>> variable to something other than 9090, a port that you know is open
>on
>>> your machine, for each separate flowgraph that you run.
>>>
>>> FYI, the modulate_vector block runs a "mini"-flowgraph, before the
>main
>>> flowgraph actually runs:
>>>
>>>
>>>
>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
>>>
>
>>>
>>> Hopefully, there isn't some sort of weird race condition with the
>Thrift
>>> port being open for the modulate_vector block's mini-flowgraph and
>the
>>> main flowgraph.
>>>
>>>
>>> Hi Tom,
>>>
>>> Do you have any comments or insights on Arik's Thrift error message
>>> and/or the possibility of modulate_vector's mini-flowgraph causing
>>> problems with Thrift's network port and the main flowgraph?
>>>
>>> Regards,
>>> Andy
>>>
>>
>> Andy,
>>
>> I think you've got it on the Thrift issue. However, running the
>modulate
>> vector mini flowgraph first should kill itself immediately and free
>up the
>> port, so I don't think that's the problem. On the other hand, I've
>been
>> seeing issues recently where every time I launch GRC, it seems to
>cause a
>> conflict with whatever port I'm setting. Almost as though GRC is
>launching
>> something and holding on to the port specified in the thrift.conf
>file. I
>> thought this could just be a problem on my laptop (I've been
>traveling a
>> lot -- more than usual even -- and developing on my laptop can lead
>to me
>> doing a lot of crazy things), but I think I've since seen it on my
>office
>> workstation as well. That could be a problem here, too. We'll have to
>track
>> that down.
>>
>> Using the GR_CONF_THRIFT_PORT variable is a good idea to set the port
>per
>> flowgraph you're running. Another option is to set the port to 0 in
>> thrift.conf, which will cause Thrift to open an ephemeral port for
>each
>> server is creates. You'll just have to pay attention to the message
>output
>> that announces the ControlPort endpoint to find out what port it's
>running
>> on.
>>
>> Tom
>>
>>


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

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Tom Rondeau 
On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik 
wrote:

> Hi Tom,
>
> Where is thrift.conf usually located?..
>
> Thanks,
> Arik
>


In ~/.gnuradio/thrift.conf


And interesting observation about having to remove Modulate Vector
completely. That might be the same problem I'm experiencing. Strange it
should matter just by being there.

Tom



> --
> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom
> Rondeau [t...@trondeau.com]
> *Sent:* Sunday, April 03, 2016 11:22 AM
> *To:* Andy Walls
> *Cc:* Landsman, Arik; discuss-gnuradio@gnu.org
> *Subject:* Re: Debugging ControlPort/Thrift problem (Re:
> [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk)
>
> On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls  
> > wrote:
>
>>
>> > Otherwise, you didn't drop a control port related block on the
>> > flowgraph did you?
>>
>>
>> Here is some good info on how GRNURadio's control port works at a high
>> level:
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>> 
>> https://gnuradio.org/doc/doxygen/page_ctrlport.html
>> 
>>
>> From that second page, it appears that running two flowgraphs on the
>> same machine has a problem caused by Apache Thrift and GNURadio's
>> configuration of the Control Port network port (default of 9090).
>> https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
>> 
>>
>> So please only run on flowgraph at a time, at first, to troubleshoot
>> this issue.
>>
>> Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
>> variable to something other than 9090, a port that you know is open on
>> your machine, for each separate flowgraph that you run.
>>
>> FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
>> flowgraph actually runs:
>>
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
>> 
>>
>> Hopefully, there isn't some sort of weird race condition with the Thrift
>> port being open for the modulate_vector block's mini-flowgraph and the
>> main flowgraph.
>>
>>
>> Hi Tom,
>>
>> Do you have any comments or insights on Arik's Thrift error message
>> and/or the possibility of modulate_vector's mini-flowgraph causing
>> problems with Thrift's network port and the main flowgraph?
>>
>> Regards,
>> Andy
>>
>
> Andy,
>
> I think you've got it on the Thrift issue. However, running the modulate
> vector mini flowgraph first should kill itself immediately and free up the
> port, so I don't think that's the problem. On the other hand, I've been
> seeing issues recently where every time I launch GRC, it seems to cause a
> conflict with whatever port I'm setting. Almost as though GRC is launching
> something and holding on to the port specified in the thrift.conf file. I
> thought this could just be a problem on my laptop (I've been traveling a
> lot -- more than usual even -- and developing on my laptop can lead to me
> doing a lot of crazy things), but I think I've since seen it on my office
> workstation as well. That could be a problem here, too. We'll have to track
> that down.
>
> Using the GR_CONF_THRIFT_PORT variable is a good idea to set the port per
> flowgraph you're running. Another option is to set the port to 0 in
> thrift.conf, which will cause Thrift to open an ephemeral port for each
> server is creates. You'll just have to pay attention to the message output
> that announces the ControlPort endpoint to find out what port it's running
> on.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
Hi Tom,

Where is thrift.conf usually located?..

Thanks,
Arik


From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau 
[t...@trondeau.com]
Sent: Sunday, April 03, 2016 11:22 AM
To: Andy Walls
Cc: Landsman, Arik; discuss-gnuradio@gnu.org
Subject: Re: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls 
>
 wrote:

> Otherwise, you didn't drop a control port related block on the
> flowgraph did you?


Here is some good info on how GRNURadio's control port works at a high
level:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
https://gnuradio.org/doc/doxygen/page_ctrlport.html

>From that second page, it appears that running two flowgraphs on the
same machine has a problem caused by Apache Thrift and GNURadio's
configuration of the Control Port network port (default of 9090).
https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

So please only run on flowgraph at a time, at first, to troubleshoot
this issue.

Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
variable to something other than 9090, a port that you know is open on
your machine, for each separate flowgraph that you run.

FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
flowgraph actually runs:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

Hopefully, there isn't some sort of weird race condition with the Thrift
port being open for the modulate_vector block's mini-flowgraph and the
main flowgraph.


Hi Tom,

Do you have any comments or insights on Arik's Thrift error message
and/or the possibility of modulate_vector's mini-flowgraph causing
problems with Thrift's network port and the main flowgraph?

Regards,
Andy

Andy,

I think you've got it on the Thrift issue. However, running the modulate vector 
mini flowgraph first should kill itself immediately and free up the port, so I 
don't think that's the problem. On the other hand, I've been seeing issues 
recently where every time I launch GRC, it seems to cause a conflict with 
whatever port I'm setting. Almost as though GRC is launching something and 
holding on to the port specified in the thrift.conf file. I thought this could 
just be a problem on my laptop (I've been traveling a lot -- more than usual 
even -- and developing on my laptop can lead to me doing a lot of crazy 
things), but I think I've since seen it on my office workstation as well. That 
could be a problem here, too. We'll have to track that down.

Using the GR_CONF_THRIFT_PORT variable is a good idea to set the port per 
flowgraph you're running. Another option is to set the port to 0 in 
thrift.conf, which will cause Thrift to open an ephemeral port for each server 
is creates. You'll just have to pay attention to the message output that 
announces the ControlPort endpoint to find out what port it's running on.

Tom

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

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Tom Rondeau 
On Sun, Apr 3, 2016 at 8:49 AM, Andy Walls 
wrote:

>
> > Otherwise, you didn't drop a control port related block on the
> > flowgraph did you?
>
>
> Here is some good info on how GRNURadio's control port works at a high
> level:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
> https://gnuradio.org/doc/doxygen/page_ctrlport.html
>
> From that second page, it appears that running two flowgraphs on the
> same machine has a problem caused by Apache Thrift and GNURadio's
> configuration of the Control Port network port (default of 9090).
> https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
>
> So please only run on flowgraph at a time, at first, to troubleshoot
> this issue.
>
> Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
> variable to something other than 9090, a port that you know is open on
> your machine, for each separate flowgraph that you run.
>
> FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
> flowgraph actually runs:
>
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
>
> Hopefully, there isn't some sort of weird race condition with the Thrift
> port being open for the modulate_vector block's mini-flowgraph and the
> main flowgraph.
>
>
> Hi Tom,
>
> Do you have any comments or insights on Arik's Thrift error message
> and/or the possibility of modulate_vector's mini-flowgraph causing
> problems with Thrift's network port and the main flowgraph?
>
> Regards,
> Andy
>

Andy,

I think you've got it on the Thrift issue. However, running the modulate
vector mini flowgraph first should kill itself immediately and free up the
port, so I don't think that's the problem. On the other hand, I've been
seeing issues recently where every time I launch GRC, it seems to cause a
conflict with whatever port I'm setting. Almost as though GRC is launching
something and holding on to the port specified in the thrift.conf file. I
thought this could just be a problem on my laptop (I've been traveling a
lot -- more than usual even -- and developing on my laptop can lead to me
doing a lot of crazy things), but I think I've since seen it on my office
workstation as well. That could be a problem here, too. We'll have to track
that down.

Using the GR_CONF_THRIFT_PORT variable is a good idea to set the port per
flowgraph you're running. Another option is to set the port to 0 in
thrift.conf, which will cause Thrift to open an ephemeral port for each
server is creates. You'll just have to pay attention to the message output
that announces the ControlPort endpoint to find out what port it's running
on.

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

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
Hi Andy, 

So the issue is with the modulate vector block like you suggested. Disabling it 
alone is not enough, had to be removed altogether and GRC restarted. Only then 
the flowgraph runs ok. 

how did you menage to run it on your setup?.. different Thrift config? To this 
end, how would I go about setting "GR_CONF_THRIFT_PORT" to have a separate port 
for modulate_vector?  Even having that block on a *blank* flowgraph returns the 
error. 

if this is a no go, I was going to try modulating a vector manually in a 
separate flowgraph (without modulate_vector), storing as txt, and later reading 
the content into corr_est in the main flowgraph. 

Best Regards,
Arik 

From: Landsman, Arik
Sent: Sunday, April 03, 2016 10:15 AM
To: Andy Walls; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

error still there in Rx_syncd_3.grc.

Feels like a version or dependencies issue on the GRC side..

With the .py running, going to use Rx_syncd_2.grc for now as a reference  to 
copy essential blocks to a working (earlier) version of Rx_syncd.grc. if this 
works I'll continue off of the other thread to keep the two topics somewhat 
separate. certainly will have a question or two on how you fine-tuned the 
modulated symbols to corr against.  going to try the "octave method" next..

also will try disabling the added blocks.




From: Landsman, Arik
Sent: Sunday, April 03, 2016 9:47 AM
To: Andy Walls; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

Hi Andy,

Looks like the issue is connected to the .grc like you mentioned - without 
opening Rx_syncd_2.grc, the Rx_syncd.py you attached earlier runs fine.

Just opening the Rx_syncd_2.grc, w/o ever running or generating a new .py, 
while attempting to run any other .grc gives the same error.

So I suppose with the .py running ok a race condition with modulate_vector is 
unlikely.. do our GRC's match version? I have 3.7.9.

not sure how to check the Apache Thrift version, but it was running ok so far.

worth noting that I did have to get the .grc off of the gnuradio-list archives 
as a .bin (original was blocked by the tufts mail server for some reason). Just 
in case anything besides the name could change once archived.

But let me try Rx_syncd_3.grc

Thanks,
Arik



From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, April 03, 2016 8:49 AM
To: Landsman, Arik; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] costas 
ambiguity and correlate-and-sync block in qpsk)

Hi Arik:

First off, try the attached Rx_syncd_3.grc.  I disabled the modulate
vector block and hard-coded in a vector of 150 preamble samples.

On Sat, 2016-04-02 at 20:11 -0400, Andy Walls wrote:
> Hi Arik:
>
> On Sat, Apr 2, 2016 at 7:41 PM, Landsman, Arik
>  wrote:
> Hi Andy,
>
> Still looking it over, but one thing jumps out right away -
> for some reason I couldn't execute either Rx_syncd_2.grc or
> the Rx_syncd.py. getting the same error in both cases:
>
> ""
> Generating:
> '/home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Executing: '/usr/bin/python2Andy, certainly will have a question or 
> two on how you fine-tuned the modulated symbols to corr against.
> -u /home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Using Volk machine: sse4_1_64
> Thrift: Sat Apr  2 19:05:54 2016 TServerSocket::listen() BIND
> 9090
> terminate called after throwing an instance of
> 'apache::thrift::transport::TTransportException'
>   what():  Could not bind: Transport endpoint is not connected
> ""
>
> does this look familiar by any chance?
>do our GRC's match versions? I have 3.7.9.
>
> It looks like a GNURadio ControlPort / Apache Thrift error.
>
>
> I took your flowgraph and modified it slightly, only adding a few
> blocks:
>
> -modulate_vector
> -skip_headmodulate_vector
> -keep_1_in_n
> -qt_time_sink
> -feedforward_agc
> -multiply const
> -qt gui range
>
> One of those might be doing it.  Disable skip_head, keep_1_in_n, and
> the constellation sink they connect to.  Hopefully it's one of them.
>
> Otherwise, you didn't drop a control port related block on the
> flowgraph did you?


Here is some good info on how GRNURadio's control port works at a high
level:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
https://gnuradio.org/doc/doxygen/page_ctrlport.html

>From that second page, it appears that running two flowgraphs on the
same machine has a problem caused by Apache Thrift and GNURadio's
configuration of the Co

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
error still there in Rx_syncd_3.grc. 

Feels like a version or dependencies issue on the GRC side.. 

With the .py running, going to use Rx_syncd_2.grc for now as a reference  to 
copy essential blocks to a working (earlier) version of Rx_syncd.grc. if this 
works I'll continue off of the other thread to keep the two topics somewhat 
separate. certainly will have a question or two on how you fine-tuned the 
modulated symbols to corr against.  going to try the "octave method" next..  

also will try disabling the added blocks. 




From: Landsman, Arik
Sent: Sunday, April 03, 2016 9:47 AM
To: Andy Walls; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: RE: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] 
costas ambiguity and correlate-and-sync block in qpsk)

Hi Andy,

Looks like the issue is connected to the .grc like you mentioned - without 
opening Rx_syncd_2.grc, the Rx_syncd.py you attached earlier runs fine.

Just opening the Rx_syncd_2.grc, w/o ever running or generating a new .py, 
while attempting to run any other .grc gives the same error.

So I suppose with the .py running ok a race condition with modulate_vector is 
unlikely.. do our GRC's match version? I have 3.7.9.

not sure how to check the Apache Thrift version, but it was running ok so far.

worth noting that I did have to get the .grc off of the gnuradio-list archives 
as a .bin (original was blocked by the tufts mail server for some reason). Just 
in case anything besides the name could change once archived.

But let me try Rx_syncd_3.grc

Thanks,
Arik



From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, April 03, 2016 8:49 AM
To: Landsman, Arik; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] costas 
ambiguity and correlate-and-sync block in qpsk)

Hi Arik:

First off, try the attached Rx_syncd_3.grc.  I disabled the modulate
vector block and hard-coded in a vector of 150 preamble samples.

On Sat, 2016-04-02 at 20:11 -0400, Andy Walls wrote:
> Hi Arik:
>
> On Sat, Apr 2, 2016 at 7:41 PM, Landsman, Arik
>  wrote:
> Hi Andy,
>
> Still looking it over, but one thing jumps out right away -
> for some reason I couldn't execute either Rx_syncd_2.grc or
> the Rx_syncd.py. getting the same error in both cases:
>
> ""
> Generating:
> '/home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Executing: '/usr/bin/python2Andy, certainly will have a question or 
> two on how you fine-tuned the modulated symbols to corr against.  
> -u /home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Using Volk machine: sse4_1_64
> Thrift: Sat Apr  2 19:05:54 2016 TServerSocket::listen() BIND
> 9090
> terminate called after throwing an instance of
> 'apache::thrift::transport::TTransportException'
>   what():  Could not bind: Transport endpoint is not connected
> ""
>
> does this look familiar by any chance?
>do our GRC's match versions? I have 3.7.9.
>
> It looks like a GNURadio ControlPort / Apache Thrift error.
>
>
> I took your flowgraph and modified it slightly, only adding a few
> blocks:
>
> -modulate_vector
> -skip_headmodulate_vector
> -keep_1_in_n
> -qt_time_sink
> -feedforward_agc
> -multiply const
> -qt gui range
>
> One of those might be doing it.  Disable skip_head, keep_1_in_n, and
> the constellation sink they connect to.  Hopefully it's one of them.
>
> Otherwise, you didn't drop a control port related block on the
> flowgraph did you?


Here is some good info on how GRNURadio's control port works at a high
level:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
https://gnuradio.org/doc/doxygen/page_ctrlport.html

>From that second page, it appears that running two flowgraphs on the
same machine has a problem caused by Apache Thrift and GNURadio's
configuration of the Control Port network port (default of 9090).
https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

So please only run on flowgraph at a time, at first, to troubleshoot
this issue.

Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
variable to something other than 9090, a port that you know is open on
your machine, for each separate flowgraph that you run.

FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
flowgraph actually runs:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

Hopefully, there isn't some sort of weird race condition with the Thrift
port being open for the modulate_vector block's mini-flowgraph and the
main flowgraph.


Hi Tom,

Do you have any comments or insights on Arik's Thrift error message
and/or the possibility of modulate_vector's mini-flowgraph causing
problems with Thrift's network port and the main flowgraph?

R

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

2016-04-03 Thread Landsman, Arik 
Hi Andy, 

Looks like the issue is connected to the .grc like you mentioned - without 
opening Rx_syncd_2.grc, the Rx_syncd.py you attached earlier runs fine. 

Just opening the Rx_syncd_2.grc, w/o ever running or generating a new .py, 
while attempting to run any other .grc gives the same error. 

So I suppose with the .py running ok a race condition with modulate_vector is 
unlikely.. do our GRC's match version? I have 3.7.9.

not sure how to check the Apache Thrift version, but it was running ok so far. 

worth noting that I did have to get the .grc off of the gnuradio-list archives 
as a .bin (original was blocked by the tufts mail server for some reason). Just 
in case anything besides the name could change once archived. 

But let me try Rx_syncd_3.grc

Thanks,
Arik 

  

From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, April 03, 2016 8:49 AM
To: Landsman, Arik; Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Debugging ControlPort/Thrift problem (Re: [Discuss-gnuradio] costas 
ambiguity and correlate-and-sync block in qpsk)

Hi Arik:

First off, try the attached Rx_syncd_3.grc.  I disabled the modulate
vector block and hard-coded in a vector of 150 preamble samples.

On Sat, 2016-04-02 at 20:11 -0400, Andy Walls wrote:
> Hi Arik:
>
> On Sat, Apr 2, 2016 at 7:41 PM, Landsman, Arik
>  wrote:
> Hi Andy,
>
> Still looking it over, but one thing jumps out right away -
> for some reason I couldn't execute either Rx_syncd_2.grc or
> the Rx_syncd.py. getting the same error in both cases:
>
> ""
> Generating:
> '/home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Executing: '/usr/bin/python2
> -u /home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Using Volk machine: sse4_1_64
> Thrift: Sat Apr  2 19:05:54 2016 TServerSocket::listen() BIND
> 9090
> terminate called after throwing an instance of
> 'apache::thrift::transport::TTransportException'
>   what():  Could not bind: Transport endpoint is not connected
> ""
>
> does this look familiar by any chance?
>do our GRC's match versions? I have 3.7.9.
>
> It looks like a GNURadio ControlPort / Apache Thrift error.
>
>
> I took your flowgraph and modified it slightly, only adding a few
> blocks:
>
> -modulate_vector
> -skip_headmodulate_vector
> -keep_1_in_n
> -qt_time_sink
> -feedforward_agc
> -multiply const
> -qt gui range
>
> One of those might be doing it.  Disable skip_head, keep_1_in_n, and
> the constellation sink they connect to.  Hopefully it's one of them.
>
> Otherwise, you didn't drop a control port related block on the
> flowgraph did you?


Here is some good info on how GRNURadio's control port works at a high
level:
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
https://gnuradio.org/doc/doxygen/page_ctrlport.html

>From that second page, it appears that running two flowgraphs on the
same machine has a problem caused by Apache Thrift and GNURadio's
configuration of the Control Port network port (default of 9090).
https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues

So please only run on flowgraph at a time, at first, to troubleshoot
this issue.

Second, you may want to try setting the GR_CONF_THRIFT_PORT environment
variable to something other than 9090, a port that you know is open on
your machine, for each separate flowgraph that you run.

FYI, the modulate_vector block runs a "mini"-flowgraph, before the main
flowgraph actually runs:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59

Hopefully, there isn't some sort of weird race condition with the Thrift
port being open for the modulate_vector block's mini-flowgraph and the
main flowgraph.


Hi Tom,

Do you have any comments or insights on Arik's Thrift error message
and/or the possibility of modulate_vector's mini-flowgraph causing
problems with Thrift's network port and the main flowgraph?

Regards,
Andy

> Regards,
>
> Andy




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