max frequency of a loop cycle

[souske]

Hi

I was trying to determine at what maximum frequency I can run my for loop.

To do that I set the "wait until next ms multiple" to some value and then calculated

the time it actually took the loop to execute and then compared them.

If they mached I assumed that the loop executed all comands inside without a problem.

I went from 6 ms to 1 ms and I got sth like this:

wait node time [ms] - calculated time [ms]

6 - 6.00

5 - 5.00

4 - 4.00

3 - 3.00

2 - 4.00

1 - 3.00

I suppose I can safely assume that 3ms is the minimal value I can use here.

Question 1. What exactly happens at 2ms that it takes 4ms to execute the code?

I suppose there is not enough time so some additional functions are being executed?

Question 2. Are there any other methods for determining how fast one cycle can be executed?

--

regards

souske

[Ton Plomp]

QUOTE(souske @ Feb 19 2008, 12:39 PM)

Question 1. What exactly happens at 2ms that it takes 4ms to execute the code?

I suppose there is not enough time so some additional functions are being executed?

Question 2. Are there any other methods for determining how fast one cycle can be executed?

1: The wait on next MS node is a synchronization node. It will start every x ms. So if your code takes 3 ms, and x is 2 it will every loop wait 1 ms.

2: Run the loop a specified number of times and do a time substraction and division.

Ton

[crelf]

QUOTE(souske @ Feb 19 2008, 06:39 AM)

I suppose I can safely assume that 3ms is the minimal value I can use here.

That's not a safe assumption - it depends on what else your PC is doing. What OS are you using? If you really want determinism, you should look at an RTOS. Read more here and here.

[BobHamburger]

QUOTE(crelf @ Feb 19 2008, 08:30 AM)

That's not a safe assumption - it depends on what else your PC is doing. What OS are you using? If you really want determinism, you should look at an RTOS. Read more here and here.

I concur with what Chris is saying here. If you're running on a Windows machine, the rule of thumb is that you can't reliably get loops to run any faster than around 30 mSec. 50 or even 100 mSec are safer bets. Windows just has an annoying and unpredictable habit of randomly going off to service something that it feels is a priority at any given time. I've heard of people who have shut off virtually every automatic service that Windows has running as background tasks, in order to improve reliability and determinism of loops, but by doing that you're also limiting the things that the platform is capable of doing. If you need speed and/or determinism, go to an RTOS.

[eaolson]

QUOTE(BobHamburger @ Feb 19 2008, 12:01 PM)

I concur with what Chris is saying here. If you're running on a Windows machine, the rule of thumb is that you can't reliably get loops to run any faster than around 30 mSec.

I have to disagree with this. Running just a quick check, I can get an empty For loop to run at 5-7 nanoseconds, with occasional excursions to about 20 ns.

[Yair]

The CPU can definitely process code at a very high speed, but it is correct that you can't get guranteed (deterministic) results, for one simple reason - Windows is not a real-time OS and as such can correctly decide that it wants to do something which is more important than what LabVIEW is doing. If that other thing takes all of the CPU, your computations will be delayed by an unknown period of time.

[crelf]

QUOTE(BobHamburger @ Feb 19 2008, 01:01 PM)

If you're running on a Windows machine, the rule of thumb is that you can't reliably get loops to run any faster than around 30 mSec.

QUOTE(eaolson @ Feb 19 2008, 02:08 PM)

I have to disagree with this. Running just a quick check, I can get an empty For loop to run at 5-7

nano

seconds, with occasional excursions to about 20 ns.

I think Bob's point was the word "reliably" (emphasis added above), which I understood to be the original poster's assumption.QUOTE(Yen @ Feb 19 2008, 02:21 PM)

Windows is not a real-time OS and as such can correctly decide that it wants to do something which is more important than what LabVIEW is doing.

:thumbup:

[souske]

Well then I deeply apologize for not specyfying that all those tests are executed on QNX RTOS

How do my assumptions and results look like now ?

[crelf]

QUOTE(souske @ Feb 19 2008, 04:53 PM)

Well then I deeply apologize for not specyfying that all those tests are executed on QNX RTOS How do my assumptions and results look like now ?

Ahhhhh - now that's a whole new ball game! Your assumptions now look much more solid!

[jdunham]

QUOTE(eaolson @ Feb 19 2008, 11:08 AM)

