queue not queueing

[grahamwebb]

I read on the forum somewhere that by allocating memory like this, it speeds things up.

[RavensFan]

Shoud your subject title actually be "queue not DEqueueing"?

If I set your msec to wait to be 0, then I see the queue rapidly build up.  But that makes sense because you are running the producer loop at pretty much top speed.

If I set it to 1 msec like you said, and do something like maxmize the window, then I do see a jump in the queue size that quickly goes away.

What is happening is that certain UI events (scroll wheel, window resize) are causing the UI to pause while the operating system handles those events, that causes your consumer loop to temporarily slow down because it can't send data to the screen for updates as quickly.

Are you sure you are actually losing data when this happens?  How do you know?

[grahamwebb]

The server sends me a frame number which I save using the TDMS file format. When there is a delay / queue build up, there is a jump in the frame number - the frame numbers aren't saved.

[RavensFan]

I don't see any reason why that should happen.

What if you save the frame number to a plain text file instead of TDMS.  Is it still missing frames?

[grahamwebb]

Yes, it still happens. This has some of the TDMS code added.

I'll try saving the data within the producer, to rule out the queueing and see if it's a TCP read error. What are the rules for setting the TCP timeout?

[RavensFan]

It seems to be saving all the data in the code you just posted.

[grahamwebb]

Yes, I'm pretty sure it's a TCP read timeout issue now. I get error 56 pretty much all the time. Tweeking the timeout value stops the frame number glitch. So .. what's going on? The producer is dropping data packets, presumably because the processor is occupied with UI refresh, and the timeout gives more time to the TCP read? I'm guessing now ..  

[dan_u]

What value are you using as TCP timeout? And at what rate are you expecting the data over TCP?

It's quite common in TCP based code to have a small VI "NO TO", meaning "no timeout", that removes the timeout error from the error cluster. This error is expected in some cases since we want the loop to spin but the data might not be transmitted at the expected rate. You'll find the "NO TO" vi e.g. in the FTP VIs, I don't remember if it's on the palette.

On another note, TCP uses an algorithm (Nagle algorithm) to avoid sending many tiny packages over the network.

[grahamwebb]

Thanks dan_u. I have disabled nagling and cleared error 56. Data is being sent at approx. 120Hz, however I've fiddled with the timeout value and found 5ms works best, strange. .. I think I need to read more about TCP data transfer!