[USRP-users] polyphase clock sync eats 100% cpu once it gets samples

Steven Knudsen ee.knud at gmail.com
Wed Oct 4 11:16:04 EDT 2017

Hey Michael,

throwing in my 2 cents, I found the same last year and implemented separate logic to monitor RSSI and set thresholds. In my case I was receiving in consecutive slots from different radios, so the RSSI varied a lot. 

You also have to be careful with any loop tracking algorithms for the same reason… not always receiving from the same transmitter can mess things up.


On October 4, 2017 at 08:21:29, Michael Wentz via USRP-users (usrp-users at lists.ettus.com) wrote:


I ran into a similar problem several months ago - what I found was that the correlation estimator produced a *huge* number of false positives (and a tag for each of them) which caused the clock recovery block to be super overwhelmed. If I recall correctly, there were also some cases that these tags would send the clock recovery block into an infinite loop. We rolled back the correlation estimator to the previous version, which uses absolute thresholds, as a quick fix.


On Tue, Oct 3, 2017 at 9:23 AM, Marcus Müller via USRP-users <usrp-users at lists.ettus.com> wrote:
That's very interesting, indeed! If I had to infer (sorry, not right now on a computer where I can test) from the thread name "header_payload2", I'd say that for some reason that I don't know, the header/payload demuxer in packet_rx "spins" on something.

If you want to, throw some more runtime analysis at this: 

sudo apt-get install linux-tools
sudo sysctl -w kernel.perf_event_paranoid=-1
perf record -ag python /path/to/uhd_packet_rx.py

[let it run for a while, e.g. 30s, end it]

perf report

That should give you a quick insight in which function/code line your processors where stuck the most time. Maybe that brings us one step forward.

Best regards,

On 03.10.2017 14:41, Vladimir Rytikov wrote:

cpu: Intel Core i7-7820HQ (Quad Core 2.90GHz, 3.90GHz Turbo, 8MB)
chipset: Intel Mobile CM238
RAM: 32GB (2x16GB) 2400MHz DDR4
OS: ubuntu 16.04 TLS
almost no other software running - only GNU Radio.

htop shows digital/packet/uhd_packet_rx.py takes ~192 % CPU.
header_payload2 - ~100%
pfb_clock_sync2 - ~90%

and the flow graph visually is frozen.
I run volk_profile - it saved some files in .volk directory.
I restarted the test again after it. the same result. htop shows the same numbers.

the RF signal has correct shape at the freq doman - I am splitting the signal to a spectrum analyzer- no overdriving the transmitter. the signal inside the coax cable. 433 MHz freq as in the example. visually looking at the Time tab - input signal within  -1 to 1. The recv dies at the moment when I press 'On' check box - it ungates receiver chain and polyphase clock sync block. transmitter sends bursts every 2 seconds.
the only modifications comparing to the vanila example - Clock/Time sources - I changed to Default instead of O/B GPSDO.

-- Vladimir

On Tue, Oct 3, 2017 at 4:57 AM, Marcus Müller via USRP-users <usrp-users at lists.ettus.com> wrote:
Hi Vladimir,

synchronization is usually among the most CPU-intense things a receiver does (only, if at all, contested by channel decoding for complex codes). So, the 100% CPU utilization don't sound totally unreasonable, depending on your system.

That being said, I don't want to rule out bugs, but for the time being, I'd declare this issue as "unclear, probably insufficient compute power".

Can you tell us a bit about your computer, in terms of CPU model, motherboard chipset, RAM configuration, OS? If you install and run "htop"¹, you'll see which block does how much without much complication, and maybe also significant non-GNU Radio CPU usage (for example, my mail client and my browser idling use *serious* amounts of CPU).

Another thing worth trying is to close all software that might be using CPU (check with htop!) and then run "volk_profile"; this should test a lot of hand-written implementations for certain math operations, which might significantly speed up the polyphase clock sync.

Best regards,


¹: I'm assuming you're using windows; after starting htop, press F2 for setup, go into the "Display Options", enable "Show custom thread names", press Esc

On 03.10.2017 12:54, Vladimir Rytikov via USRP-users wrote:

I am trying to run an example from GNU Radio - examples/digital/packet/uhd_packet_rx and uhd_packet_tx with real USPR radios connected via an attenuator and a coax cable.

When I enable receiver by clicking on 'On' check box - the whole RX flow graph freezes.
I think I manually adjusted transmit power and receive gain to be within reasonable ranges.

By disabling different blocks one at a time I found is that polyphase clock sync inside packet_rx blocks kills the flow graph. It seems like the signal is gaited by Correlation Estimator and once it gets the correct sync word - the signal goes to Polyphase Clock Sync and CPU dies - it is 100% loaded all the time.

If I run only loop back simulation the whole flow graph seems working fine. I wonder if noise or not very good signal destroys Polyphase Clock Sync.

I installed GNU Radio via PyBOMS - 3.7.12git* version. Please help to find better idea on debugging it.

with a different simple flow graphs Polyphase Clock Sync works fine even when I feed noise to it and signal later.


USRP-users mailing list
USRP-users at lists.ettus.com

USRP-users mailing list
USRP-users at lists.ettus.com

USRP-users mailing list
USRP-users at lists.ettus.com

USRP-users mailing list  
USRP-users at lists.ettus.com  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171004/b5657690/attachment-0002.html>

More information about the USRP-users mailing list