NI-2920 buffer size

[cochenob]

Call me crazy, but I can't seem to find the size of the memory on the USRP.

Looking to get a handle on how much room I have in order to determine fetch size/fetch rate/etc..

A related question...is it possible to monitor the number of samples/percentage of the buffer used/etc. on the USRP through the driver? 

---

Brandon

[Leah-L]

Hi Brandon,

I was taking a look at the schematic on the system block diagram here. http://sine.ni.com/ds/app/doc/p/id/ds-355/lang/en.

From the looks of this, it doesn't seem like there is any hardware memory on the USRP itself. All the memory allocation takes place in the RAM of your computer. This would explain why there is no spec for the buffer on the USRP.

Leah 

[cochenob]

Hi Leah-

I agree that this info isn't in the block diagram or other specs of the USRP...but the digitized IQ samples have to be stored *somewhere* (even if only temporarily) until the the Ethernet call from the PC to fetch them from the radio.  I assumed the operation is similar to the DAQ cards, which have some finite on-board memory buffer that holds samples until LabView calls a VI to fetch them.  Are you saying that the USRP is sending Ethernet packets back continuously, and that the "Fetch" VI's are really "fetching" to memory on the PC?

---

Brandon

[Sarah_Y]

Hey Brandon,

Since this is an Ethernet based device, data has to be sent as packages or at least Ethernet frames.  The default is to use 1472-byte frames.  The FPGA has a small section that is large enough to allow double buffering for a maximum-sized VITA-49 frame.  The FPGA is what directs the into/out of VITA-49-over-UDP-over-1GiGe frames.  The USRP is set up to be a streaming architecture and in that way is different than a DAQ card.  Keep in mind this is for the receive chain.  There is a very small buffer for transmit, but it is only big enough for a fraction of samples even at lower IQ rates like 1 MS/s.  

[cochenob]

Hi Sarah-

Thanks for the heads up.  I clearly misunderstood how the data transfer works here, so I'm glad I asked!  This however opens up a whole other world of questions....

- If I understand correctly now...as soon as I call the "Initiate.vi"...Ethernet packets start flying back to the PC?  The FPGA has a big enough space to hold/package the current data until the next packet is ready to head back to the PC.

- In the USRP help documents...there's a short section that says in order to optimize data transfer...try to make your fetches some multiple of a certain number that represents a "full" Ethernet packet.  This sort of made sense to me when I thought that the "Fetch" vi was initiating a call for data from the radio.  However...if you're really fetching from a PC memory address space...who cares if it's a multiple of an Ethernet packet? 

- Where in the process is PC memory being allocated?  How does it know how much to allocate?

I probably have a million more questions.  Do you guys have any more detailed documentation on what exactly the driver is doing here.  It might be easier.  I'm looking to do continuous acquisition/analysis, and am trying to understand the timing requirement/data flow in order to really understand what I need to do in order to assure myself that there won't be any "data gaps" in jumping back and forth between my "parallel" acquisition and processing tasks.  Said another way, I need to verify that whatever processing tasks I do are able to "keep up" with the acquisition task, and that I don't miss contiguous data/create a memory overflow/etc..  At this point, I feel like I know less about how the radio than I did 5 minutes ago!  Mayday!

---

Brandon

[cochenob]

Sarah (and friends!)....

After a day or so of thinking about this, and reading up on what exactly VITA-49 is, I suppose I can be convinced that even though I can't see what's going on underneath the hood....that between the large PC memory and VITA-49 protocol...I shouldn't be worried about "missing" portions of data.  Though, if you had any info (that wasn't propriatary) in how the driver manages to "keep up" and "keep track" of contiguous data from the radio, it would certainly give us a higher level of confidence.  Some other devices that we've been using do not handle this data management for the user automatically (meaning the user has to write a driver themselves).  In that sense, it would be nice to know, at least at a high level, what's going on so we can compare/contrast.

