UDP processing speed issue

[willzhou]

Hi, everyone,

    I've been working on an embedded Ethernet communication project recently. The host is DSP28335 and we plan to use Labview to receive the data. The UDP function is OK at present. However, Labview seems to be too slow in data processing. One example is that: an Ethernet frame with payload of 402bytes data is sent every 100us(approximately 37Mb/s) for 2000 times, Wireshark is able to capture almost all of the 2000 frames. However, Labview is only able to receive 550 frames. I wonder whether it is my computer hardware issue or my Labview code issue?

   I've attached the Labview vi been used. Hopefully someone can give me some advice.

   Thank you !!!

[altenbach]

Hard to tell what speed LabVIEW can do here, but wireshark is probably not a fair comparison because it can tap into the information very early.

You probably can reduce the code overhead by eliminating the local variable and numeric control. Just increment an initialized shift register in the loop and display the count after the loop has finished.

You are currently not doing much procseeing at all.  What kind of processing have you planned? You probalby want to process the data in a consumer loop, e.g. using a queue.

[willzhou]

Hi, sir,

The local variable here is for frame counting. I am new to Labview, so I probably do not have a better solution.

What I plan to is that I am going to decode the payload data into U16 form, like in the new attchment. I think the processing made here will make the receiving rate even worse.

[PhillipBrooks]

You can simplify your string to U16 conversion and drastically improve it's performance.

Typecast the entire received string directly to an array of U16.

[altenbach]

Also, since you know the number of messages and their fixed lenght (once cast to U16), you can preallocate it as a 2D array where you can just replace each row with real data as it arrives. Very memory efficient.

[altenbach]

For comparison, see if this is a little bit faster. (Avoiding local variables and indicator/control updates. Only polling the stop button)

No guarantees.... 😉