Timing less than 1 ms/loop iteration needed

[nullhost]

Hello everyone. I ran into a pretty nice timing frequency problem. A short description of what I'm working on: I've created a "bidirectional sofware router" which sends UDP-datagrams from our common TCP/IP network to AFDX (Avionics Full DupleX) network and back as well. When running the "router", 2 types of Reentrant VI clones are being executed: WRITE PROCESS VI - for parsing the incoming UDP-datagrams and forwarding the payload to AFDX network specific channels; READ PROCESS VI is for redirecting AFDX datagrams back to our common network. Each of 8 Read-VI clones enqueue the received data into the named FIFO (see 1st screenshot). Then it's being dequeued in the main loop (see 2nd screenshot) and the data is being written into the UDP-channel.

If you have a look at the Dequeue Element function - the timeout value is set to its minimal value of 1 ms. And it seems 1 ms is not enough: the quantity of elements in the queue is growing. The problem is that less timing (i.e. 0.9 ms - it would be enough) is impossible as well as setting the value to -1 (the loop will consume all CPU resources)... I see no other way than creating an additional parallel loop, one more queue and one more udp-connection to distribute the load... That's weird anyway! And what do you think? I'll appreciate any advice. Thank you!

[paul.r]

If your queue size is growing its because you arent dequeueing messages fast enough - this has nothing to do with the queue timeout. The dequeue timeout is only relevant if there is nothing on the queue - it defines how long the dequeue node will sit and wait if there is nothing on the queue - if there are messages in the queue, the timeout doesnt come into play at all.  

Whats in the false case of that case structure? Also the value property node is slow - orders of magnitude slower than using a local variable (at least for writing, reading may not be as slow). So there is one small performance increase you could make. 

[aputman]

Setting Dequeue to -1 will not cause it to hog the CPU.  That just means it will sit there and wait forever for another message. 

[Yamaeda]

The value property node could very well take >1ms as it requires a switch to the UI thread, also, do you really need to check that every time? Could you move it outside of the loop or place it in a First call Case with a feedback node? Sending the data shouldn't take >1ms, but you can set up a timer to make sure that's not the issue.

/Y

[Bob_Schor]

It is very frustrating to look at a static picture of non-working code -- we can't look at "other case elements", can't see "outside the window provided", can't get "help" if there's a function we don't quite recognize.  The only virtue comes when there are "foreign functions" (like your AFDX function), where we at least can see the Function's Icon (whoo-hoo).

Bob "Curmudgeon" Schor

[crossrulz]

As already stated, property nodes are SLOW.  And I am talking thousands of times slower than reading/writing from/to a terminal or even a local variable.  First thing I would do is get rid of those.  For some things, like the UDP settings, you could use a shift register to hold the values (most efficient method).

The Dequeue's timeout is just how long it waits for data to come in.  If data is already there, no wait is performed.  If no data is there, it actually sleeps (no CPU usage) until data comes in, up to the timeout value.

[CFER_STS]

Is this a Windows VI?  Windows only provides access to a 1 kHz clock, giving you 1 ms timing resolution on your timing functions.  If your require more precise timing, you might need a real-time hardware target which can support higher frequency clocks than are supported by your desktop PC.

That said, others have already pointed out what the timeout value on a Dequeue function actually does (i.e. not what you think).  If you can't meet your timing requirements, you need to optimize your code to improve its execution speed, or simply implement synchronization at a slower overall rate.  Consider buffering in your queue (i.e. Enqueue writes a single point each iteration, but Dequeue, which executes at a slower frequency, reads multiple points from the buffer), and possibly implementing some handshaking so that you handle buffer overruns and underruns (the purpose of a -1 timeout on Dequeue).

You can look into using timed loops for more precise execution timing / synchronization, but you're still limited by the 1 kHz clock unless you have an appropriate hardware target.