I have to disagree with this. Running just a quick check, I can get an empty For loop to run at 5-7 nanoseconds, with occasional excursions to about 20 ns.

Sorry, your code isn't accurate. Your graph reads in milliseconds, and you are assuming that your 20ms excursion is divided evenly among all 1,000,000 iterations of your empty FOR loop. It's much more likely that just a few of those iterations are taking the a large part of the excursion.

I ran the code anway, and I found excursions between 200-350 ms when I opened up Excel, Word, or Acrobat Reader. So if you can keep any of your users from ever running other applications then you are more likely to get deterministic performance.

If there isn't risk of human life or limb, you can still try to run a quasi-real-time acquisition and control loop, and it will work pretty often.

OK, I see that the original question referred to QNX.

Note that if you use an NI-DAQ board, you can get more accurate timing with a Timed While loop

[eaolson]

QUOTE(jdunham @ Feb 19 2008, 04:14 PM)

Sorry, your code isn't accurate. Your graph reads in milliseconds, and you are assuming that your 20ms excursion is divided evenly among all 1,000,000 iterations of your empty FOR loop. It's much more likely that just a few of those iterations are taking the a large part of the excursion.

OK, that's a valid point. But because the ms timer is limited in resolution to 1 ms, I had to do a bunch of iterations and average. And this is for an empty loop. Since that's boring and you'll want to do something inside the loop, that will slow it down considerably.

And since the OP was talking about QNX, this is all probably a moot point.

[souske]

QUOTE(eaolson @ Feb 19 2008, 11:27 PM)

OK, that's a valid point. But because the ms timer is limited in resolution to 1 ms, I had to do a bunch of iterations and average. And this is for an empty loop. Since that's boring and you'll want to do something inside the loop, that will slow it down considerably.

And since the OP was talking about QNX, this is all probably a moot point.

Well maybe not so moot

Eventhough its QNX, when I run a loop similar to yours (without wait until next ms multiple) I get average execution time around 0.5ms. Which as you can see is not

useful information if I want to set the frequency for the loop. And the puzzling fact is that when I checked exactly what the times of specific cycles are, they ranged

from 0 to 3 ms. So it looks like in reality you actually take the largest value instead of an average.

[crelf]

QUOTE(souske @ Feb 19 2008, 06:29 PM)

So it looks like in reality you actually take the largest value instead of an average.

...and add some arbitrary time in case your OS encounters something during it's run that it didn't during your testing

[Yair]

I'm not sure if you noticed Ton's original reply, but Wait Until Next MS Multiple is the wrong choice - it WILL wait until the next multiple, so if your code finished at xxxx36.001, it will wait an extra 2 ms until it will get to xxxx38. A better timing structure is the timed loop, but I'm not sure if it's available on the QNX.

Another alternative is to place a 0 ms wait. This should tell the OS to run this as fast as possible if nothing else needs the CPU. Additionally, playing with the VI priorities might get you better results.

[crelf]

QUOTE(Yen @ Feb 20 2008, 01:35 PM)

Another alternative is to place a 0 ms wait. This should tell the OS to run this as fast as possible if nothing else needs the CPU.

:thumbup:

[souske]

QUOTE(Yen @ Feb 20 2008, 07:35 PM)

I'm not sure if you noticed Ton's original reply, but Wait Until Next MS Multiple is the wrong choice - it WILL wait until the next multiple, so if your code finished at xxxx36.001, it will wait an extra 2 ms until it will get to xxxx38. A better timing structure is the timed loop, but I'm not sure if it's available on the QNX.

Another alternative is to place a 0 ms wait. This should tell the OS to run this as fast as possible if nothing else needs the CPU. Additionally, playing with the VI priorities might get you better results.

Yes the are available and they "should work on QNX" (NI words). Setting the Period in the Timed Loop works (it is easy to see that), but I don't know

how to check if the loops are actually executed with the set priorities.

Is there any difference between 0 ms wait and not using wait at all?

[crelf]

QUOTE(souske @ Feb 21 2008, 06:28 AM)

Is there any difference between 0 ms wait and not using wait at all?

Absolutely - (in generic terms) the 0ms wait actively allows the OS to swap to a different thread, if required. having no wait in there *can* lock the OS to servicing the thread, and other things can really suffer...