Status update as of 11/15/05

 

(Note: All tasks listed were executed by both Deepa and Tricia)

 

Previously Open Issues (from 11/1/05 status)

1.      We need to ensure we have the right kernel source before doing any flashes of the kernel. Resolved: Dr. Mueller confirmed we had the correct source.

2.      We need to understand why when we set the mode to suspend it does not work as expected. Resolved: This is a known bug but does not affect our experiment.

3.      We need to understand the granularity provided by the available clocks. From our current understanding the RTC value can only be read with the highest precision of seconds based on what we have read in section 14.4 of the 405LP user manual (p. 308) which shows the registers available for reading the RTC value. Completed: This is true, therefore we need to use other solutions such as using the PIT timer to gain better granularity instead of just reading the RTC.

4.      We need to understand which registers and clocks are available to us even in a suspended mode. The Documentation/powerpc/405lp-sleep.txt states "The RTC remains active during sleep, but the timebase does not…". Need to understand the PIT as well to determine if this is available to us during a suspend. If the PIT is available, we could possibly use the RTC to drive the PIT and use that to calculate the time. Completed: The PIT is not available during a suspend (as determined from our experiments). Instead, we plan to initialize the PIT immediately upon initiation of a wake-up and then read it after wake-up is complete.

 

Completed tasks

  1. Resolved open issues from the last progress report. Details are in the section above.
  2. Compiled the kernel. In order to successfully compile the kernel, we needed to do the following:

-       Changed link under include/asm directory to point to ppc directory instead of x86

-       Copied powerpc-linux-nm from /opt/cross/bin to our directory and renamed to ppc_405-nm

  1. Modified the kernel code with our own sleep/wakeup overhead measurement code and flashed the board using instructions in README file.
  2. Ran experiments with our code and determined that the PIT is not decremented during suspend mode. Our analysis based on these experiments is that we should measure the overhead from the time the wakeup call is first initiated until the wake-up has completed. We can do this using the PIT, but we need to first determine what rate the PIT is being decremented.
  3. We found microsecond timer code in the kernel in the file 4xx_utimer.c. If the kernel is enabled using a compile flag. As far as we can tell from the source code, this flag is not enabled. However, this can be used for microsecond scheduling precision of the dpm. But we don't fully understand how exactly the PIT is used for this. Since, according to our previous experiments, we found that the PIT was not being used, we're using it for our readings.
  4. Successfully modified the kernel code to use the RTC to decrement the PIT (on a power state initialization), set the RTC to 4.2MHz and ran tests to ensure the PIT decremented as expected. We did this by commenting out the actual suspend code and instead just having it go to sleep for a specified amount of time. We then compared the number of times the PIT decremented against the amount of time that had passed (via usleep). We found that the PIT did not decrement at a clock speed of 4.2 MHz, but instead was decremented at a rate of 1.048576 MHz. This is okay for our experiments so we will use 1.048576 MHz. We have detailed notes of these experiments.
  5. Determined that the overhead for wake-up in clock suspend mode is essentially 0 since the only action that occurs is restarting the clock and this is the only part of the wake-up that we cannot measure. Also confirmed this experimentally.
  6. Took measurements of the wake-up overhead for the mode ‘suspend’. We have detailed notes of these measurements, which are summarized in this report.

 

Open Issues

1.      Cannot get the board to recover from a “standby” mode.

 

Current Status of Milestones/Tasks

1.      Address open issues especially in regards to understanding timers and registers available during suspend modes. Enabling better granularity than 1 second (Nov 7). Completed.

2.      Flashing the kernel with the new code and running tests via an application driver to determine overhead (Nov 14). Completed.

Our basic project goals are essentially completed. Hence, we will next attempt the following stretch goals (originally identified in the proposal):

3.      Expanding application driver to test the various sleep modes. Begin incorporation into scheduler (Nov 21).

4.      Incorporation into scheduler (Nov 28)

 

Summary of Measurements

Suspend Mode:

Sleep overhead = 228.56 microseconds

Wakeup overhead = 83.89 microseconds

 

Clock suspend mode:

Sleep overhead = 168.82 microseconds

Wakeup overhead = 0 microseconds