topic Re: microsecond tick count in LabVIEW

microsecond tick count

jspaarg — Tue, 25 Jul 2006 18:42:07 GMT

To do some fast and dirty performance analysis, I was wondering if I could get less than ms resolution from anything in LabView.

I found this post

http://forums.ni.com/ni/board/message?board.id=170&message.id=165500&query.id=205509#M165500

Which seems to ask the same question, but the answer seems more like a CVI answer than LabView.

Can you access the Query... API from LabView?

If so, can someone please tell me how?

Thanks

Re: microsecond tick count

Kevin_Price — Tue, 25 Jul 2006 18:53:13 GMT

In addition to the answer you linked, there's also a LabVIEW-based example that uses the RDTSC (ReaD TimeStamp Counter) instruction to query a counter that increments at CPU freq (or thereabouts, I don't know the raw gory details down at that low level).

It was intended for use under Pentium-based RT systems, but I recall using it under Windows as well. Here's a link.

Just keep in mind that the timing uncertainty for a chain of function calls under Windows may be orders of magnitude greater than the actual CPU usage time.

When I'm checking performance under Windows, I usually look for some type of average time over maybe 10000+ calls, depending on the thingy I'm benchmarking. Also note that sometimes performance during a benchmark can be significantly better than it is in normal use. The tight looping may keep a lot of things in a local cache and require many fewer than normal wait states for memory access.

Good luck! Despite the quirks and difficulties of performing benchmarks, it's still good to take your best shot at it.

-Kevin P.

Re: microsecond tick count

jspaarg — Tue, 25 Jul 2006 18:58:59 GMT

Thanks a lot. I will give this a try.

Spending most of my adult life in embedded, I am used to being able to get statistically significant information with just a few samples (assuming you know the architecture). I realize that just won't happen with a PC, but I would like to get a general idea what I'm up against.

Thanks again.

Re: microsecond tick count

Matt_W1 — Tue, 25 Jul 2006 20:39:07 GMT

Here's a little LLB I wrote for accessing QueryPerformanceCounter. Basically you just have to use the time output from the HighResTimer.vi. You may also have to relink the DLL calls to kernel.dll. Note this only works on a windows system.

If you need to tweak it. I wrote the code originally in LV7, which is why I'm internally using a pair of int32s instead of a single int64.

Re: microsecond tick count

jspaarg — Tue, 25 Jul 2006 20:41:41 GMT

Thanks a bunch.

I will take a look at this later.

LabView 7 is perfect as I am using 7.1

Re: microsecond tick count

Matt_W1 — Tue, 25 Jul 2006 20:45:52 GMT

I updated it to use int64, so it's just one VI now

Re: microsecond tick count

Matt_W1 — Tue, 25 Jul 2006 21:02:47 GMT

I found an old version compiled under 7.1

Hopefully this one should work for you

Re: microsecond tick count

LV_J — Tue, 22 May 2007 16:23:23 GMT

Hi Matt,

I believe you made an error in your code to join two 32-bit numbers. The high part should be multiplied by 2^32 = 4,294,967,296 (an even number), not 4,294,967,295. Unless you are trying to compensate for the code processing time to do the calculation.

Regards, Jay

Re: microsecond tick count

Matt_W1 — Tue, 22 May 2007 20:03:33 GMT

You're right that is wrong, I would post corrected code but for some reason QPC is only accurate to one second on my machine (I don't have time to figure out why, although that is really weird. I have unusual windows setup though, so it's likely just me), so I can't really test it. The 8.0 code that uses 64bit ints isn't affected. As a warning, QPC doesn't work right on certain old chipsets, and on some multicore CPUS (The AMD hotfix and /pmtimer in boot.ini usually straightens out the dual cores). But for quick and dirty performance analysis on a development machine it should be good.

Re: microsecond tick count

eoinbutler — Mon, 03 Sep 2007 14:25:01 GMT

I can also only get the VI to be accurate to 1s. I've tried it on multiple PCs (AMD and Intel chips) but no change. Anyone know why?

Re: microsecond tick count

altenbach — Mon, 03 Sep 2007 20:53:14 GMT

I can easily measure loop times in the low microseconds after doing some modifications.

Try a loop time of 0, 1, 2, or 3 ms for example. You'll also notice that on many modern processors, a 1ms will turn into a 2ms wait.

I am still not entire sure about the U64 division. Maybe it is OK.

See attached example (LabVIEW 8.2)

Message Edited by altenbach on 09-03-2007 01:56 PM

Re: microsecond tick count

YHAnis — Thu, 10 Apr 2008 22:51:30 GMT

The file is saved on v8.2. Can you please save it as v8.0?

Re: microsecond tick count

sensorimotor_nsc — Sun, 10 May 2009 20:57:50 GMT

Althought this thread is just short of 2 years old, I have some questions regarding sub millisecond timer work, such as in the HighResTimer.vi that was posted here.

One of the comments in this thread indicates that on some chipsets and multicore systems, the QueryPerformanceCounter does not necessarily work correctly.

On the MSDN boards for QPC, I found this remark:

"On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function."

So, is the problem of QPC in Labview only that it may poll the Counter from a different thread? Is there a way to circumvent this, with the SetThreadAffinityMask function to only call the HighResTimer.vi using a specific thread?

Other things I've read about this:

"If there's heavy bus traffic, on many, common chip sets, even very new ones, this timer may suddenly jump between one and four seconds forward in time (boo!). I believe there is some internal race WRT this counter being 64 bits, but kept in two separate 32-bit registers, but don't hold me to that."

Is all of this true?

What I want to do: monitor parallel port and determine the time between consecutive pulses. The pulses are spaced approximately 25ms apart, so using the ms tick counter, even one ms off and I have a 4% change... I don't want much more resolution, really 1-2% margin of error is okay. Will the QPC be alright for my purposes?

Or is my misunderstanding of this all skewed?

Thanks

Brian

Re: microsecond tick count

DFGray — Mon, 11 May 2009 13:55:11 GMT

Here is an 8.0.1 version of the code (Windows only!). It includes VIs to query the frequency of the counter, the tick count, and calculate the interval from two tick counts. It will only work on processors which have a high resolution timer (I think this was introduced with the Pentium Pro, but it has been awhile and I could be wrong).

Note that due to the multi-tasking nature of Windows, you should probably take a large set of measurements and then take your minimum. Be sure to take into account your infrastructure time (loop time, VI call time, etc.). It can be challenging, but it is also fun to figure it out.

Let us know if you need more info.

Re: microsecond tick count

Ben — Mon, 11 May 2009 14:16:55 GMT

FYI:

If using LV Real-Time is an option then sub-microsecond measurements can be performed by uisng hardware clocked counters. Using NI stuff I used an 80 MHz clock to meassure node to node SCRAMNet trasfers. Please ntoe that at these time intervals the overhead of calling VI WILL affect your mesurements.

Have fun!

Ben