Hi, 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.
-Michael On Tue, Oct 3, 2017 at 9:23 AM, Marcus Müller via USRP-users < usrp-users@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, > 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> 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 > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
