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> 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@lists.ettus.comhttp://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 > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
