LabVIEW
Enqueue Timed out no error - ideas?
Solved!
@JÞB wrote:
After a bit more pondering....
HOLD IT! you are enqueueing with a 1msec tmo. Let's just ask ourselves the silly question "How long does it take to increment the 1msec clock by 1?" The hardware itself clicks along nicely a 1msec and then the OS calls into the kernel driver to see if the hardware counter incremented so, 0 < Cntr++ <= 1msec. So, tmo occurs at the variable latency of cntr++ from enqueue call start.
Allign the call start with a short increment and a memory allocation...AND BINGO! you get yourself a hard to replicate enqueue timeout.
The 8-Ball is working! Pass the kudos!
Are you saying here that if I put the timeout at zero, it will occur more frequently and it needs to be at >1 then .
(I wonder if thats why I put the timeout is 1 not zero, to reduce this timeout error and I haven't commented it?)🤔
the VI is classed as Time critical and the loop actual contents are :
I have no control over the data packet termination, and as its more commonly the sender queue that gets full (rechecked the messages - its a limited queue size on the sender, that defines the buffer. ) if this loop runs too slowly I need the enqueue timeout as small as possible.
Someone else wrote the code originally (I added the timeout) and I've already stripped a string subset function to remove the TCP header and put it in the dequeue loop function (unless that's possibly giving me a performance hit.)
Not sure how using a DVR here works better as I would get a race between Write/EnQ and Read/DeQ?
DeQ turns the string into the required dataset.
Kudos when I'm sure I understand the last post Jay 😉
James
@James_W wrote:
As an aside, the source device strikes me as ill-designed when it has a 19+ MB/sec stream rate, a mere 500 byte buffer, and a hard crash when the buffer fills.
-Kevin P
I might have got my numbers wrong, don't know.😉
- They certainly look bad, which makes me think I've got them wrong.
Having a look at tow to implement Wiebe's idea at the moment. (Having trouble reproducing the problem, The last test failed to read the TCP port fast enough in the producer loop😣)
James
A good old circular would also do the trick.
The circular buffer can be either a by wire (data in a cluster or class), FGV (that won't scale up well) or DVR. But if the input is correct, there's no reason a queue wouldn't work.
A benefit of a DIY buffer is you can probe it's internals.
Of course you could make a base buffer class, with a queue child, a DVR circular buffer child and a FGV buffer child. Then you can switch implementations, even at run time (not during a test of course). 😊
EDIT: Come to think of it, if you want to fill a buffer, the buffer doesn't need to be circular. A simple array (plain, in a class, cluster, FGV or DRV) would work.
Search LabVIEW like a graph! Can't post the DeQ code - it goes towards the core of company IP as I start splitting up the datastream there.
If DeQ lags and queue gets full, design is that EnQ should terminate (FAST), flush the queue and close the TCP connection.
Queue holds a buffer of 5 mins of data - at 200MB/s this would be a 60GB buffer, at 180MB/s this is 54GB. (This is more than most PCs have fitted as standard and comes close to the limit of a server grade machine standard setup) - so you are quite right with your earlier statement of big data and it being a memory allocation delay. I can't afford for the raw data to be split and for processing sent to multiple modules with their own memory spaces for different mathematical operations with this sort of data set size.
DeQ speed is limited by processing modules pulling data out (it enqueues to another queue with a queue size of 5 for processing).
I'm currently looking to see if the timeout might be caused by running out of physical memory on the PC, and therefore causing slightly more delay at the EnQ step - I'm not sure if this is the issue as the data rate was low when this was reported, and I'm now stressing it at higher rates to try and induce performance related issues faster.
I've tried compiling with the name removed but not noticed any difference in performance. I pulled the EnQ back out of a subVI and it started spinning slightly faster (don't know why - I think I'm reaching threading limits).
This program is the most intensive program I've ever come across and pushes the boundaries of what a multicore machine can do in real time (and it needs a slightly better architecture - but where to optimise without breaking is difficult). You couldn't write this in anything other than LabVIEW though 😁
Basic setup of obtain queue above (doesn't matter if named)
James
@James_W wrote:
Queue holds a buffer of 5 mins of data - at 200MB/s this would be a 60GB buffer,
Yes, if you enqueue bytes.
If you enqueue strings, it's an 8 bytes pointer + a minimum string size word of 2 bytes per element.
So it's 60GX10 = 600 GB.
For all empty strings.
This might become a problem while filling the queue... A timeout might be the result.
