discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Vector Source and QT GUI Time Sink causes performance drop


From: Jeff Long
Subject: Re: Vector Source and QT GUI Time Sink causes performance drop
Date: Sat, 9 Jan 2021 20:54:39 -0500

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 <plucinski.mariusz@gmail.com> 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 <derek@bitstovolts.com>:
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 <w6rz@comcast.net>:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]