Error: Underflow: the Tx buffer was emptied before new data was provided. Consider reducing the IQ rate, increasing the Write rate, or increasing the number of samples per Write.

[chahatb]

Hello 

I am getting following error with many vi's I have worked with. 

Underflow: the Tx buffer was emptied before new data was provided.  Consider reducing the IQ rate, increasing the Write rate, or increasing the number of samples per Write.

I randomly try to change IQ rate and other parameters because I really don't understand what this error means.

Please help.

[vvkakade]

Hi,

The underflow error means that the device was expecting samples at a particular rate and the host was not able to provide them at that rate. One common case where such an error could happen is when you configure to send small number of samples at a relatively high IQ rate which causes the effective rate of transfer to be low due to the overhead associated with each write Tx data call. Hence as the error sugests one can do the following to get rid of the underflow.

1. Reduce the IQ rate so that the host can keep up with the device's utilization of data from its buffer.
2. Increase the write size for data, which means that you write more data to the device's buffer per write call.
3. Increasing the write rate means that you may try to reduce the other operations (signal processing ) which you are doing (let's say in the tx continuous loop) which will increase the effective write rate attained by the host as it will get to spend more time on transmitting than doing the other processing.
4. Do a few small finite writes before you start the continuous transmission loop, this helps in priming the device buffers and can help prevent underflow.

Thanks.

[filipfilip]

Hey,

Could someone please answer these 4 small questions about avoiding the underflow (or at least some of them):

1) How does one increase the number of samples per write? Where is this done and what are best practice values?

2) What is the absolutely largest possible (but safe) value of "FastSendDatagramThreshold"=dword:XXXXXX that I can set for increasing the write rate for data?

3) I have also changed the sample width for 16bit to 8bit. Does this have any negative effect on my transmission, such as precision or something?

4) With the value under 2) set to 2400 HEX and 8-bit sample width, I still cannot achieve a stable transmission with the IQ rate of 8 MS/sec. Not only that I have buffer underflow after 2 minutes, but the value is also coerced to 7.69 MS/sec.

I am using NI USRP-2921 and I have also set my power options on the laptop to 'high perfromance'.

Thanks a lot for your time,

Filip

[ErikL]

We have seen:
* Desktop computers perform better than laptops.
* I have had the best luck with the manufacturer's latest driver
* increasing tx buffer depth to its maximum in the driver helps
* I don't think fast send datagram threshold is not needed for the latest driver
* sending more points to the driver at a time usually helps in each iteration of the while loop (but can increase latency)
* producing data and passing to the driver in a producer consumer (multiple loops with a fifo connecting them) is a recommended architecture.
* Intel chipsets seem to give the best performance overall.

These are just some things to try.... We've utized the hardware on many pc and laptop and it really just comes down to the hardware you are running on. Most Lenovos and MacBooks (booted to windows, not emulated) work well consistently. However sometimes the same model iof Lenovo Includes a different Ethernet chipset and then it has a different performance profile. Desktop PC can almost always run at full rate.

[filipfilip]

Hey ErikL,

Thanks a lot for your reply. Can you also please clarify these 2 small issues:

1. you wrote 'increasing tx buffer depth to its maximum in the driver helps'. How do I do that?

2. you recommended me to use desktop PC. If I get a fairly decent desktop PC, do you think that 8 MS/s is realistic to achieve? My VI is an upgrade of one of NI example VI's, and I don't think my modifications were so heavy that they could deteriorate the performance substantially.

Thanks,

Filip

[psisterhen]

1) The number of samples per write is simply the size of the array that you pass to niUSRP Write VIs.  It writes all of the samples that you give it.  It's better to call Write fewer times with larger arrays than many times with smaller arrays.

3) Yes, if you change the Sample Width to 8-bit you will get better streaming performance but drop some resolution in your samples.  You can make sure to transmit the most significant samples using the Expected Peak attribute.  For more information, see the example niUSRP EX Tx Customize Write Type and Sample Width.vi that ships with the driver.  And there is good documentation about these attributes in the NI-USRP Help.

4)  For the 2921, the sample rates are 100 MS/s divided by an integer N.  If N = 12, you get 8.333 MS/s.  If N = 13, you get 7.69 MS/s.  That's why you can't get exactly 8 MS/s.