Error -1074118647 - Overflow: an internal receive buffer has filled before the data could be returned

[Patrick78]

Hello everyone,

I have a USRP-2920 running on a DELL Latitude E6420, 4GB RAM and i5-2540M processor. USRP Driver Version 1.2 is installed. Windows 7, 64bit.

Whenever I try to run an example configuration for the USRP is crashes after a random time period and gives me the following error message:

Error -1074118647 occurred at niUSRP Fetch Rx Data (CDB WDT).vi

Possible reason(s):
Overflow: an internal receive buffer has filled before the data could be returned.  Consider reducing the IQ rate, increasing the Fetch rate, or increasing the number of samples per Fetch.

I attached an example configuration that shows the issue. However it happens with the other examples as well.

I tried changing the IQ rate and samples per fetch but best case this only extends the time until I see the issue. I tried it on a different Computer (same Make/Model) as well and see exactly the same issue.

I can't figure out what the cause of this issue is and it pretty much renders the USRP useless for me.

Any help would be highly appreciated. 

Thanks in advance.

Patrick

[cochenob]

How long exactly is, "a random period of time"?

WIth any application, if you're not taking samples out of PC memory faster than they're coming in, then you'll get the buffer overflow error.  This isn't unique to the USRP.  That said...large computer memory, lower sample rates, larger fetches, etc. will all help extend the time till overflow if your data processing is taking so long as to slow down your rate of fetches out of memory.

Still...looking at the example you attached...it looks like it is configured for finite acquisition...so you shouldn't have any issues with buffer overflow at all.  Maybe one of the App Engineers can give some advice here.

Are you running any other programs that might be eating up a large chunk of your memory?

---

Brandon

[Patrick78]

Hi Brandon,

thanks for the feedback.

The time until I get the error message for the attached VI is usually in the range of 20s to couple of minutes. I observed that with higher IQ sample (for example10 MS/s) it ususally crashes within seconds. Also the number of samples per fetch has an influence on that, as expected. But even if I chose IQ rates as low as 1KS/s I see the issue usually within a minute or two.

As for the laptop it is my regular work laptop so there is all kind of Software running in the background. Maybe it would be worth setting up a clean machine with only the OS and LabView on it?

Would be great to get some feedback from an App Engineer. Maybe they have seen this issue with other users in the past and can advise?

Thanks,

Patrick

[cochenob]

Patrick-

This sounds in line with my own experience...both with the examples and with developing my own applications.  With some of the example VI's that do continuous acquisition, it would not be uncommon, based upon both your machine as well as what your LV code is doing in between fetches, that you'd get an overflow.  This is especially true at wide BW's.

I've done real-time operation for one application that fetches about a million samples every second or so and have not run into overflow issues.  This included doing a whole bunch of processing in between fetches as well. The BW was low (200kHz), and not much else running on it except LV. Even when fetching data over 2 or 3 radios (so several million samples a second).  I should add though that I purchased a laptop with 32GB of RAM and a quad-core i7 to help assure that I had as big a buffer as possible...and I use these machines solely for USRP applications, so nothing else eats up resources. 

It's still curious though that you get these issues even when doing finite acquisitions. Seems to suggest that you've got other applications eating up what should be a sufficient amount of memory...but, as you see, it depends on all the variables.  Side note...I don't think you can decimate much lower than about 200kHz.  If you punch in something smaller than that, the driver coereces the value 'up' to 200kHz.

---

Brandon

[Patrick78]

Hi Brandon,

that all sounds pretty much like it could be a computer related problem. I will try setting up a dedicated machine with sufficient memory and CPU power for LabView only.

If anyone from the NI support time has any other suggestions I would be very happy to hear them.

Thanks for you help so far.

Patrick

[Door-C]

Patrick,

Is this USRP connected directly to your computer? Be sure you have a Gigabit connection on your computer and any switch you may be going through. If you are connected over a network you may have a lot of traffic on the network and it could be causing issues.

Try removing the niUSRP Initiate.vi in the while loop as well. It may run faster without the intiate every iteration of the loop.

This sounds like a limitation of the computer's hardware or the network connection to me.

[Patrick78]

Hi Noah,

the computer is connected directly to the USRP. Nothing in between and no other network connection used on the machine when I execute the VI.

If I remove the Initiate.vi from the loop the program doesn't execute properly anymore. I guess it needs to see that initiation on every iteration (sorry I am fairly new to working with the USRP).

I am in the process getting a dedicated system. If that also doesn't fix the issue I will let you know.

Thanks,

Patrick

[ErikL]

The NI USRP driver streams data directly to the host PC. There is no meaningful amount of onboard memory. On the host there is a circular buffer that catches the Ethernet packets. If LabVIEW can not pull data from that buffer fast enough you will overflow. The random amount of time often means other services running on the PC armrest taking priority / disrupting the thread.

There are many best practices but it's an art not a science. Set power options in windows to high performance and use an Intel Ethernet card are my biggest advice points.

[Patrick78]

Hi all,

I just wanted to let you know that it must have been some sort of issue with the computer. On a freshly installed desktop system with i3 CPU and 4GB RAM it runs without any problems up to the highest sample rates.

Just thought I would post this in case anyone else experiences this issue in the future.

Thanks for all your help! 

Patrick

[皓翔_student]

Hi, Patric

    Recently I face the same problem like you. How do you solve the problem in the end? I use both USRPs as TX and RX. But the RX occurs overflow when I specify the higher IQ rate. If you have any good method to solve this problem, please let me know. Very appreciate. 

Shung