Compare All Three Timers Drift Test - Periodic and Random OEMIdle (Compact 7)
3/12/2014
The Compare All Three Timers Drift Test - Periodic and Random OEMIdle tests check for drift, timing irregularities, and other timer problems on the three clocks (GetTickCount, High-Performance, and Real-Time Clock) by comparing them with each other under different system conditions. These tests periodically take data samples from the clocks. The system is kept in different states in the time period between samples, allowing identification of drift introduced by specific functions.
A good way to use the Three Timer Drift tests is to run them to confirm the clocks do not drift relative to each other, and to run at least one of the individual drift tests to confirm that the clock does not drift relative to outside sources. To measure drift on individual clocks, use the Wall Clock Timer Tests. These allow one to compare a given clock against a stop watch or any other external clock source. Ideally, one would compare the RTC, since this clock is not expected to drift with respect to an outside clock.
The RTC and GTC also have an automated drift test that compares them to an NTP server. If you have access to an NTP server, you can take advantage of this test; see RTC and GTC to NTP Drift Test.
If there is a known drift between any two clocks on the platform which is by design, the test can be given drift bounds so that it passes when the drift is within the specified bounds.
Each subtest runs by default for 3 hours.
Test Prerequisites
The following table shows the hardware requirements for the test:
| Requirements | Description |
|---|---|
GetTickCount Clock |
The clock that corresponds to the GetTickCount function |
High-performance Counter |
The clock that corresponds to the QueryPerformanceCounter function |
Real-Time Clock (RTC) |
The clock that corresponds to the GetSystemTime function |
The following table shows the software requirements for the test:
| Requirements | Description |
|---|---|
Tux.exe |
Tux test harness |
Kato.dll |
Kato logging engine |
OalTestTimers.dll |
Library containing the timer tests |
Subtests
The table below lists the subtests included in this test.
| SubTest ID | Description |
|---|---|
3030 |
Compare All Three Timers - Periodic OEMidle Confirms that the clocks do not drift relative to each other. The test periodically takes data samples from each of the three clocks, and compares them to each other for drift. The default time between samples is 2 minutes. This test is similar to the OS Sleep case (3020), except that instead of waking after 2 minutes, it wakes every N milliseconds. N in this case varies from 5 ms to 1000 ms. Regardless of how frequently a device may wake up, data points are taken only once every 2 minutes. Waking every N ms allows the test to call OEMIdle and force the OS into deep sleep for varying times. This can expose odd drift issues in the timer routines. The default run time for this test is 3 hours. This can be changed using -c "-driftRunTime <time>", where time is the run time for the test. If there is known drift between any two clocks on the platform which is by design, the test can be given drift bounds by appending "-trackIdlePer bound num1 num2", so that it passes when drift is within the specified bounds. See explanation of values below table. |
3040 |
Compare All Three Timers - Random OEMIdle Confirms that the clocks do not drift relative to each other. The test periodically takes data samples from each of the three clocks and these samples are compared to each other for drift. The default time between the samples is 2 minutes. This test is similar to the OS Sleep case (3020), except that instead of waking after 2 minutes, it wakes up at random times. Data points are again taken only once every 2 minutes. Sleeping for random times allows the test to call OEMIdle and force the OS into deep sleep for varying times. This can expose odd drift issues in the timer routines. The default run time for this test is 3 hours. This can be changed using -c "-driftRunTime <time>", where time is the run time for the test. If there is known drift between any two clocks on the platform which is by design, the test can be given drift bounds by appending "-trackIdleRan bound num1 num2", so that it passes when drift is within the specified bounds. See explanation of values below table. |
Setting Up the Test
This test has no additional requirements, beyond the standard test environment setup.
Running the Test
The Compare All Three Timers Drift Test - Periodic and Random OEMIdle performs the following on default execution: tux -o -d oaltesttimers.dll -x 3030,3040 -c"-cmdf OALOemIdleDriftTestCmdLines.txt"
You can modify the test by editing the command line for the test. To specify an optional command line parameter for this test, use the -c command line parameter, which causes Tux to pass the specified string into the test module.
The following table shows the command line parameters for the Compare All Three Timers Drift tests.
| Command line parameter | Description |
|---|---|
-driftRunTime <time> |
Specifies the run time for the test. The default run time is 3 hours. 'time' is considered to be in seconds unless the time modifiers listed below are used. |
-driftSampleSize <time> |
Specifies the time between samples. The default is 2 minutes between samples. The 'time' is considered to be in seconds unless the time modifiers listed below are used. |
-testname <bound numF numS> |
Specifies the drift bounds when comparing the three different clocks for drift. '-testName' is one of -busySleep, -osSleep, -trackIdlePer, or -trackIdleRan. 'bound' is one of GtcToRtc, GtcToHiPerf, or HiPerfToRtc. 'numF' and 'numS' give the 'faster' and 'slower' bounds for the given comparison, respectively. The 'numF' and 'numS' are multiplied with the expected values to define the pass/fail range for the test. The default bounds for all tests are zero. |
-cmdf <filename> |
Read <filename> for bounds information. See OALOemIdleDriftTestCmdLines.txt for an example. |
- s means seconds (12s = 12 seconds)
- m means minutes (12m = 12 minutes)
- h means hours (12h = 12 hours)
- d means days (12d = 12 days)
Note
If a tested clock does not run accurately, the duration of a test case may differ from expected.
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all sub-tests.
Troubleshooting the Test
Determine the point of failure and record the exact error message. Check that the setup steps were followed and that all pre-requisites were met. If the source code is available, examine the point of failure in code to see if any additional information can be gathered about the failure domain.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.