BatteryMAX (idle detection)
BatteryMAX is an Idle Detection System used for computer power management developed at Digital Research, Inc.'s European Development Centre (EDC) in Hungerford, UK. It was invented by British borne engineers Roger Gross and John Constant in August 1989 and was first released with DR DOS 5.0. It was created to address the new genre of portable personal computers (lap-tops) which ran from battery power. As such, it was also an integral part of Novell's PalmDOS 1.0 operating system tailored for early palmtops in 1992.
Description
Power saving in laptop computers traditionally relied on hardware inactivity timers to determine whether a computer was idle. It would typically take several minutes before the computer could identify idle behavior and switch to a lower power consumption state. By monitoring software applications from within the operating system, BatteryMAX is able to reduce the time taken to detect idle behavior from minutes to microseconds. Moreover it can switch power states around 20 times a second between a user's keystrokes. The technique was named Dynamic Idle Detection and includes halting, or stopping the CPU for periods of just a few microseconds until a hardware event occurs to restart it.
DR DOS 5.0 was the first Personal Computer operating system to incorporate an Idle Detection System for power management. An US patent describing the Idle Detection System (5,355,501) was filed on 9 March 1990 and was granted in 11 October 1994.
Despite taking an early lead and having the protection of a patent, BatteryMAX did not enjoy commercial success having been sidelined after the disarray that followed the integration of Digital Research into Novell, Inc. in 1991. It was not until 1992, some three years after the invention that software power management under operating system control became ubiquitous following the launch of Advanced Power Management by Microsoft and Intel.
Functional Overview
BatteryMAX uses the technique of Dynamic Idle Detection to provide power savings by detecting what the application is doing (whether it is idle), and switching power states (entering low power mode) therefore extending the battery life of the product.
BatteryMAX employs a layered model of detection software encapsulated into an DOS character device driver called $IDLE$ which contains all the hardware-dependent code to support Dynamic Idle Detection. It can either be linked into the DR-DOS operating system BIOS or loaded dynamically using the CONFIG.SYS DEVICE directive, overloading the built-in default driver. All versions of DR-DOS since version 5.0 have contained Dynamic Idle Detection support inside the operating system kernel. When the operating system believes an application is idle, it calls the $IDLE$ BIOS/driver layer, which executes custom code written by the computer manufacturer or third parties to verify the request and switch power states. Using the device driver concept, BatteryMAX can be integrated with hardware-related power management facilities, which might be provided by the underlying hardware, including interfacing with APM or ACPI system BIOSes.
Power states are computer dependent and will vary from manufacturer to manufacturer. Power savings can be made in a number of ways including slowing/stopping the processor clock speed or shutting off power to complete sub-systems.
Before switching power states, the $IDLE$ driver uses any available hardware assistance to detect if the application has been accessing other components in the system. For example, the application may be polling a serial port, or updating a graphics screen. If this is the case, the device driver determines that the application is not in fact idle and overrides the kernel's call to switch power states by passing information back up the layers and allowing application execution to resume.
Detecting when an application is idle
An application is idle if it is waiting for some external event to occur, for example for a keystroke or a mouse movement, or for a fixed amount of time to pass. The DR-DOS kernel monitors all DOS API calls building up a profile of the applications behavior. Certain combinations of API calls suggest that the application is idle.
The $IDLE$ driver is able to make the subtle distinction between a program that is genuinely idle, for instance one that is polling the keyboard in a tight loop, and one that is active but also polling the keyboard, to test for an abort key to be pressed. The driver makes this distinction by monitoring the time taken to go idle. If the time is within a specified period, the driver assumes that the program is idle, e.g. polling in a tight loop for a key to be pressed. If the time is outside the specified limit, the driver assumes that some processing has occurred in between polling the keyboard, and allows application execution to resume without switching power states. A local variable, IDLE_CNTDN, specifies the time against which the actual time taken to go idle is compared. The value for this variable is dynamically calculated at initialization and recalculated periodically.
Origins of BatteryMAX
The Idle Detection technique was first used to improve multi-tasking of single-tasking MS-DOS applications in Digital Research's multi-tasking/multi-user Concurrent DOS/386 (CDOS386) operating system.
Programs written for single-tasking operating systems such as MS-DOS can go into endless loops until interrupted; for example when waiting for a user to press a key. Whilst this is not a problem where there is no other process waiting to run, it wastes valuable processor time that could be used by other programs in a multi-tasking/multi-user environment like CDOS386. Applications designed for a multi-tasking environment use API calls to "sleep" when they are idle for a period of time but MS-DOS applications do not do this so Idle Detection must be used.
The Concurrent DOS/386 release included an Idle Detection function in the operating system Kernel which monitored MS-DOS API calls to determine whether the application was doing useful work or in fact idle. If it was idle, the process was suspended allowing the dispatcher to schedule another process for execution.