can timed loop clock be WRONG?

[Enrico_Segre]

I'm running into a weird behavior, which I think is either a bug of labview, or could otherwise give me hints for debugging an apparent bus arbitrage bottleneck.

I have a simple program in which I'm monitoring the "actual start" output of the left data node of a timed loop. In my understanding, no matter what the delays in the execution of each iteration of the loop, this node should incrementally provide a readout bound to the system clock. Instead, there are particular circumstances where I see it slowing down. Not just jittering, really running slow, even twice slower (and counting) than what it should. I mean, the "elapsed time" indicator circled in the diagram below, reads HALF of the elapsed world time, and cumulating iteration after iteration.

The configuration of the timed loop is:

 

Is there an explanation for this?  I suspect something is happening at the motherboard level here.

I attach the VI which evidences the problem for me. It is a simple snippet for testing the performance of a very high speed hard disk streaming system we're building. There are specific settings of the RAID controller which cause that, repeatably. It looks as if problematic settings (namely, a writetrough vs a writeback policy setting) switch the behavior of the "actual start" timer from normal to slow. Even placing the controller card in one or another PCIe slot causes the behavior. Obviously the weird behavior is a nuisance because it forges the measurement of the write-to-disc rate, measured as bytes/time.

Platform is LV 8.6.1 on XP32sp3 on a Tyan Tempest 5400 motherboard, with an LSI raid controller. I'm already familiar with quite a number of resources on the NI site concerning high speed streaming, btw.

Thanks, Enrico

[Enrico_Segre]

>I'm already familiar with quite a number of resources on the NI site concerning high speed streaming, btw.

Including for instance:

http://zone.ni.com/wv/app/doc/p/id/wv-803

http://zone.ni.com/devzone/cda/epd/p/id/5348

http://zone.ni.com/devzone/cda/tut/p/id/6355

http://zone.ni.com/devzone/cda/tut/p/id/2909

http://zone.ni.com/devzone/cda/tut/p/id/7677

http://forums.ni.com/ni/board/message?board.id=200&message.id=18641&requireLogin=False

the unbuffered windows opening of the file used in my VI comes from http://forums.ni.com/ni/attachments/ni/200/19729/1/streaming.zip, occurring in the last thread.

Enrico

[Jörn]

In the set-up you have checked discard missed periods. As far as I know this won't catch up if the loop is late on the next timing point. If the loop will miss on timing point it will wait for the next. That can mean that it runs with half speed.

Unchecked "dicard missed periods" and the loop will try to catch up if one loop run takes more computational time than the desired loop time.  

But If the needed processing time in the loop is always larger than the intended loop time the loop can never catch up missed timing points.

Jörn

[Enrico_Segre]

Thanks for the attempt, Jörn, but that can't be the explanation. My timed loop is scheduled once per second, and all it does is to check the value of the local "writie iteration" and of the node "actual start", making a total of 9 floating operations and displaying three numbers, besides the stop button and the shift register. Very, very, very, very unlikely to run late systematically, on an 8 cpu machine.

[JÞB]

Actually,  the timed loop isn't the problem- it should be able to do the process IF the CPU's resources aren't being hogged by say... a LV While loop that doesn't have a wait until next mS multiple in it...... 😉 

Add the metromone delay to your while loop- and mark the solution please 

[Enrico_Segre]

Jeff, you're missing completely my point.

I WANT to hog the while loop - and I'm complaining that "actual start" reads WRONG in such case.

As a mattel of fact, the while loop is NOT hogging the cpu (checked), but rather the I/O (and so it should, that IS a test of the IO troughput). Or if not the IO, it is keeping on hold some internal bus arbitrer (PCI express, core node, bridges, who knows). Knowing how the read of the "actual start" tick is implemented internally may give some hint about a) why we have something which looks so much like a LV bug, b) what is the deadlock in this memory-to-RAID write.

I turned my question the general LV forum, since I don't see any more specific place. But getting newbie dismissals to a carefully documented question puts me a little off.

Thanks, Enrico

[Jörn]

You have two while loops! The lower one is really busy writing data to a file, isn't it?

The upper loop is only calculating the data rate - did I get it right? So it doesn't matter if its on time. I would reduce the cycle time of the upper loop to get more often the chance to compute the data rate. Placing a wait in the lower loop helps as well but affects data rate.

[Enrico_Segre]

I hate I have to say that, but that is again an useless answer.

Of course the lower loop is busy all the time. That is the purpose. As a matter of fact, one of its iterations takes typically ~15ms (writing 6400kB at a rate of ~400MB/s).

I wouldn't care much if the upper loop is on time or not. What I'm saying is that I observe that the readout of the "actual start" node, whenever that is read, is WRONG. The tick number read, incrementally, is LATE with respect to world time.

For the sake of exemplification (not real data), this is what I'm claiming is happening, under some circumstances:

iteration	world time, ms	"actual start"
1	0	0
2	1000	500
3	2000	1000
4	3000	1500

At least, that is what I see when I look at the progression of "Elapsed time", which is nothing but "actual start"/1000. Comparing the indicator with a stopwatch shows me that the former is running at half of the speed.

I am not by the system now, but could try in the next days to collect more accurate statistics.

Enrico

[JÞB]

---

Enrico Segre wrote:

Jeff, you're missing completely my point.

I WANT to hog the while loop - and I'm complaining that "actual start" reads WRONG in such case.

As a mattel of fact, the while loop is NOT hogging the cpu (checked),

--- editJB Really, you found a way to limit a while loop without a timer? show us all how!---

but rather the I/O (and so it should, that IS a test of the IO troughput). Or if not the IO, it is keeping on hold some internal bus arbitrer (PCI express, core node, bridges, who knows). Knowing how the read of the "actual start" tick is implemented internally may give some hint about a) why we have something which looks so much like a LV bug, b) what is the deadlock in this memory-to-RAID write.

I turned my question the general LV forum, since I don't see any more specific place. But getting newbie dismissals to a carefully documented question puts me a little off. 

--- Edit JB Re "NEWBIE dismissals?" OK have a good one!----

Thanks, Enrico

---

[JÞB]

---

Enrico Segre wrote:

I hate I have to say that, but that is again an useless answer.

Of course the lower loop is busy all the time. That is the purpose. As a matter of fact, one of its iterations takes typically ~15ms (writing 6400kB at a rate of ~400MB/s).

I wouldn't care much if the upper loop is on time or not. What I'm saying is that I observe that the readout of the "actual start" node, whenever that is read, is WRONG. The tick number read, incrementally, is LATE with respect to world time.

For the sake of exemplification (not real data), this is what I'm claiming is happening, under some circumstances:

At least, that is what I see when I look at the progression of "Elapsed time", which is nothing but "actual start"/1000. Comparing the indicator with a stopwatch shows me that the former is running at half of the speed.

I am not by the system now, but could try in the next days to collect more accurate statistics.

Enrico

---

so why is that the timed loop?