Test Cases for the OAL Timer Test (Windows CE 5.0)

  • Article

Send Feedback

Each test case for the OAL Timer Test falls into one of several categories. Test cases 102, 111, and 121 calculate the resolution of a specified timer and compare the resolution to an upper bound. Test cases 103, 112, and 122 confirm that the timer monotonically increases, except in an overflow condition. Test cases 131, 132, and 133 compare two clocks to each other, calculate the drift between the clocks, and confirm that the drift is less than an acceptable threshold. Test case 141 is a manual test. You must edit the command line for the OAL Timer Test to run test case 141. To run test case 141, specify the command line tux -o -d oaltest -x141, and then run the OAL Timer Test. For information about editing the command line for a CETK test, see Editing the Command Line for a Test.

The following table shows the test cases for the OAL Timer Test.

Note   If a tested clock does not run accurately, the expected duration of a test case shown in the following table might not be accurate.

Test case Description
102: Tick Count Latency/Resolution (high priority) Determines the latency of the GetTickCount function and the resolution of the corresponding clock. This test case records the resolution of the clock for 300 intervals, and then averages the recorded values to report a result.

This test case runs at a scheduler priority of 1.

This test case passes if the average of the recorded values is less than 2 milliseconds (ms).

This test case also reports the latency of the system call, but does not compare this value to a threshold value.

Note   This test case evaluates resolution, not precision. The precision of a clock is the smallest unit of measurement that the clock displays. The resolution is the smallest unit that the clock accurately measures. In general, the precision of a clock is greater than the resolution of the clock because the unit of measurement for a clock is typically chosen so that the unit does not prevent an accurate reading of the clock. In some cases, a higher precision is possible but not used because no application requires a higher precision.
103: Tick Count Backwards Check Confirms that the clock for the GetTickCount function is a monotonically increasing value that runs backward only if it overflows. This test case reads each subsequent clock tick and verifies that the value is greater than the previous value. If the value is less than the previous value, the difference between the values must be less than twice the resolution of the clock. If the difference between the values is greater than twice the resolution of the clock, this test case fails.

By default, this test case runs for 10 minutes. You can specify the length of time that it runs by specifying the -c command-line parameter and appending "–tt_it <seconds>", where <seconds> is the number of seconds for which you want the test case to run. If the clock does not tick correctly, the test case might not run for the length of time that you specify.

The timer for the GetTickCount function wraps once approximately every 49 days. To test the condition where the timer overflows, set the timer so that the timer will soon wrap.
111: High Performance Latency/Resolution (high priority) Determines the latency of the QueryPerformanceCounter function and the resolution of the high-performance clock. This test case records the resolution of the clock for 300 intervals, and then averages the recorded values to report a result.

This test case runs at a scheduler priority of 1.

This test case passes if the average of the recorded values is less than 2 ms.

This test case also reports the latency of the system call, but does not compare this value to a threshold value.

This test case skips if the test determines that the OAL does not implement a high-performance clock.

Note   This test case evaluates resolution, not precision. The precision of a clock is the smallest unit of measurement that the clock displays. The resolution is the smallest unit that the clock accurately measures. In general, the precision of a clock is greater than the resolution of the clock because the unit of measurement for a clock is typically chosen so that the unit does not prevent an accurate reading of the clock. In some cases, a higher precision is possible but not used because no application requires a higher precision.
112: High Performance Backwards Check Confirms that the high-performance counter is a monotonically increasing value that runs backward only if it overflows. This test case reads each subsequent clock tick and verifies that the value is greater than the previous value. If the value is less than the previous value, the difference between the values must be less than twice the resolution of the clock. If the difference between the values is greater than twice the resolution of the clock, this test case fails.

By default, this test case runs for 10 minutes. You can specify the length of time that this test case runs by specifying the -c command-line parameter and appending "–tt_it <seconds>", where <seconds> is the number of seconds for which you want the test case to run. If the clock does not tick correctly, the test case might not run for the length of time that you specify.
121: RTC Latency/Resolution (high priority) Determines the latency of the GetSystemTime function and the resolution of the real-time clock (RTC). This test case records the resolution of the clock for 300 intervals, and then averages the recorded values to report a result.

This test case runs at a scheduler priority of 1.

This test case passes if the average of the recorded values is less than 2 seconds (s).

This test case also reports the latency of the system call, but does not compare this value to a threshold value.

