sbrio-9606 Poor performance for sbRIO-9606 USB

[codcoder]

Hi guys,

 

Long time reader, first time writer.

 

I'm currently trying to develop a data gathering system using a NI sbRIO-9606.

 

The premise is quite straight-forward; I have a digital signal (data and clock) with a bitrate of 10 Mbit/s which I want to store to a USB flash drive in real time. The single-board RIO has no problem reading and processing the bitstream but storing the data to the USB flash drive is apparently not as easy as I thought.

 

According to the manual the USB port supports a transfer speed up to 480 Mbit/s (USB 2.0 standard?) but I've been unable to achieve any faster transfer speed than around 1 Mbit/s (1.3 Mbit/s worst-case). This is unaccaptable for my application!

 

I'v tried to disabeling buffering for the Open/create file function and only storing files in multiples of the sector size but it does not seem to help. Are there any preferrable USB flash drives one must use? Or am I unaware of any "high speed file streaming" options in LabVIEW?

 

Sincerley,

CC

 

[Jordan Kuehn]

Could you post some code of your write operation?  Are you doing any buffering of the data between acquisition and writing to disk (well USB)?

[smithd]

It does sound like you should be able to get better than that, but its hard to say without breaking up the problem a bit. One option is that the code is doing something strange which limits your max log rate. I'd try running the code and have it log to the local disk and see what rates you can get. Then you can compare to these benchmarks, which are on the main disk: http://www.ni.com/example/31206/en/#toc7 (the sbRIO should be a little better than the 9074, but likely not as fast as the 9068).

 

Assuming you get the expected rates when writing locally, you can start looking at the USB. There is absolutely no way you're going to hit 480 Mbit/s -- thats the *bus* limit, not the rate at which your CPU or the attached device can log to disk. But you can still look at the performance and try to improve it to meet your needs. One option is trying a different USB stick. Another thing worth checking is the formatting. I believe the sbRIOs should be able to handle FAT16 or FAT32, but you won't get anywhere near the speed of an NTFS system. (Source: Random person on the internet: http://www.msfn.org/board/topic/125116-fat16-vs-fat32-vs-ntfs-speed-on-usb-stick/)

[hooovahh]

You will never see advertised maximum transfer rates on any bus.  The 480MB/s mentioned doesn't take into account all the extra bit packing, bookend messaging, bit correction, or CRC checking of data.  

 

Getting higher transfer rates highly depend on how the data is being written.  Lets say you have 10 bytes of overhead for a packet over USB.  Well if you write one byte at a time you are going to have a lot of wasted overhead.  It would be best if you could write 1KB and only have that extra 10 bytes.

 

If you aren't already I recommend using TDMS.  It's made to be a streaming file format which handles buffering well for the most part.  You just perform the write operation and then it will flush to disk when criteria are met.  You can then post process the file into some other format if you like.

 

Of course you don't need TDMS, you can do your own buffering on a CSV file and it will probably work just as well in your application.

[codcoder]

Thanks for the input so far!

For obvious reasons (as stated) I will never reach the theoretical maximum of 480 Mbit/s, and nor do I need to, but still 0.2% of that is "amazingly" poor.

I use the FPGA on the sbRIO to store the bit stream in a DMA FIFO consisting of uint8 elements. On the RT processor I have two timed loops: one that pops a fixed number of elements from the DMA FIFO and pushes them as a byte array element on a queue and another loop that simply pops an element (a byte array) at a time and stores it on the USB flash drive using the standard write-to-binary-file block (with byte order set to native).

I’ve set the number of elements I read from the DMA FIFO in each iteration as a multiple (currently x8) of the sector size of my storage medium. I’ve tried to replace the USB storing with both storing on the internal memory of the sbRIO (thanks for the tip smithd!) and sending the data to my PC as a network stream. Both these variations have worked successfully with no loss in data, i.e. the sbRIO can send data fast enough both over Ethernet and to its internal memory, but the system design requires the data to be stored locally (and the internal memory is too small for my application).

I’ve also tried a couple of different USB sticks I have lying around with no better result but I’m gonna get my hands on an external SSD later this afternoos. I’ll let you know if that works.

Cheers,
CC

[codcoder]

Good news everyone!

Couldn’t find the SSD but I hooked up an old hard drive to the sbRIO with a SATA-to-USB adapter. Ran some benchmarking on forehand which reviled it to be around 10x faster than my USB flash drive.

And sure enough the sbRIO had no problem storing data to the hard drive while simultaneously streaming the data over Ethernet to my PC. The next step is to find a suitable storage medium but I know now that the sbRIO itself is capable to handle my application.

Thanks for the help guys!

Cheers,
CC

[smithd]

Glad to hear it.

 

One other tip you might keep in mind is to ensure you have a timeout of 0 in your DMA loop, or otherwise fairly tightly match the timing of the loop with the timing of the DMA. Any time period in which the DMA node is waiting on data is a busy wait--that is, is is hogging the CPU looking for data. This will definitely hurt the performance of your system (even if you are able to keep up, it can't hurt to do a little bit better ). This limitation is resolved in the shiny new cRIO released a few weeks ago, and the solution is documented here: http://digital.ni.com/public.nsf/allkb/583DDFF1829F51C1862575AA007AC792

[Rolf Kalbermatter]

Good news everyone!

Couldn’t find the SSD but I hooked up an old hard drive to the sbRIO with a SATA-to-USB adapter. Ran some benchmarking on forehand which reviled it to be around 10x faster than my USB flash drive.

And sure enough the sbRIO had no problem storing data to the hard drive while simultaneously streaming the data over Ethernet to my PC. The next step is to find a suitable storage medium but I know now that the sbRIO itself is capable to handle my application.

 

Unless you use a truely speced high speed flash pen drive you are likely to keep seeing poor performance. Especially those cheapo give away flash drives (I'm looking at you NI  ) have abominable performance, especially for writing. I've found that almost all flash drives that are handed out for marketing purposes seem to be of that super el cheapo quality, and similarly most noname flash drives that you can find in the super market stores.

 

Cost maybe half of a high quality brand drive but perform much less than half that good. 

[bbean]

Not sure if this is relevant to the conversation, but I wonder if the FIFO.Acquire Read Region DVR to TDMS technique discussed here:

 

http://lavag.org/topic/15335-why-tdms/?p=109716

 

would help with your scenario if you need to push performance.  See also:

 

http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqread/

[ned]

Not sure if this is relevant to the conversation, but I wonder if the FIFO.Acquire Read Region DVR to TDMS technique discussed here:

http://lavag.org/topic/15335-why-tdms/?p=109716

would help with your scenario if you need to push performance.  See also:

http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqread/

Unfortunately those functions aren't available on an sbRIO-9606, unless that's a new addition in 2014.