occasionally slow acquisition

[BlueAnaconda]

Hello,

I developed an application labview, an infinite loop that performs a read data via Ethernet, put the content in a specific format and saves it in a oracle DB.

Time of this loop varies between 90 ms and 300 ms.

The weird thing which happens every 30 seconds or so, is that the time of this loop becomes equal to 6 sec 9 sec and back again quickly to the normal rate.

I was wondering how do I know the reason?!
I disabled the firewall, antivirus, but nothing!

I even changed the architecture of the local Ethernet network, with a single cable between the Ethernet controller NI and my PC, but it changes nothing.

So .. how can I trace what happens and conclude the problem please? I have doubts about the BD (can be occupied by calculations) or Windows Server 2008 service that triggers every 30 seconds maybe?

If someone can guide me

Thank you in advance,

[ramses64]

Hi,

if I were you, I would pu some spy in my code to seek which part take more time than it should : try to measure the time duration of DB insertion, time of reading... etc.

Best regards,

[BlueAnaconda]

Hi ramses,

Soory for this late to answer you.

In fact, I did exactely what you said. I measured each function timing. And I found that the INSERT_TO_DB function is in late each time the hole process take a lot of time.

I verified this with the DB expert, and I found that he was doing many operations after each 30 sec. So the DB wasn't responding and it was the slowness problem !

Thank you !

[johnsold · Accepted solution]

Blue_Strike,

This sounds like a perfect situtation for a Producer/Consumer architecture. The Producer loop runs at the ~90 ms rate and acquires the data from the Ethernet connection. It places the data into a queue.  The Consumer loop reads the queue and writes the data to the DB. This loop can run more slowly than the Producer without loss of data (so long as the queue does not overflow).  For this to succeed you may need to write multiple data sets to the DB at one time so that the Consumer loop can "catch up" after the DB has been napping.

Inifintie loops are generally not a good idea. Include a Stop button or some criteria based on the data which will cause the program to stop.  When a Stop command occurs, close the Ethernet connection, write an accumulated data to the DB, close the DB connection, and then stop the program.  If you stop the program using the Abort button, you cannot do any of those orderly shutdown processes.

Lynn

[BlueAnaconda]

Hi Johnsold,

Yes I agree with you about the Producer/Consumer architecture. I'm developing that and I will see if I can solve this problem definitely.

Regards,