Note   This test case evaluates resolution, not precision. The precision of a clock is the smallest unit of measurement that the clock displays. The resolution is the smallest unit that the clock accurately measures. In general, the precision of a clock is greater than the resolution of the clock because the unit of measurement for a clock is typically chosen such that the unit does not prevent an accurate reading of the clock. In some cases, a higher precision is possible but not used because no application requires a higher precision.
122: RTC Backwards Check Confirms that the RTC is a monotonically increasing value that runs backward only if it overflows. This test case reads each subsequent clock tick and verifies that the value is greater than the previous value. If the value is less than the previous value, the difference between the values must be less than twice the resolution of the clock. If the difference between the values is greater than twice the resolution of the clock, this test case fails.

By default, this test case runs for 10 minutes. You can specify the length of time that this test case runs by specifying the -c command-line parameter and appending "–tt_it <seconds>", where <seconds> is the number of seconds for which you want the test case to run. If the clock does not tick correctly, the test case might not run for the length of time that you specify.
131: Compare High Perf to GetTickCount Calculates the drift between the high-performance counter and the clock for the GetTickCount function. This test case runs for 30 intervals. Each interval is 5 minutes. This test case calculates drift by comparing the beginning and ending values for each clock over each interval.

This test case fails if the clocks drift by more than 1.44 seconds in any hour, or if the average drift per hour exceeds 0.75 seconds.

This test case runs for approximately 2.5 hours. The clock for the GetTickCount function has relatively low resolution. Significant time is required to detect drift in a clock with low resolution.
132: Compare RTC to GetTickCount Calculates the drift between the RTC and the clock for the GetTickCount function. This test case runs for 30 intervals. Each interval is 5 minutes. This test case calculates drift by comparing the beginning and ending values for each clock over each interval.

This test case fails if the clocks drift by more than 1.44 seconds in any hour, or if the average drift per hour exceeds 0.75 seconds.

This test case runs for approximately 2.5 hours. The clock for the GetTickCount function has relatively low resolution. Significant time is required to detect drift in a clock with low resolution.
133: Compare High Perf to RTC Calculates the drift between the high-performance counter and the RTC. This test case runs for 30 intervals. Each interval is 5 minutes. This test case calculates drift by comparing the beginning and ending values for each clock over each interval.

This test case fails if the clocks drift by more than 1.44 seconds in any hour, or if the average drift per hour exceeds 0.75 seconds.

This test case runs for approximately 2.5 hours.
141: Wall Clock Drift Test (manual) Compares the clock for the GetTickCount function to a wall clock. This test case catches a condition in which the clock for the GetTickCount function, the high-performance counter, and the RTC agree with each other but do not keep accurate time. This condition might occur if all three clocks derive from a common clock that does not keep accurate time.

Test case 141 is a manual test. To run test case 141, specify the command line tux -o -d oaltest -x141, and then run the OAL Timer Test.

This test case assumes that the time between clock ticks is relatively constant.

Before starting this test case, obtain a stopwatch or other external clock that you can use to measure the length of events during the test.

By default, this test case runs for 3 hours. You can specify the length of the test from the command line. Specify the -c command-line parameter and append "–tt_wc <minutes>", where <minutes> is the number of minutes that you want the test case to run.

This test case displays a start time, waits for the length of time that you specified in the command line, and then displays a stop time. The test displays a message that tells you when to start your stopwatch, and then periodically displays messages that tell you how much time remains. Observe these messages and prepare to stop the stopwatch when the test completes. The test displays messages more frequently when the test nears completion.

If the time that you record is the same as the time reported by the test, the clocks keep accurate time. If the time that you record differs from the time reported by the test, at least one of the clocks does not keep accurate time.

When this test case starts, it determines whether a timer would overflow during the test. The test case fails if it determines that a timer would overflow. Run the test when a timer is not set to overflow during the test.

A noisy Sleep routine might cause this test case to report a false positive. A false positive might occur if one end of the test is close to the overflow boundary and a Sleep call returned after the timer overflowed. Run the test when the timer is not near the overflow boundary.

This test case displays the following error message if a timer suddenly jumps forward in time during the test:

ERROR: The current time overshot the stop time for the test.
ERROR: This is quite odd, because it shouldn't have happened.
ERROR: Something is most likely wrong with either sleep or the timers.

This error causes the test to end. This error occurs if the Sleep function does not behave correctly or if a timer does not behave correctly.

See Also

OAL Timer Test | Supporting High-Resolution Timers

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.