Getting overflows at 50 Msps (not sure why)

GNU Radio
1

Hello,

I am trying to get samples from a B200 at 50 Msps into GNU Radio. The
UHD benchmark_rate tool receives at 50 Msps without any overflows
detected. My GNU Radio flowgraph is simply a USRP source connected to a
null sink, and I’m still getting overflows. I’ve tried expanding the
min_output_buffer for the USRP source, but that doesn’t seem to help. I
really don’t know what is causing the problem. Any suggestions about
what I should try?

Thank you,
Orin L.

2

On Wed, Jun 4, 2014 at 5:16 PM, Orin L. [email protected]
wrote:

I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD
benchmark_rate tool receives at 50 Msps without any overflows detected. My
GNU Radio flowgraph is simply a USRP source connected to a null sink, and
I’m still getting overflows. I’ve tried expanding the min_output_buffer for
the USRP source, but that doesn’t seem to help. I really don’t know what is
causing the problem. Any suggestions about what I should try?

In addition to what Marcus said, if your application allows, you can
try 8-bit samples to relieve some pressure on the USB bus.

-TT

3

On 06/04/2014 05:16 PM, Orin L. wrote:

Thank you,
Orin L.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

What is causing the problem is that your computer/OS simply cannot keep
up. Gnu Radio has noticeably more overhead than a hand-crafted
program like benchmark_rate. Being able to maintain real-time
streaming at these rates is challenging, and just because
benchmark_rate
doesn’t fall over, is zero guarantee that some other program,
trying to swallow data at a similar rate, will actually be able to.

Desktop/Server operating systems (Windows, OSX, Linux, *BSD) aren’t
really optimized for dealing with high-bandwidth real-time flows.
In any given system configuration, it’s rather a crap-shoot as to
whether your system will be able to keep up or not.

What type of computer do you have? What OS? How much memory? Is it
the fastest memory you can use on your motherboard?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

On 6/4/2014 2:16 PM, Orin L. wrote:

Thank you,
Orin L.

On bladeRF, the number of USB3.0 buffers makes a big difference
in the maximum sample rate without overruns. On the B200, you
can try the same thing by increasing the number of buffers
in the device_addr arguments.

device_addr=“recv_frame_size=65536,num_recv_frames=128,…”

Ron

5

I appreciate the suggestions I received. It turns out that I was able to
run GNU Radio with realtime priority, and that solved my overflow
issues. I am now able to run flowgraphs that actually do things without
getting overflows all the time.

Thanks,
Orin L.

6

Orin,

Just curious what USB 3.0 chipset and OS you are using, and if you can
go
over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI
VL80x,
but not over that.

Thanks,
Lou
KD4HSO

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Getting-overflows-at-50-Msps-not-sure-why-tp48774p48945.html
Sent from the GnuRadio mailing list archive at Nabble.com.

7

On 06/16/2014 04:23 PM, madengr wrote:

Orin,

Just curious what USB 3.0 chipset and OS you are using, and if you can go
over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI VL80x,
but not over that.

Thanks,
Lou
KD4HSO

Also, I should point out that getting some high sample-rate in the
benchmark application is only a very-vague indicator of how well
things will
do when you’re actually doing things with the samples. It’s very
much cheaper to read samples and throw them away than it is to actually
do things, including recording, with said samples.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium