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

Marcus Müller marcus.mueller at ettus.com
Tue Oct 3 09:23:02 EDT 2017

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:
> Marcus,
> 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 <mailto: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,
>     Marcus
>     ¹: 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:
>>     Hi,
>>     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.
>>     Thanks,
>>     Vladimir 
>>     _______________________________________________
>>     USRP-users mailing list
>>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>     <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171003/4929a01f/attachment-0002.html>

More information about the USRP-users mailing list