LV for ARM UDP read 55 ms wait?

[w0utje]

"It is interesting to note that the wait effects the loop rate, but not on a one-to-one basis. The "superfluous" 55 ms wait reduces UDP read performance by up to 60%."

The wait isn't one-to-one because the wait that is used in RLARM_CCGTcpUdpSupport.c is a WaitNextMultiple(55, NULL); and not a WaitMS.

These functions are the C code variant for the LabVIEW wait vi's (Wait Until Next ms Multiple  and Wait (ms) )

[vitoi]

Aren't the units milliseconds? Regardless of the wait mode, I would expect that at least 55 ms x number of loops of wait/execution would occur.

[w0utje]

I would also expect that, because in my testproject that I've posted here, you see that one UDP_read takes 55 ms.

[vitoi]

The difference is that you are timing one iteration. I am timing 10,000 iterations. 

[w0utje]

yeah I'm timing an iteration of a loop, a single loop takes 55 ms, the next iterations (endless loop) takes also 55 ms. sometimes 52/53 when you send something to the ARM.

[vitoi]

Are you measuring each time as a one shot or in a loop? Also are you sending any UDP data?

[w0utje]

I am measuring each iteration of a loop, and putting this delay on the uart. 

No I am sending nothing. just read UDP (without receiving).

[vitoi]

I did look at your code earlier, but I don't have acess to LabVIEW right now. Can't remember what timeout you used on the UDP read, but I assume it was zero.

How are you measuring each iteration of a loop? Do you have a loop and then record the time it took for each iteration? 

Anyway, the main thing is, if you are continously reading UDP packets on the microcontroller as fast as you can (and you are doing nothing else) the maximum loop rate is 1904 Hz (0.53 ms per iteration), but with the "fix" the maximum loop rate is 4770 Hz (0.21 ms per iteration). Not sure what the effect would be as other load is applied.

[w0utje]

I am measuring only the UDP_read vi. I think you are measuring the UDP_read with the LabVIEW code overhead (while loop etc.)