- Data and Times Info from Part 1 of MTConnect 1.3
- W3's Date and Time Formats that MTConnect references
- MSFT's QueryPerformanceCounter (QPC) aka OS Tick Interval
- This document gets in the level of detail that should answer most, if not all, of the questions on accuracy and number of decimal fractional digits. Nice reading if you have trouble falling asleep tonight as well :-)
A guaranteed response time is not part of the MTConnect specification
MTConnect was not designed to take the place of a closed-loop system where guaranteed response times of nanoseconds or microseconds are a hard requirement
Per the MTConnect Spec: When the interval parameter is provided (with the MTConnect Sample command), the MTConnect® Agent MUST find all available events, samples, and condition that match the current filter criteria specified by the path delaying interval milliseconds between data or at its maximum possible rate. The interval indicates the delay between the end of one data transmission and the beginning of the next data transmission. A interval of zero indicates the Agent deliver data at its highest possible rate.
Date and Time Formats
- This version:
- Newest version:
- Misha Wolf <email@example.com>
Charles Wicksteed <firstname.lastname@example.org
- Document Status
Status of this document
Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm)
- Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
- Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.
Acquiring high-resolution time stamp
- QPC support in Windows versions
- Guidance for acquiring time stamps
- General FAQ about QPC and TSC
- FAQ about programming with QPC and TSC
- Low-level hardware clock characteristics
- Hardware timer info
QPC support in Windows versions
- Windows XP and Windows 2000
- QPC is available on Windows XP and Windows 2000 and works well on most systems. However, some hardware systems' BIOS didn't indicate the hardware CPU characteristics correctly (a non-invariant TSC), and some multi-core or multi-processor systems used processors with TSCs that couldn't be synchronized across cores. Systems with flawed firmware that run these versions of Windows might not provide the same QPCreading on different cores if they used the TSC as the basis for QPC.
- Windows Vista and Windows Server 2008
- All computers that shipped with Windows Vista and Windows Server 2008 used a platform counter (High Precision Event Timer (HPET)) or the ACPI Power Management Timer (PM timer) as the basis for QPC. Such platform timers have higher access latency than the TSC and are shared between multiple processors. This limits scalability of QPC if it is called concurrently from multiple processors.
- Windows 7 and Windows Server 2008 R2
- The majority of Windows 7 and Windows Server 2008 R2 computers have processors with constant-rate TSCs and use these counters as the basis for QPC. TSCs are high-resolution per-processor hardware counters that can be accessed with very low latency and overhead (in the order of 10s or 100s of machine cycles, depending on the processor type). Windows 7 and Windows Server 2008 R2 use TSCs as the basis of QPC on single-clock domain systems where the operating system (or the hypervisor) is able to tightly synchronize the individual TSCs across all processors during system initialization. On such systems, the cost of reading the performance counter is significantly lower compared to systems that use a platform counter. Furthermore, there is no added overhead for concurrent calls and user-mode queries often bypass system calls, which further reduces overhead. On systems where the TSC is not suitable for timekeeping, Windows automatically selects a platform counter (either the HPET timer or the ACPI PM timer) as the basis for QPC.
- Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2
- Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 use TSCs as the basis for the performance counter. The TSC synchronization algorithm was significantly improved to better accommodate large systems with many processors. In addition, support for the new precise time-of-day API was added, which enables acquiring precise wall clock time stamps from the operating system. For more info, seeGetSystemTimePreciseAsFileT
ime. On Windows RT PC platforms, the performance counter is based on either a proprietary platform counter or the system counter provided by the Windows RT PC Generic Timer if the platform is so equipped.
Guidance for acquiring time stamps
- Pre-Windows Vista operating systems that run on certain processors might violate this consistency because of one of these reasons:
- The hardware processors have a non-invariant TSC and the BIOS doesn't indicate this condition correctly.
- The TSC synchronization algorithm that was used wasn't suitable for systems with large numbers of processors.
- When you compare performance counter results that are acquired from different threads, consider values that differ by ± 1 tick to have an ambiguous ordering. If the time stamps are taken from the same thread, this ± 1 tick uncertainty doesn't apply. In this context, the term tick refers to a period of time equal to 1 ÷ (the frequency of the performance counter obtained from QueryPerformanceFrequency
Direct TSC usage
Examples for acquiring time stamps
Using QPC in native code
Acquiring high resolution time stamps from managed code
Using QPC from kernel mode
General FAQ about QPC and TSC
- Is QueryPerformanceCounter() the same as the Win32 GetTickCount() or GetTickCount64() function?
- Should I use QPC or call the RDTSC /RDTSCP instructions directly?
- To avoid incorrectness and portability issues, we strongly encourage you to use QPC instead of using the TSC register or the RDTSC or RDTSCP processor instructions.
- What is QPC’s relation to an external time epoch? Can it be synchronized to an external epoch such as UTC?
- Is QPC affected by daylight savings time, leap seconds, time zones, or system time changes made by the administrator?
- No. QPC is completely independent of the system time and UTC.
- Is QPC accuracy affected by processor frequency changes caused by power management or Turbo Boost technology?
- No. If the processor has an invariant TSC, the QPC is not affected by these sort of changes. If the processor doesn't have an invariant TSC, QPCwill revert to a platform hardware timer that won't be affected by processor frequency changes or Turbo Boost technology.
- Does QPC reliably work on multi-processor systems, multi-core system, and systems with hyper-threading?
- How do I determine and validate that QPC works on my machine?
- You don't need to perform such checks.
- Which processors have non-invariant TSCs? How can I check if my system has a non-invariant TSC?
- You don't need to perform this check yourself. Windows operating systems perform several checks at system initialization to determine if the TSC is suitable as a basis for QPC. However, for reference purposes, you can determine whether your processor has an invariant TSC by using one of these:
The following shows the TSC-INVARIANT info that is provided by the Windows Sysinternals Coreinfo.exe utility (www.sysinternals.com). An asterisk means "True".
- the Coreinfo.exe utility from Windows Sysinternals
- checking the values returned by the CPUID instruction pertaining to the TSC characteristics
- the processor manufacturer’s documentation
- Does QPC work reliably on Windows RT PC hardware platforms?
- How often does QPC roll over?
- Not less than 100 years from the most recent system boot, and potentially longer based on the underlying hardware timer used. For most applications, rollover isn't a concern.
- What is the computational cost of calling QPC?
- The computational calling cost of QPC is determined primarily by the underlying hardware platform. If the TSC register is used as the basis for QPC, the computational cost is determined primarily by how long the processor takes to process an RDTSC instruction. This time ranges from 10s of CPU cycles to several hundred CPU cycles depending upon the processor used. If the TSC can't be used, the system will select a different hardware time basis. Because these time bases are located on the motherboard (for example, on the PCI South Bridge or PCH), the per-call computational cost is higher than the TSC, and is frequently in the vicinity of 0.8 - 1.0 microseconds depending on processor speed and other hardware factors. This cost is dominated by the time required to access the hardware device on the motherboard.
- Does QPC require a kernel transition (system call)?
- A kernel transition is not required if the system can use the TSC register as the basis for QPC. If the system must use a different time base, such as the HPET or PM timer, a system call is required.
- Is the performance counter monotonic (non-decreasing)?
- Can the performance counter be used to order events in time?
- Yes. However, when comparing performance counter results that are acquired from different threads, values that differ by ± 1 tick have an ambiguous ordering as if they had an identical time stamp.
- How accurate is the performance counter?
- The answer depends on a variety of factors. For more info, see Low-level hardware clock characteristics.
FAQ about programming with QPC and TSC
- I need to convert the QPC output to milliseconds. How can I avoid loss of precision with converting to double or float?
- There are several things to keep in mind when performing calculations on integer performance counters:
As a general principle, delay these computations and conversions as long as possible to avoid compounding the errors introduced.
- Integer division will lose the remainder. This can cause loss of precision in some cases.
- Conversion between 64 bit integers and floating point (double) can cause loss of precision because the floating point mantissa can't represent all possible integral values.
- Multiplication of 64 bit integers can result in integer overflow.
- How can I convert QPC to 100 nanosecond ticks so I can add it to a FILETIME?
- A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). File times are used by Win32 API calls that return time-of-day, such as GetSystemTimeAsFileTime and
GetSystemTimePreciseAsFileTime . By contrast, QueryPerformanceCoun ter returns values that represent time in units of 1/(the frequency of the performance counter obtained from QueryPerformanceFrequency ). Conversion between the two requires calculating the ratio of the QPCinterval and 100-nanoseconds intervals. Be careful to avoid losing precision because the values might be small (0.0000001 / 0.000000340).
- Why is the time stamp that is returned from QPC a signed integer?
- Calculations that involve QPC time stamps might involve subtraction. By using a signed value, you can handle calculations that might yield negative values.
- How can I obtain high resolution time stamps from managed code?
- Call the Stopwatch.GetTimeStamp met
hod from the System.Diagnostics.Stopwat ch class. For an example about how to useStopwatch.GetTimeStamp, see Acquiring high resolution time stamps from managed code.
- Under what circumstances does QueryPerformanceFrequency return FALSE, or QueryPerformanceCounter return zero?
- This won't occur on any system that runs Windows XP or later.
- Do I need to set the thread affinity to a single core to use QPC?
- No. For more info, see Guidance for acquiring time stamps. This scenario is neither necessary nor desirable. Performing this scenario might adversely affect your application's performance by restricting processing to one core or by creating a bottleneck on a single core if multiple threads set their affinity to the same core when calling QueryPerformanceCounte
Low-level hardware clock characteristics
Absolute Clocks and Difference Clocks
Resolution, Precision, Accuracy, and Stability
- Example 1
- QueryPerformanceFrequency retu
rns the value 3,125,000 on a particular machine. What is the tick interval and resolution of QPCmeasurements on this machine? The tick interval, or period, is the reciprocal of 3,125,000, which is 0.000000320 (320 nanoseconds). Therefore, each tick represents the passing of 320 nanoseconds. Time intervals smaller than 320 nanoseconds can't be measured on this machine.Tick Interval = 1/(Performance Frequency)Tick Interval = 1/3,125,000 = 320 ns
- Example 2
- On the same machine as the preceding example, the difference of the values returned from two successive calls to QPC is 5. How much time has elapsed between the two calls? 5 ticks multiplied by 320 nanoseconds yields 1.6 microseconds.ElapsedTime = Ticks * Tick IntervalElapsedTime = 5 * 320 ns = 1.6 μs
|Clock Source||Nominal Clock Frequency||Clock Resolution||Access Time (Typical)||Precision|
|PC RTC||64 Hz||15.625 milliseconds||N/A||N/A|
|Query performance counter using TSC with a 3 GHz processor clock||3 MHz||333 nanoseconds||30 nanoseconds||333 nanoseconds|
|RDTSC machine instruction on a system with a 3 GHz cycle time||3 GHz||333 picoseconds||30 nanoseconds||30 nanoseconds|
|Time interval duration||Measurement uncertainty due to accumulated error with +/- 10 PPM frequency tolerance|
|1 microsecond||± 10 picoseconds (10-12)|
|1 millisecond||± 10 nanoseconds (10-9)|
|1 second||± 10 microseconds|
|1 hour||± 60 microseconds|
|1 day||± 0.86 seconds|
|1 week||± 6.08 seconds|
- Example 1
- Suppose you perform time-interval measurements by using a 1 MHz oscillator, which has a resolution of 1 microsecond, and a maximum frequency offset error of ±50 ppm. Now, let us suppose the offset is exactly +50 ppm. This means that the actual frequency would be 1,000,050 Hz. If we measured a time interval of 24 hours, our measurement would be 4.3 seconds too short (23:59:55.700000 measured versus 24:00:00.000000 actual).Seconds in a day = 86400Frequency offset error = 50 ppm = 0.0000586,400 seconds * 0.00005 = 4.3 seconds
- Example 2
- Suppose the processor TSC clock is controlled by a crystal oscillator and has specified frequency of 3 GHz. This means that the resolution would be 1/3,000,000,000 or about 333 picoseconds. Assume the crystal used to control the processor clock has a frequency tolerance of ±50 ppm and is actually +50 ppm. In spite of the impressive resolution, a time-interval measurement of 24 hours will still be 4.3 seconds too short. (23:59:55.7000000000 measured versus 24:00:00.0000000000 actual).Seconds in a day = 86400Frequency offset error = 50 ppm = 0.0000586,400 seconds * 0.00005 = 4.3 secondsThis shows that a high resolution TSC clock doesn't necessarily provide more accurate measurements than a lower resolution clock.
- Example 3
- Consider using two different computers to measure the same 24 hour time interval. Both computers have an oscillator with a maximum frequency offset of ± 50 ppm. How far apart can the measurement of the same time interval on these two systems be? As in the previous examples, ± 50 ppm yields a maximum error of ± 4.3 seconds after 24 hours. If one system runs 4.3 seconds fast, and the other 4.3 seconds slow, the maximum error after 24 hours could be 8.6 seconds.Seconds in a day = 86400Frequency offset error = ±50 ppm = ±0.00005±(86,400 seconds * 0.00005) = ±4.3 secondsMaximum offset between the two systems = 8.6 secondsIn summary, the frequency offset error becomes increasingly important when measuring long time intervals and when comparing measurements between different systems.The stability of a timer describes whether the tick frequency changes over time, for example as the result of temperatures changes. Quartz crystals used as the tick generators on computers will exhibit small changes in frequency as a function of temperature. The error caused by thermal drift is typically small compared to the frequency offset error for common temperature ranges. However, designers of software for portable equipment or equipment subject to large temperature fluctuations might need to consider this effect.
Hardware timer info
- TSC Register
- Some Intel and AMD processors contain a TSC register that is a 64-bit register that increases at a high rate, typically equal to the processor clock. The value of this counter can be read through the RDTSC or RDTSCP machine instructions, providing very low access time and computational cost in the order of tens or hundreds of machine cycles, depending upon the processor.Although the TSC register seems like an ideal time stamp mechanism, here are circumstances in which it can't function reliably for timekeeping purposes:
Like other timers, the TSC is based on a crystal oscillator whose exact frequency is not known in advance and that has a frequency offset error. Thus before it can be used, it must be calibrated using another timing reference.During system initialization, Windows checks if the TSC is suitable for timing purposes and performs the necessary frequency calibration and core synchronization.
- Not all processors have TSC registers, so using the TSC register in software directly creates a portability problem. (Windows will select an alternative time source for QPC in this case, which avoids the portability problem.)
- Some processors can vary the frequency of the TSC clock or stop the advancement of the TSC register, which makes the TSC unsuitable for timing purposes on these processors. These processors are said to have non-invariant TSC registers. (Windows will automatically detect this, and select an alternative time source for QPC).
- On multi-processor or multi-core systems, some processors and systems are unable to synchronize the clocks on each core to the same value. (Windows will automatically detect this, and select an alternative time source for QPC).
- On some large multi-processor systems, you might not be able to synchronize the processor clocks to the same value even if the processor has an invariant TSC. (Windows will automatically detect this, and select an alternative time source for QPC).
- Some processors will execute instructions out of order. This can result in incorrect cycle counts when RDTSC is used to time instruction sequences because the RDTSC instruction might be executed at a different time than specified in your program. The RDTSCP instruction has been introduced on some processors in response to this problem.
- PM Clock
- The ACPI timer, also known as the PM clock, was added to the system architecture to provide reliable time stamps independently of the processors speed. Because this was the single goal of this timer, it provides a time stamp in a single clock cycle, but it doesn't provide any other functionality.
- HPET Timer
- The High Precision Event Timer (HPET) was developed jointly by Intel and Microsoft to meet the timing requirements of multimedia and other time-sensitive applications. HPET support has been in Windows since Windows Vista, and Windows 7 and Windows 8 Hardware Logo certification requires HPET support in the hardware platform.