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

Vladimir Rytikov kk6ygb at gmail.com
Tue Oct 3 08:41:17 EDT 2017


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> 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 listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at 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/a3697a59/attachment-0002.html>


More information about the USRP-users mailing list