Cause of REDHAWK UHD Receive Overflow

Question

I'm running REDHAWK 1.10.1 on a CentOS 6.6 VM (on Macbook Pro OS X 10.10 via Parallels). I'm using a USRP N210. I'm simply trying to get things up and running before I connect an actual waveform to it.

I configure OS X with:

sudo sysctl -w net.inet.tcp.sendspace=1048576
sudo sysctl -w net.inet.tcp.recvspace=1048576

And CentOS with:

$ sudo sysctl -w net.core.wmem_max=1048576
$ sudo sysctl -w net.core.rmem_max=50000000

I also configure the thread scheduling priority by appending to /etc/security/limits.conf:

@redhawk  - rtprio    99

Right now I just have the USRP_UHD dataShort_out connected to a DataConverter dataShort_in. Data is flowing, but fairly soon after I begin execution, I receive the following message repeatedly:

USRP_UHD_i:1295 - WARNING: TIMEOUT OCCURED ON USRP RECEIVE! (received num_samps=0)

I'm thinking this might be a data flow issue, but I can not find any reference to the message. Might it be caused by the OS X receive buffer size (which I assume is limiting the CentOS VM)? Unfortunately, OS X won't allow me to raise it much higher than that, surely not to 50 MB. What could cause this message?

I'm using the WBX daughter board. I tuned to 2 GHz, BW of 40 MHz, SR of .2 Msps.

DevMgr Node output:

2015-02-18 19:48:06,578 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:101 - Issuing event for DCE:9da85ebc-6503-48e7-af36-b77c7ad0c2b4 ({'fivemin': 0.26000000000000001, 'fifteenmin': 0.20999999999999999, 'onemin': 0.20999999999999999} != {'fivemin': 0.23000000000000001, 'fifteenmin': 0.20000000000000001, 'onemin': 0.11})
2015-02-18 19:48:06,584 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:101 - Issuing event for DCE:6565bffd-cb09-4927-9385-2ecac68035c7 (3692 != 3693)
2015-02-18 19:48:06,585 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:103 - Eventing for properties ['DCE:9da85ebc-6503-48e7-af36-b77c7ad0c2b4', 'DCE:6565bffd-cb09-4927-9385-2ecac68035c7']
2015-02-18 19:48:06,586 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:65 - Skipping sendPropertiesEvent (no connections)

USRP Node output:

2015-02-18 19:48:55 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=400000 buffer_capacity=943718
2015-02-18 19:48:56 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=800000 buffer_capacity=943718
2015-02-18 19:48:57 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=71859 buffer_size=943718 buffer_capacity=943718
2015-02-18 19:48:57 DEBUG USRP_UHD_i:240 - serviceFunctionReceive|pushing buffer of 471859 samples
2015-02-18 19:48:58 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=400000 buffer_capacity=943718
2015-02-18 19:48:59 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=140642 buffer_size=681284 buffer_capacity=943718
2015-02-18 19:48:59 WARN USRP_UHD_i:1295 - WARNING: TIMEOUT OCCURED ON USRP RECEIVE! (received num_samps=0)

score 1 · Answer 1 · edited May 23 '17 at 11:48

1

What values are you using for your tuner allocation? I had the same problem as you a long time ago. I think the issue was using values that were out of range for the USRP.

Try these:

center freq = 462e6
bandwidth = 40e6
sample rate = 0.2e6

Afterwards, you may encounter a new problem with the ports. I would recommend following the problem and solution here.

edited May 23 '17 at 11:48

Community

1
1

answered Feb 10 '15 at 19:36

user3508688

40
6

I've experimented with a bunch of settings, including some very similar to what you suggested. I still experience the issue. I'm beginning to wonder if it is because of the VM network performance. I may end up trying a native Linux install to see if that fixes it. Were you using a VM? – bruno617 Feb 17 '15 at 21:56
Yes, I used CentOS 6.5 through the oracle vmbox. If you have the time could you try this? Run the domain in debug level 4 or 5. Run the device in debug level 4 or 5. Let both run for a bit, and then copy paste some of the results before it starts giving you the warning. – user3508688 Feb 18 '15 at 22:21
Also, you may need to check which daughterboard your USRP is using here: http://www.ettus.com/product/details/UN210-KIT – user3508688 Feb 18 '15 at 22:33
I'm using the WBX daughter board. I tuned to 2 GHz, BW of 40 MHz, SR of .2 Msps. DevMgr Node: `2015-02-18 19:48:06,578 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:101 - Issuing event for DCE:9da85ebc-6503-48e7-af36-b77c7ad0c2b4 ({'fivemin': 0.26000000000000001, 'fifteenmin': 0.20999999999999999, 'onemin': 0.20999999999999999} != {'fivemin': 0.23000000000000001, 'fifteenmin': 0.20000000000000001, 'onemin': 0.11}) 2015-02-18 19:48:06,584 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:101 - Issuing event for DCE:6565bffd-cb09-4927-9385-2ecac68035c7 (3692 != 3693)` – bruno617 Feb 19 '15 at 01:16
DevMgr Node continued... `2015-02-18 19:48:06,585 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:103 - Eventing for properties ['DCE:9da85ebc-6503-48e7-af36-b77c7ad0c2b4', 'DCE:6565bffd-cb09-4927-9385-2ecac68035c7'] 2015-02-18 19:48:06,586 DEBUG DCE:0b818b5e-aa99-47ac-87ca-ff4d37b6991b{1}:65 - Skipping sendPropertiesEvent (no connections)` – bruno617 Feb 19 '15 at 01:16
USRP Node: `2015-02-18 19:48:55 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=400000 buffer_capacity=943718 2015-02-18 19:48:56 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=800000 buffer_capacity=943718 2015-02-18 19:48:57 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=71859 buffer_size=943718 buffer_capacity=943718 2015-02-18 19:48:57 DEBUG USRP_UHD_i:240 - serviceFunctionReceive|pushing buffer of 471859 samples` – bruno617 Feb 19 '15 at 01:19
USRP Node continued... `2015-02-18 19:48:58 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=200000 buffer_size=400000 buffer_capacity=943718 2015-02-18 19:48:59 DEBUG USRP_UHD_i:1312 - usrpReceive|received data. num_samps=140642 buffer_size=681284 buffer_capacity=943718 2015-02-18 19:48:59 WARN USRP_UHD_i:1295 - WARNING: TIMEOUT OCCURED ON USRP RECEIVE! (received num_samps=0)` – bruno617 Feb 19 '15 at 01:20

score 0 · Answer 2 · answered Mar 22 '15 at 13:47

The problem when you're seeing overflows is simply that your PC doesn't keep up with the samples that come in. At a sample rate of 200kS/s that means that your VM might be underpowered or your application too complex.

There's nothing you can do about this, other than making your application and/or machine more performant.

In general, doing software defined radio in a VM is a bad idea. There is a lot of I/O work to be done, and the virtualization places a significant overhead on each ethernet frame that enters your VM.

Cause of REDHAWK UHD Receive Overflow

2 Answers2