Hi Jerrid, what kind of analysis are you doing? I think it would be most helpful if we could see a full flowgraph, and maybe the critical code.
In general, one or multiple blocks in your processing chain will be posing a bottleneck. On Linux, `htop` with "Show Thread Names" enabled is a quick way to diagnose a CPU hog. Best, Marcus the younger On 20.10.20 22:17, Jerrid Plymale wrote: > Marcus, > > Ok, I have moved this discussion to the GNU Radio email list. As far as > sampling rate is concerned, we are only running at a 4 MHz sampling rate. I > have ran tests with the USRP x310 and the PC we are using for development, > and I was able to run a sampling rate of up to the 200 MHz clock rate without > issue. > > Best Regards, > > Jerrid > > From: Marcus D. Leech <[email protected]> > Sent: Tuesday, October 20, 2020 1:03 PM > To: Jerrid Plymale <[email protected]> > Cc: [email protected] > Subject: Re: [USRP-users] Underruns causing USRP to stop transmitting and > receiving > > On 10/20/2020 03:53 PM, Jerrid Plymale wrote: > Marcus, > > The problem seems to be related to running the system with the USRP though. > Someone who is working on this project with me is able to run the same > embedded python block, without the USRP hardware, and gets no Underruns when > doing so. We have also been unsuccessful in finding any useful information > regarding potential causes and solutions from GNU Radio and USRP > documentation. > > Best Regards, > > Jerrid > Well, an underrun is conceptually simple. It means "you aren't supplying me > with samples at the desired rate, so when I went to grab some > samples, there weren't any there". That means your flow isn't supplying > them at the desired rate, either due to computational starvation, > or a mis-understanding/mis-configuration of things like re-samplers. > > Some SDRs out there DO NOT REPORT overruns/underruns, so things can "seem" > great and not be. > > Further the computational envelope and requires of the UHD driver may be > different-enough from other hardware that is operating at > similar rates that you end up with underruns. When you're running at the > edge of what can be accomplished with the compute > hardware at hand, small differences are what makes the difference. > > What sample-rates are we talking about? Are you configuring your hardware > for a sample-rate it can actually support, for example? > > Much of this discussion really does belong in the discuss-gnuradio arena, > because it comes down to Gnu Radio performance tuning. > > Also, you mention an embedded processing block--presumably embedded Python? > Such blocks CANNOT be run at high sample > rates--even if you use numpy to do all your math, the marhsalling and > interpreter costs will kill performance compared to a > similar block written in C++. > > > > > From: Marcus D Leech <[email protected]><mailto:[email protected]> > Sent: Tuesday, October 20, 2020 12:35 PM > To: Jerrid Plymale > <[email protected]><mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]> > Subject: Re: [USRP-users] Underruns causing USRP to stop transmitting and > receiving > > Probably better served by the discuss-gnuradio list and the chat.gnuradio.org > online chat community. > Sent from my iPhone > > > > On Oct 20, 2020, at 3:30 PM, Jerrid Plymale via USRP-users > <[email protected]<mailto:[email protected]>> wrote: > > Hello All, > > So I am working on writing an embedded python block in GNU Radio Companion to > preform some analysis of RF signals that is received by a USRP x310 and > transmitted back out of the USRP after analysis has been done. I have been > running into some underruns lately that I have not been able to find a > solution for. If I execute some of my analysis functions in the work function > of the block, the application underruns and it causes the USRP to stop > transmitting or receiving. However, if I execute the functions in separate > polling functions that are being used to display values in the GUI, I do not > get underruns. I think this might has to do with how often the analysis > function is being executed, as the poll functions are only called at a rate > of 10 Hz which is controlled by a function probe. Can anyone give me > suggestions on what to try to fix the underrun problem, and any resources you > can point me to that might help would be appreciated. > > Best Regards, > > Jerrid > _______________________________________________ > USRP-users mailing list > [email protected]<mailto:[email protected]> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
