Linux Watch - WatchPad Systems
A few representative software systems related threads are captured below. (The base system included Linux, X11, Tcl/Tk, WML browser, etc.)
Low Power 2001-2003
Two new concepts were developed to reduce the power consumed by the Linux watch. The Linux Watch pushed the boundaries on power consumption and for the first time it became clear that mimimizing standby power was super-critical in making batteries last. Hardwired custom devices such as electronic watches excelled at reducing the power foot print to microwatts but were limited in function. At the other end general purpose processors were emphasizing speed and number of instructions per second, including speculative execution, etc., all pointed in the direction of increased power consumption. With the advent of the smart phone custom processors with multiple low power sleep states have been introduced in the past decade. However, in the 2001-2004 timeframe, it was essential to disseminate that innovation at multiple levels was necessary to get the maximum battery life from a 200mwh battery. Some of them are listed below.
1) work dependent timing scheme to eliminate a periodic timer tick in the Linux OS when it is not necessary and put the processor into the best sleep state. This feature is now implemented in Linux Tickless Kernel on S390 and on i386, e.g., Redhat Enterprise Linux 6 implements this feature - "The kernel in Red Hat Enterprise Linux 6 runs tickless: that is, it replaces the old periodic timer interrupts with on-demand interrupts. Therefore, idle CPUs are allowed to remain idle until a new task is queued for processing, and CPUs that have entered lower power states can remain in these states longer."
2) controlling the power consumed by the display by varying the number of lighted pixels for depicting content.
Several smart watches in the market today, including the Apple iWatch use an OLED display and screen styles that use more black than white to save power.
Work Dependent Timing Scheme
The Linux Operating System (OS) operates around the notion of a periodical timer interrupt, known as the tick. The frequency of this interrupt is 100Hz in most Linux systems. In the case where there's no work to be done, i.e., the system is idling, the OS typically puts the processor into a low power state in between the timer ticks. From the standpoint of power consumption, this is not an efficient timing method since it forces the processor and OS to service the timer interrupt every 10ms, even when there is no other work to carry out. In addition, there may be a finite amount of energy associated with transitioning the processor into and out of the low power state. This energy is also wasted whenever there's no work to be done. Finally, the 10ms idling period between timer ticks may limit the OS to exploit more efficient processor low power states, since the more efficient low power states may take longer than 10ms to transition into and out of.
Many of today's mobile and portable devices are what we denote as idle systems. Per our definition, an idle system is a system in which there are no active tasks running the majority of time the device is turned on. Examples of predominantly idle systems could include PDAs, sensors, etc. On many occasions, we turn PDAs on, issue a couple of requests and then we digest the information displayed on the screen and/or we let the device "just sit there". Nevertheless, the timer interrupt in the system, persistently interrupts the processor and forces the OS to needlessly service the interrupt and thus consume energy.
We address the above problem by implementing a more suitable timing scheme in the Linux kernel which better exploits the processor's most low power mode. The scheme is called work dependent timing (WDT). The basic approach is to skip timer ticks whenever there is no work to be done. So whenever code operation returns to the Linux "main idle loop", we parse the various queues and lists that may contain tasks that need to be executed. If they are all empty, then we parse the timer list which contains timers with associated timeout values. We find the timer with the nearest timeout value and then program the hardware timer accordingly to wake us up when it's time for the timer function to be executed. The following figure illustrates the low power WDT scheme (using specific power numbers from the Linux Watch implementation).
As may be seen from the figure, the timer ticks which do not result in any work to be carried out are skipped, thus giving the processor and OS more time to remain in the IDLE or STANDBY low power modes. The low power WDT scheme improves the battery life for the WatchPad 1.5 from around 8hrs (when running standard Linux kernel) to anywhere between 35-64hrs depending on usage pattern. The reason for the significant improvement in battery life is the fact that sufficiently long timer interrupt intervals makes it possible to utilize the STANDBY (lowest power) mode in the Linux Watch processor.
More details can be found in
A Work Dependent OS Timing Scheme for Power Management: Implementation in Linux and Modeling of Energy Savings, Claus Michael Olsen, Chandrasekhar Narayanaswami. IBM Research Report RC22784, April 2003.
PowerNap: An Efficient Power Management Scheme for Mobile Devices, C Michael Olsen, Chandra Narayanaswami, IEEE Transactions on Mobile Computers, vol. 5, no. 7, July 2006, pp. 816-828
OLED Displays and Power Savings
The OLED display used in one version of the Linux Watch includes an SRAM cell per pixel and power is consumed only by pixels that are turned on. There is no backlight in the device. This feature allows us to control the power consumed by the display by changing the graphical representation of data shown on the screen. One example, shown in the figure below is the display of time. For comparable readability, digital representation of time needs more pixels to be turned on than an analog representation. Within each scheme, the figure shows how the number of lighted pixels can be changed. For example, the number of lighted pixels for an analog representation ranges from 1.07-1.33% of the total number of pixels on the screen.
More details of this technique can be found in
Energy Trade-offs in the IBM Wristwatch Computer. N. Kamijoh, T. Inoue, C. M. Olsen, M. Raghunath, C. Narayanaswami. Proceedings of the Fifth IEEE International Symposium on Wearable Computers (ISWC'01), pp 133-140.
Mobile IPv6 on the Linux Watch (shown at LinuxWorld August 2002)
In this demo a server streams image data to the watch using TCP over IPv6. The Linux Watch is attached to its cradle with a serial cable. A PPP connection between an access point and the cradle provides IP connectivity. The watch can be moved from one access point to another by detaching the serial cable and attaching it at the new station. This demonstration shows the mobility of the watch, persistent IP connectivity and the fact that Linux can provide network connectivity to small devices.
As shown in the above figure our demonstration setup consisted of two laptops that served as routers, routing IP packets between their Ethernet interfaces and PPP running on their serial ports. One of these laptops was the home router and the was the foreign router. The Linux Watch made PPP connections with either the home or the foreign router when its serial cable was connected to them.
We decided to demonstrate mobility in action by showing a single TCP connection that stayed alive even as the Watch was disconnected from its home router and connected to a foreign router and back. Because TCP connections are hard to visualize, we created an application that showed a continuous slideshow on the Watch display, repeatedly fetching different still images over a TCP socket connection, and displaying them on the Watch face. Conceptually, a third machine was the server that served up the still images to the Watch, but for the demo we simply ran the server program on one of the two laptops that served as routers. When the serial cable from the Watch was disconnected from the home router (laptop), the still image data over the TCP connection was interrupted and the slideshow stopped advancing. When the Watch was then connected to the foreign router (laptop), this router reestablished its persistent PPP connection with the Watch and the Watch discovers that it has now moved to a foreign location. This movement detection is achieved through Mobile IPv6 signaling mechanisms and in this process the Watch did a registration with the HA (foreign router) and also performed route optimization with the Correspondence Node (which in this case happened to be the Home Agent itself). Thus, it ensured that the slideshow data packets got routed to the foreign location. All of this takes a couple of seconds and once the data flow over the TCP connection resumed, the slideshow continued from where it was stalled. The TCP connection remained oblivious to the fact that the watch moved from one router to another.
Over time, we expect this to work wireless interfaces such as Bluetooth™.
Some external coverage on this topic can be found here.
More details are available in a paper published in Fosdem 2004.
BlueDrekarTM running on the Linux watch - Dec 2000
IBM demonstrated the watch with BluetoothTM capabilities at Bluetooth Developers Conference 2000 in San Jose, CA by running the BlueDrekarTM protocol stack developed at IBM Research on the Linux Watch. This was one of the earliest demonstrations of the Bluetooth protocol.
With this functionality the Linux watch can interact with other appliances or devices that also have Bluetooth capabilities. For example, the watch could be used to control a projector, a stereo system, or a thermostat, etc. The data in the watch, such as an address book, could also be viewed on a bigger BluetoothTM capable display.
Linux is registered trademark of Linus Torvalds. The Bluetooth trademarks are owned by Bluetooth SIG, Inc. U.S.A. and used by IBM under license.