LV for ARM UDP read 55 ms wait?

[w0utje]

Hi there,

I've been developing labview for ARM for a while now, I have experience in targeting other microcontrollers for labview for ARM.

At this moment I'm testing the UDP functions of LabVIEW to communicate.

I saw that the UDP read function, which I give a timeout of 0 ms, always has a duration of 55 ms.

this is strange because you can see in the C code of RLARM_CCGTcpUdpSupport.c and RLARM_TCPWrapper.c that is checks for a variable pSockBuf->rxBufCnt which is set by the callback function when some data is sent.

I saw in the code that the functions is always waiting 55 ms! 

WaitNextMultiple(55, NULL);

my question: why is this? i've set it for myself to a wait of 1 ms and it is working also, my delay is gone!

this is code that NI provided with LabVIEW for ARM.

I am using LV for ARM 2010, but it is the same in 2009

Greetings,

Wouter

[Alex.T]

Hi Wouter,

I would imagine that since UDP is a broadcasting mechanism for networks, introducing a delay into the function would prevent users from flooding the network. An accidental code modification to your code would cause some big problems quickly with some rigorous firewall installations if UDP data was allowed to broadcast too quickly.

[w0utje]

Hi Alex,

That could be, but the provided code by LabVIEW does only a wait when you're reading a UDP socket (you're sending nothing)

So you can't flood it here.

When writing to a UDP socket, there is no wait!

I also see the 55 ms wait (why 55?) in the bluetooth and IRDA support.

Wouter

[ninlmartijn]

Dear Wouter,

I found this forum post which hopefully gives you some insight what is happening.

Best regards,

[vitoi]

Unfortunately the referenced post did not solve the problem.

w0utje, you changed to wait from 55 ms to 1 ms. Why not 0 ms? Did you try 0 ms?

I'm wondering if the author of the C code put in a 55 ms wait for some reason such as debugging, but forgot to put it back to something faster.

[w0utje]

the 1 ms wait was just a first try what worked. maybe the wait can be commented..

i've searched the labview c code for more 55 ms waits like this. it's also in the bluetooth, IRDA and lvphonesupport?? 

so I think it's a "standard LabVIEW c code procedure"

but my opinion is that it can be deleted from the code because it's creating a delay in all the applications 😛

[vitoi]

I'm very interested in hearing the reason for the 55 ms wait. Perhaps under certain circumstances the wait is necessary. However, putting it in universally is a killer. The maximum read loop rate would be 18 Hz!

NI, does someone know why the 55 ms wait is there?

I'm currently evaluating LabVIEW Embedded for ARM. Although it is easy to use, performance has been an issue. For example, with the LM3S8962 Evaluation Board the TCP example runs at a maximum rate of 34 Hz (see http://forums.ni.com/t5/LabVIEW-Embedded/Can-LabVIEW-Embedded-for-ARM-work-with-any-board-or-just-wi... I wonder if what you are seeing and what I'm seeing are related?

[Alex.T]

Hi Guys,

I've been out of the office for the past couple of weeks and I'm sorry that no one has been able to get back in touch with you during this time.

Q: So, why the 55ms wait?

A: I believe that this may be due to Nagle's Theorem, or more specifically, the associated ACK delay. Nagle's Theorem is used to concatenate packets of data to improve the efficiency of data transmission across a network. An attribute of the Transmission Control Protocol, the delayed ACKnowledgement response, ensures that a read will not occur until the seond write of data can be confirmed, at approximately a 500ms interval. This explains how depending on the size of data you're transmitting (Hence dependant on the application) we can choose whether or not to eliminate this delay. The wait we're exhibiting in this code may be an embedded equivalent, as I have read that the uVision TCP Stack that this implementation is based on does make use of this method of compensating for network congestion.

Kind Regards,

[vitoi]

What a disaster! A 55 ms wait for any TCP/IP or UDP reads! This limits streaming data to LabVIEW embedded to a maximum rate of 18 Hz.

At the very least the delay should be user configurable. Include any required caveats documentation if necessary. Latency is a big issue with the sort of application LabVIEW is used for.

If my understanding is correct, UDP does not use acknowledgements. If so, Nagle's algorithm is not applicable and the UDP read delay can be removed.

In some LabVIEW applications there is a dedicated Ethernet link and/or Nagle's algorithm is disabled. So, the delay is just limiting performance.

Also, for maximum performance, LabVIEW Embedded requires a single loop algorithm (and appropriate compiler options). Using multiple loops uses up 75% of CPU power. Single loop operation requires all VIs to return control ASAP.

(The biggest/only problem with LabVIEW Embedded is performance. Things like this don't help.)

Can anyone give me some guidance on how to change the C code delay to zero and recompile so it's available?

Longer term, can NI, disable or make the delay an option?

[w0utje]

for now:

in RLARM_CCGTcpUdpSupport.c row 745,

WaitNextMultiple(55, NULL);

you can comment out this, or change the 55 to anything you like.

you can find RLARM_CCGTcpUdpSupport.c when you build an application in LabVIEW and after that use Tools >> ARM >> open Keil.

you'll find the file under system drivers.

you can find it also in the map <labview>\Targets\Keil\Embedded\RealView\Drivers\RL-ARM\TCP\RLARM_CCGTcpUdpSupport.c

make sure you make a backup because this is a file that comes with LabVIEW for ARM, and it is used by all the targets (lm3s8962, lpc2378,lpc2468)

to the 55 ms wait, Why build this in non changable labview C code?, if you can add a delay if you want it to in your LabVIEW application.

OK, for TCP the Nagle's algorithm can be the cause why this is done, so why is the exact same delay (copy-pasted) in bluetooth, lvPhone and IRDA drivers????????

Wouter