09-03-2007 03:53 PM - edited 09-03-2007 03:53 PM
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
04-10-2008 05:51 PM
05-10-2009 03:57 PM
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
05-11-2009 08:55 AM
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.
05-11-2009 09:16 AM
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