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, Marcus 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@lists.ettus.com <mailto:usrp-users@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@lists.ettus.com <mailto:USRP-users@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@lists.ettus.com <mailto:USRP-users@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@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
