Re: Underruns causing USRP to stop transmitting and receiving

[Marcus Müller]

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 <patchvonbraun@gmail.com>
> Sent: Tuesday, October 20, 2020 1:03 PM
> To: Jerrid Plymale <jerrid.plymale@canyon-us.com>
> Cc: usrp-users@lists.ettus.com
> 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 <patchvonbraun@gmail.com><mailto:patchvonbraun@gmail.com>
> Sent: Tuesday, October 20, 2020 12:35 PM
> To: Jerrid Plymale 
> <jerrid.plymale@canyon-us.com><mailto:jerrid.plymale@canyon-us.com>
> Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
> 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 
> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> 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
> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>