Hi, I use the control port, or at least I'm trying to... But I can only use and see the performance counters, I can never see the graphical representation on the proves that I use, and that will be so useful for my dissertation thesis.
On Mon, 25 Mar 2019 at 08:44, Müller, Marcus (CEL) <[email protected]> wrote: > Hi Johannes! > > let me answer in-text real quick: > On Mon, 2019-03-25 at 10:13 +0000, Johannes Demel wrote: > > Hi Marcus, > > > > it seems like Thrift is a painful dependency. So, this is a pro > > ctrlport > > removal. Though, what else does ctrlport removal entail? > > Removal of Ctrlport and the tools dependent on it. > > > Is it really only used for monitoring and control? > > I'm only speaking for in-tree code, but yes. > Speaking for the whole ecosystem: I'm by now aware of 1 (one) external > project that uses CtrlPort. We're in contact. > > > Just for clarification, the zeromq blocks are not affected? > > Not affected. > > > How will the performance monitor be preserved? > > At this point, I have no clue. Suggestions welcome! > > > I really like to look at > > the statistics to get a first idea where to look for problems and > > analyze my system with it. > > That's a fair point. But to be honest, you don't really need an RPC > framework running in a separate process to query perfcounters, do you. > A very valid model would be having a tiny perfcounter-server (e.g. > behind a req/rep zeromq socket). It wouldn't be a general RPC > framework, but it could do ctrlport's job for this very limited scope! > > > > > Also, in case ctrlport is removed, we should have a GREP to discuss > > what > > we want and how we want ctrlport back in some other form. > > YESSSS! Want to (co)author that? > > Best regards, > Marcus > > > > > Cheers > > Johannes > > > > Am 24.03.19 um 20:26 schrieb Marcus Müller: > > > Dear GNU Radio community, > > > > > > we've got an outstanding breakage in our controlport > > > infrastructure. > > > Since fixing it seems to involve architectural changes to what > > > controlport does, and since making these changes would quite > > > possibly > > > break the semantics of using controlport anyway, we're considering > > > removing Controlport from the GNU Radio 3.8 release (this does NOT > > > apply to 3.7). > > > > > > The negative effect of that would obviously be that we'd lose > > > controlport (which I'm not going to introduce here; if you don't > > > know > > > what it is, you haven't been using it). We would *not* lose the > > > performance counters, just the default way of querying them. > > > > > > The most important upside would be the ability to remove the Apache > > > thrift dependency. Thrift has been the single worst thing we've > > > relied > > > on for as long as I can remember in terms of availability and > > > consistency across platforms. In fact, different distros build > > > completely different configurations of thrift, and noone seems to > > > be > > > able to build a "fully featured" thrift. > > > > > > Another aspect to this is that albeit controlport is pretty cool in > > > theory – an adaptable RPC server within GNU Radio, with pluggable > > > RPC > > > backends – its adoption has been slow to say the least, and it > > > doesn't > > > really tie neatly into any GNU Radio applications I'd be aware of. > > > > > > So, lest someone fixes the bug (I'll be describing it below), I'd > > > recommend we remove Controlport alltogether, and remove the thrift > > > dependency. I still stand by the very idea of controlport – having > > > RPC > > > access to what a flow graph does – but in the end, there's a > > > discussion > > > that we need to have: > > > > > > How do we want to do RPC in a way that enables us to make GNU Radio > > > far > > > more machine-agnostic than it is? How does one not only allow for > > > gathering of statistics and calling of functions, but build an RPC > > > framework that makes heterogeneous and distributed GNU Radio really > > > feasible? > > > > > > We've been addressing the question of what the scheduler needs to > > > become at the heterogeneous compute working group at GRCon'18. To > > > conclude, we need to get away from the "one buffer type fits all" > > > and > > > "all blocks are born equal and are just individual OS threads" > > > towards > > > domain-specific subschedulers and buffer managers. This is where > > > this > > > needs to tie in. > > > > > > Hence: Is anyone seriously using ControlPort and needs it for 3.8? > > > Please raise a metaphorical hand on the mailing list or write a > > > private > > > one in response to this email. > > > > > > Best regards, > > > Marcus > > > > > > ---------------------------------- > > > > > > Bug: clang correctly has been complaining for quite a while now > > > that > > > the RPCAggregator stores a reference to a temporary object. It > > > seems > > > that in the past this just worked by chance – probably, libc never > > > really got around to reassign the memory of these temporary objects > > > and > > > all lived happily everafter. However, now on multiple platforms, we > > > just see aborts in various tests due to access to freed memory. > > > Probably memory protection just got smart enough to kick some sense > > > into this code. > > > All is fine as long as one doesn't actually use the code in > > > question. > > > > > > > > > _______________________________________________ > > > Discuss-gnuradio mailing list > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
