discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
Date: Wed, 04 Jun 2014 17:21:25 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 06/04/2014 05:16 PM, Orin Lincoln wrote:
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 Lincoln

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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 Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]