That GRC uses almost no processor on a Fedora 33, maint-3.8 installed via PyBOMBS.
On Mon, Jan 11, 2021 at 6:31 AM Marcus Müller <[email protected]> wrote: > Hi, > > I'm on the run, else I'd start a Ubuntu VM myself, but: > > sudo apt install linux-tools > sudo sysctl -w kernel.perf_event_paranoid=-1 > > perf record -ag python3 /path/to/your/flowgraph.py > > run for a couple of seconds, close. > > Afterwards, > > perf report > > will hopefully show you a percentage of "of the times we looked, the CPU > was busy with this and that function". > > Best regards, > Marcus > > On 11/01/2021 12.15, Mariusz Pluciński wrote: > > Hi, > > > > I tested on a different machine of mine (Fedora 32, GNU Radio 3.8.2) and > > the problem does not occur there. > > This suggests that the problem is somehow specific to this Ubuntu > > system, but not to a specific build of GNU Radio (nor Python, it occurs > > with both 3.8 and 3.9). Since this looks more like a GUI problem than > > signal processing itself, I'm wondering if it may be related to the Qt > > version there - 5.12.8. The machine it works correctly on has 5.14.2 > > installed. > > > > Attached the test file. It works fine on my Fedora but very slow (in > > terms of GUI responsiveness) on my Ubuntu. Would be great if somebody > > could point me in a right direction of what else I can check. > > > > Mit freundlichen Grüßen > > Mariusz Plucinski > > > > > > Am So., 10. Jan. 2021 um 18:41 Uhr schrieb Jeff Long > > <[email protected] <mailto:[email protected]>>: > > > > I was using 2MS/s, tested with 3.8 and master (which should be close > > enough to 3.9). Nothing comes to mind. You could post a GRC file, > > just in case there's a misunderstanding of how something works. > > > > On Sun, Jan 10, 2021 at 10:00 AM Mariusz Pluciński > > <[email protected] <mailto:[email protected]>> > > wrote: > > > > Thank you for trying this. It assures me that it's something > > wrong either in my project or in my configuration. > > > > I also tried to build GNU Radio from source (3.9.0 RC2 from > > git), but the problem also occurs there. > > > > What do you mean by "reasonable sample rate"? I'm trying with > > very low values like 300 (in both throttler and time sink) and > > the problem still occurs. > > > > In the new build, there seems to be a small delay before the > > data appear on the chart. Up to this moment, the window is > > reponsive, but as soon as the green lines appear, it becomes not > > responsive again - best visible when trying to resize the window. > > > > Is there anything else I can check? > > > > Mit freundlichen Grüßen > > Mariusz Plucinski > > > > > > Am So., 10. Jan. 2021 um 02:55 Uhr schrieb Jeff Long > > <[email protected] <mailto:[email protected]>>: > > > > I gave this a try, adding Vector Source -> Throttle -> QT > > GUI Time Sink to a flowgraph. Performance is fine at 2MS/s > > on an older laptop. Make sure that the Throttle is being set > > to a reasonable sample rate. > > > > On Sat, Jan 9, 2021 at 6:35 PM Mariusz Pluciński > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi, > > > > Thanks for the answers. Unfortunately, I already tried > > this before (forgot to mention) and it doesn't change > > anything in this weird behavior of the GUI window. > > It also doesn't help to have a hardware source and/or > > sink in the flow (tried with Audio Sink and osmocom > > Sink/Source); as soon as I enable both Vector Source and > > QT GUI Time Sink at the same time (anywhere in the > > flow), everything becomes unusably slow. > > > > I also tried to add a separate path Null Source -> > > Throttle -> Null Sink (as seen somewhere in the Wiki), > > but this also didn't help. Changing sample rate of the > > throttle also doesn't seem to change anything. > > > > Is there any way I can diagnose this issue? > > > > Regards, > > Mariusz > > > > Am Sa., 9. Jan. 2021 um 23:47 Uhr schrieb Derek Kozel > > <[email protected] <mailto:[email protected]>>: > > > > Hi Mariusz, > > > > The main issue here is that you're missing a > > Throttle block in your flowgraph. You have no > > Hardware block in the flowgraph, it is pure > > simulation. GNU Radio will try to run the processing > > as fast as possible, using 100% of available CPU. A > > Throttle block limits the simulation speed to > > approximately realtime (to the set sample rate per > > second). > > > > A hardware source or sink will have a real, physical > > clock and will restrict the number of samples > > produced (Source) or consumed (Sink) and the other > > blocks will not be able to run at infinite speed > > (using all the CPU). > > > > I'm curious why that would work better with a > > different non-hardware source rather than the Vector > > Source, but the recommended fix is straightforward. > > > > Regards, > > Derek > > > > > > > > > > Am Sa., 9. Jan. 2021 um 23:49 Uhr schrieb Ron Economos > > <[email protected] <mailto:[email protected]>>: > > > > It's telling you what's wrong. > > > > >>> Warning: This flow graph may not have flow > > control: no audio or RF hardware blocks found. Add a > > Misc->Throttle block to your flow graph to avoid CPU > > congestion. > > > > Add a Throttle block between the Vector Source and > > QT GUI Time Sink blocks. > > > > Ron > > > > > > On 1/9/21 14:32, Mariusz Pluciński wrote: > >> Hello everybody, > >> > >> I'm quite new to GNU Radio (and to signal > >> processing as well), but I did a few successful > >> experimens. But now, I encountered a weird > >> behavior, namely: > >> > >> Every flowgraph including Vector Source and QT GUI > >> Time Sink conencted (regardless if directly or > >> with intermediate steps) causes huge performance > >> degradation. CPU usage jumps to 100% of a core, > >> window takes a few seconds to refresh, GUI becomes > >> almost unusable. > >> > >> Everything works well if I use any different > >> source, .e.g. Signal Source or osmocom Source. > >> Everything works well if I use any different sink, > >> e.g. Audio Sink or QT GUI Frequency Sink. > >> > >> It's just this specific combination that causes > >> the issue. Drastically reducing the number of > >> points in the Time Sink helps, but at the cost of > >> the output becoming useless. > >> > >> To reproduce the problem, it's enough to do the > >> following in GNU Radio Companion: > >> 1. Create an empty flow graph > >> 2. Add "Vector Source" > >> 3. Change "Vector" parameter to "(0, 0, 0, 1)" > >> 4. Add "QT GUI Time Sink" > >> 5. Connect both blocks > >> 6. Run > >> > >> Am I doing something wrong here? > >> > >> (in case it's necessary, my ultimate goal here is > >> to use the vector source as a source of bits to > >> modulate a square wave; the output will later be > >> transmitted out, but first, I'd like to see it in > >> the Time Sink) > >> > >> I'm using GNU Radio 3.8.1.0 on Ubuntu 20.04. > >> > >> Best Regards, > >> Mariusz Plucinski > > > >
