I've had similar issues on the e310 with similar sample rates. On the e310 no usb is involved. Unfortunately I have not been able to fully get rid of the underrun issues as well.
So far I have tried: - separate threads with ping-pong buffers: this helped - linux real-time scheduling - increasing the linux process nice value : this helped - compiling with -O3 : this helped because I forgot initially - making the buffers a multiple of tx_streamer::get_max_num_samps() : https://github.com/EttusResearch/uhd/issues/128 : didn't help With all of this I still get about 1 underrun an hour, but it is sporadic. >From here I'm a bit stumped in looking for a software solution. Unless there is something in UHD? Some things that I haven't yet tried. - increasing buffering on the FPGA : should give me more time before an underrun - pushing more of the work to the FPGA to reduce burden on the pc On Thu, May 2, 2019 at 11:26 AM Ron Economos via USRP-users < usrp-users@lists.ettus.com> wrote: > Setting a large number of UHD buffers can help quite a bit. In the GRC > UHD Sink block device address: > > "num_send_frames=256" > > In Python: > > self.uhd_usrp_sink_0_0 = uhd.usrp_sink( > ",".join(("num_send_frames=256", "")), > uhd.stream_args( > cpu_format="fc32", > channels=range(1), > ), > ) > > Ron > > On 5/2/19 05:18, Matthias Brändli via USRP-users wrote: > > Dear all, > > > > I'm maintaining ODR-DabMod[1], a Digital Audio Broadcasting modulator > > which uses UHD to drive a USRP at 2048ksps, in most applications a B200. > > > > ODR-DabMod runs the modulator and the UHD output in separate threads, to > > ensure that a few modulated frames are always ready when the USRP needs > > one[2]. It requests realtime scheduling[3]. The system runs headless (no > > X11 running), and generally doesn't have anything else running. > > > > On some systems, we observe sporadic underruns. They occur in irregular > > intervals, something like once a minute, sometimes rarer. Seen with both > > USB2 and USB3 hosts, over several UHD versions. Until now we've mostly > > been able to avoid the issue by selecting machines that don't show the > > issue, but we hope we can find a mitigation in software. > > > > Both the data source the modulator connects to and the USRP have a > > disciplined time reference, implying there is no rate drift (plus, that > > would trigger regular underruns, not sporadic ones). > > > > > > There are some parameters described in USB Transport Parameters[4], does > > it make sense to change those? > > > > Could CPU frequency scaling lead to interruptions? > > > > Are there other knobs to turn that I'm not aware of? Device, stream or > > linux kernel settings? > > > > Is the approach of using a separate thread for UHD output beneficial? > > > > Anything else? > > > > Sorry for the vague description of the issue and the many questions, but > > I'm a bit out of ideas about how to approach that. If anybody had > > similar problems I'd be curious to hear your experiences. > > > > Cheers > > mpb > > > > [1] > > https://github.com/Opendigitalradio/ODR-DabMod > > > > [2] > > Look for m_queue in > > > https://github.com/Opendigitalradio/ODR-DabMod/blob/master/src/output/SDR.cpp > > > > [3] > > For all threads involved in DSP and the SDR output thread. Grep for > > `set_realtime_prio`. > > > > [4] > > https://files.ettus.com/manual/page_transport.html#transport_usb > > > > Default send_frame_size seems to be on line 85 of > > https://files.ettus.com/manual/b200__impl_8hpp_source.html > > > > _______________________________________________ > > 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