I would also be great to understand a little better how the driver manages the data once the VITA-over-UDP-over-1GigE frame gets stored into PC memory.  Some pieces of info that would be good to have...

1.  Can I actively monitor how much memory is being eaten up by storing USRP data packets?  This would help provide some feedback (Are the fetches large enough?  Are they happening fast enough?  Is the processing taking too long? etc..).  In the past I know I've found scenarios where the PC would crawl to a halt and throw a memory overflow error...probably because I wasn't fetching fast enough, or my fetch sizes were too small.  Correcting these helped...but there was never really any rhyme or reason or way to predict what would work and what wouldn't.  In fact...the documentation suggests something like, "just make your fetches bigger".  Having a more concrete picture, or at least some kind of feedback/monitor, might go a long way.

2.  Clearly...I'm not really familiar with how all of the timing details are handled here...but what would happen if I requested a fetch size that was bigger than what's been delievered so far and sitting in memory?  Would the driver wait?  Would there be an error?  Could this scenario even happen (like when using a really slow IQ sample rate)?

3.  It's still not clear why it is suggested that fetches are some multiple of an Ethernet-sized packet, when a fetch is really only  from memory and not over the network to the hardware.  Is this because it's more efficient to remove from memory in the same size that you're writing to it?  (i.e. - in 1GigE sized chunks?)

Hope I'm not unnecessarily dragging everyone down into the weeds with all of this.  We're just trying to make sure we understand the abilities/limitations of the device.  Thanks for all the feedback.

---

BC

[Leah-L]

cochenob,

I am still looking into the answers to your questios that you listed, but I found this article that talks about the performance of your USRP with regards to the capabilities of your host PC. 

http://www.ni.com/white-paper/13882/en

Leah

[cochenob]

Thanks Leah-

I agree that towards the end, the article hints at some of the questions I'm asking.  However, one must admit that it's still a bit wishy-washy in terms of what the driver is actually doing.  It basically says, "We tried this example on a PC with these characteristics, and it seemed to work.  If your application doesn't work...get a faster computer with more memory."

What I'm hoping to do is get some insight into how the driver is managing all of this so that I might be able to predict whether I'm going to run into issues....or....to know where the potential roadblocks will be so I can design my code/processing appropriately.

Thanks for the discussion.

---

Brandon

[Leah-L]

Brandon,

I think I have a little more information regarding your previous questions.

There isn't really a way to actively monitor how much memory is being eaten up by storing USRP data packets. Just like any other programs, you can't see how much memory is divided into different sections of the code, so there isn't away for us to see how much memory is being allocated to the USRP receiver. So what we are left with are guidelines for what our fetche sizes should be.

However, memory overflow errors can happen as a result of several different factors. For example, the processing that is going on inside the program, what is happening outside the program (instant messengers, anti virus, etc), and the configuration of the network adapter card ("energy efficient setting, etc).

Essentially, there is no way to ensure that we won't get errors, because we are not in control of what the CPU does. 

Does this information help?

Leah

[Anthony_F]

It has been my experience that the most crucial part of getting the USRP running as fast as possible is what I place just after the Fetch Rx Data VI (aside from the registry edit and network card settings).

Take, for example, the continuous receive example: It contains two graphs, one for graphing IQ and one for graphing an FFT of the samples that were just fetched. 

At a sample rate of 10 MSa/s I can run this program at least a minute with no errors.

If I change the number of samples control to a larger value, say 500k, then it runs for about 7 seconds before error. If I remove the FFT processing it runs indefinitely again. But this conflicts with my goal of seeing frequency spectrum with an acceptable noise floor.

I heavily believe that the role of memory management plays a very small part next to what happens with those samples in your program and what programs are using network resources at the same time.

What sample rates are you planning on using?

Are you currently having troubles with those rates?

What types of processing do you need after the fetch?

It's very hard to say how all computers and ethernet cards will react when being pushed to their limits (such as streaming >20 MSa/s over ethernet).