Optimizing UDP on ARM or Blackfin

[Chris_Megdanoff]

We are in the process of evaulating the Blackfin and ARM modules for use in an application where we've already migrated from PC to cRIO (and/or sbRIO), and I was wondering if anyone has tried to optimize UDP communications between any of the embedded processors and PCs?  

One of the largest loads in the cRIO is the publishing of our data packet which is about 8192 bytes every 10ms per channel (2 channels currently).

Therefore, I ran a test to see how fast the Blackfin and ARM was able to write a constant packet  8192 bytes to a UDP port.  It's a rather disappointing, but I'm thinking that the standard UDP functions may not be optimized for this.

I'm also going to look into the clock rates, and any thing else I can think of, but if anyone else as gone down this road, please chime in.

Chris 

[Kevin_S]

Chris,

The Blackfin module calls into the open source lwIP stack.  I believe that the source for it on your computer is here:

C:\Program Files\National Instruments\LabVIEW 2009\Targets\ADI\Embedded\vdk\common\lv_lwip

The ARM module calls into the Ethernet stack from Keil.  I believe that the source for it on your computer is here:

C:\Program Files\National Instruments\LabVIEW 2009\Targets\Keil\Embedded\RealView\Drivers\RL-ARM\TCP

It's very possible other individuals in the community have more-optimized versions of these stacks.  I'm curious though - what have you found with regards to the performance of these different stacks compared to the generic Windows driver?

Kevin S.

Applications Engineer

National Instruments

[Chris_Megdanoff]

I have not compared it to the Windows driver, but rather the cRIO.  On a cRIO, you can easily use 80-90% the bandwidth of a 100bt connection - although you use a LOT of CPU to do it.

Running a similar test on the ARM and Blackfin is only getting me <10%.  All I'm doing is a UDP write of a I16 array constant converted to string with no timing restrictions in a while loop.  I have not benchmarked any CPU usage on these yet.

I'm testing on the Blackfin BF537, the MCP2300, and the LM3S8962 eval kits.

Chris 

[David-n-MO]

Chris,

I have a little lm3s8962 application in which I UDP an encoder position to a windows app, using a LABVIEW DLL on the C side and I found the tightest continuous loop was about 50ms. If the updates were longer, like 100ms the loop time would drop to between 10ms and 50ms.  While working with it I stuck a wait() after the UDP send and the loop time dropped dramatically .   Setting the wait to 0 seconds dropped it to about 1-2 ms.  I believe this caused a task rescheduling (it is C) allowing the system to send the UDP without having to wait for the next time slot.  Unfortunately the wait did not work on the dll side.  It still takes 25ms or so to receive the UDP, so the handshaking I hoped to achieve won't work for me.

If anyone could help me improve this it would be much appreciated.  I hope this little nugget will help someone else.

David