GetIdleTime Tests (Compact 2013)
3/26/2014
The GetTickCount (GTC) Test verifies the implementation of the GetIdleTime function.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The test should be run on a minimal OS design, such as one with only the following SYSGENs set to minimize the likelihood of interactions from other system components:
SYSGEN_NETWORKING=1
SYSGEN_SHELL=1
The tests should be run on a minimal OS design, such as an "OAL" or "Tiny Kernel" image. The test makes assumptions that nothing else is running on the system for significant periods of time. On a larger image, the assumptions will not be true and the test will fail as a result. Therefore, the test should be run on as minimal of a configuration as possible.
The following table shows the hardware requirements for the test.
Requirement |
Description |
|---|---|
GetTickCount clock |
The clock that corresponds to the GetTickCount function |
The following table shows the software requirements for the test
Requirements |
Description |
|---|---|
Tux.exe |
Tux test harness, required for executing the test |
Kato.dll |
Kato logging engine, required for logging test data |
OalTestTimers.dll |
Library containing the timer tests |
Subtests
The table below lists the subtests included in this test.
SubTest ID |
Description |
|---|---|
7010 |
Idle Time While Sleeping Verifies the GetIdleTime function implementation. The test keeps the system idle by sleeping for random amounts of time. After each sleep cycle, the test verifies that the idle time returned by GetIdleTime shows that the system was idle for most of the time. The default run time for the test is 10 minutes. You can specify the length of time that it runs by specifying -c "-idleRunTime seconds", where seconds is the run time for the test in seconds. It is recommended that you run this test on an image built with minimum possible SYSGENs. The more SYSGENs your image has, the more likely this test case will fail. Drivers and applications waking for service will make the system noisy. The failure of this test indicates that there may be something on the system that is waking it up, or that there is a bug in the implementation of GetIdleTime. |
7020 |
Idle Time While Busy Verifies the GetIdleTime implementation. The test keeps the system busy in a while loop and calls GetIdleTime at random intervals. It verifies that the idle time returned by GetIdleTime shows that the system has not been idle at all during that time. The test runs for a default time of 10 minutes. You can specify the length of time that it runs by specifying -c "-idleRunTime seconds", where seconds is the run time for the test in seconds. |
Setting Up the Test
This test has no additional requirements, beyond the standard test environment setup.
Running the Test
The default test command line is: tux -o -d oaltesttimers -x7010,7020
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. For more information about how to edit the command line for a test, see Editing the Command-Line for a Test.
The following table shows the optional command line parameter for the test.
Command line parameter |
Description |
|---|---|
-idleRunTime <time> |
Specifies the run time for the test. The value time is considered to be in seconds unless the following modifiers are used: |
-idleThreshold <threshold> |
Specifies the threshold to use for the test. This is expected minimum ratio of time spent in idle during any measurement period. Default is 0.95 (ie. 95% idle). |
* s means seconds (12s = 12 seconds)
* m means minutes (12m = 12 minutes)
* h means hours (12h = 12 hours)
* d means days (12d = 12 days)
The default run time is 10 minutes
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all sub-tests.
Troubleshooting the Test
* Ensure that you are running on a minimal OS Configuration
* Ensure that drivers and servers running on the OS meet real time constraints and do not interrupt the test
* The Kernel Scheduler (ksched) test may be helpful for further investigation of failures
* 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.