LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

queue not queueing

I have a producer / consumer architecture - data are being read (from a TCP read) in the producer loop and placed on a queue. The consumer is reading the queue and doing lots of modelling, analysis and display. This architecture was chosen because the data doesn't arrive at a consistent rate from the server - due to network load etc. I am reading 'number of elements on queue' to get a rough idea if there is latency in the system. 

 

The server sends a frame number, which I save using the TDMS format. I recently noticed that when the number of elements on queue increases, the frame number skips, i.e, when data are buffered on the queue, they don't seem to appear when the elements are dequeued.

 

What's going on?!

 

Unfortunately I can't post the code, but I will try and produce a cut down version. 

 

 

0 Kudos
Message 1 of 19
(2,590 Views)

It sounds like you have a race condition somewhere, but without code, it would be difficult to say.  You may also be having issues with out-of-order execution, since the timing of TCP is not guaranteed.

 

Please post what code you can so we can give better feedback.

0 Kudos
Message 2 of 19
(2,584 Views)

@DFGray wrote:

It sounds like you have a race condition somewhere, but without code, it would be difficult to say.  You may also be having issues with out-of-order execution, since the timing of TCP is not guaranteed.

 

Please post what code you can so we can give better feedback.


I would suspect a "lossy" queue myself.

 

Re: TCP

 

The order is guarenteed.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 19
(2,578 Views)

In the process of cutting down the code to make an example, the problem went away - all I've done is replace the TCP read with a random number generator + delay. Will post something later..

 

Thanks

0 Kudos
Message 4 of 19
(2,559 Views)

@grahamwebb wrote:

In the process of cutting down the code to make an example, the problem went away - all I've done is replace the TCP read with a random number generator + delay. Will post something later..

 

Thanks


 

now THAT sounds more like a race condition.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 19
(2,555 Views)

What's your queue size? Do you use a timeout when enqueueing elements?

The queue size should be big enough to keep a few elements that are received over TCP, but of course you have to make sure that your consumer loop can process the data fast enough so the queue does not "overflow".

 

0 Kudos
Message 6 of 19
(2,554 Views)

The queue size is default (unlimited).

 

The queue builds up when the PCs processing load goes up - when an email arrives etc. You can see this by reducing the delay time right down to 1ms and click "real-time operation" then do something else with the PC - shake the vi window around the desktop for example. The queue should build up, unless you've got a good PC!

 

The problem I have with my real program is that data being queued are lost.

 

Other difference with my real program - data are coming from a TCP read function, there is no delay in the producer, the data are text not numerical, and the consumer is huge. I'm not sure how to set a sensible timeout. There's also no handshaking with the server.  

 

G

 

0 Kudos
Message 7 of 19
(2,549 Views)

doh!

 

Here it is  ..

0 Kudos
Message 8 of 19
(2,548 Views)

What's with the pre-allocation and intialisation part?  It looks like you're just stuffing and flushing the queue 999999 times.  A single flush queue should be sufficient.

0 Kudos
Message 9 of 19
(2,539 Views)

Also, I didn't see any data loss while running your example.

 

You probably want to create a mechanism that stops your consumer loop when your producer loops stops though.

0 Kudos
Message 10 of 19
(2,535 Views)