Execution Time Issue

[thutch79]

---

@Yamaeda wrote:

---

@thutch79 wrote:

However, if this were indeed a disk write time issue, wouldn't that show up in loop times? (C) Those have all been 0's across the board when this occurs. If I had seen the time show up in "C", I wouldn't still be looking for the source. At one point, I also put timing directly around the "write text to disk" call and again found no time lost there. I've always suspected a disk write timing issue, but I haven't been able to produce the timing data that shows it. I'm afraid if I do all the work to move the disk writes out into their own queue, it won't do any good.

---

It's not possible/realistic to have 0ms as write time, either it's an error in causing no writing or it's cached, in which case the several hundered ms is realistic when it finally writes.

But yes, you should see times != 0 in the list.

/Y

---

Thank you for actually reading through my posts. I feel like everyone else is just skimming. To clarify for the others, no I'm not trying to write every ms. The write is occurring every 200ms. This is already in a producer/consumer setup. I am already having buffer overflow issues. My frustration is why I can't pinpoint the executions that take too long.

I believe the idea of moving the disk write to another queue is good. However, I would really like to confirm that what you are suggesting is actually happening. I would expect that I would see small write times when I wrap a timing test around the "write text to disk" node. When the long execution of the VI in question occurs, I would expect to see one (or more) of the exectution times of that node to explain the long execution of the overall VI. Am I wrong in my thinking? So far I haven't been able to see that behavior.

[Yamaeda]

For test, you can add Flush file after your write, and it should write the buffer each time. Maybe it'll even work better in total.

/Y

[johnsold]

I have been looking at your code. In the Write Basic Run Data.vi you call Write to Text File every iteration of the loop. Since no data was stored with the VI, I cannot tell how many elements are in the arrays but it appears that they may be small.  It also appears that the strings you write are on the order of tens to a few hundreds of characters in length.  The timing of that loop is set by the time it takes for the code inside to run. There are no Waits or delays in the loop. Most likely the slowest function there is the Write to Text File. The OS may buffer those small strings and only actually write to the file after it has accumulated several kilobytes of data. If this is happening the Write to Text File may only take microseconds to execute. This would account for your zeros in the Loop Times.  As someone suggested earlier adding a Flush File function will force the OS to actually write to the file.

Of course that still does not address your original question.

I noticed that on some of the wires going to your timing cluster indicator the tunnels are set to Use Default if Unwired. For the numerics that will produce zeros.  Suppose you put some unlikely but non-zero value (such as 99999) in the other cases. That would provide an easy indication that the code was following an unexpected path.

Lynn

[thutch79]

Thank you. Good suggestions. I'm building the app again this morning, so I'll try at least fine tuning the timing checks with some non-zero numbers. I'd feel so much better if I could see the text file write times explain the missing time. I don't want to jump to the file flush until I get a chance to check it out.

[thutch79]

Ok...I placed a timing check directly around the disk write (see attached). When it's running, I occasionally see an overall VI execution time on the order of hundreds of ms's and I see 0's in each of the eight instances of the disk write (the array size feeding the FOR loop is 8). I also did as suggested and fed 999 for the case when the write doesn't happen to be sure I'm not getting fooled by the "use default when unwired" tunnel.

Is there any chance this is something to do with the disk write? I just don't see how it would be when the execution of that node is 0 when the VI takes hundreds of ms's. Any idea where else this time could be coming from?

[Nick-A]

It is very hard to say what else is going on in a timing app like this when it is running in Windows.  There is plenty that could be happening behind the scenes that is hogging the CPU.  Your best bet is to try to take a time of every part of the system and compare it to the total time.

I believe that Yamaeda has a good point in testing with Flush just to see if that is why your Write is taking 0ms to run.