BatteryMAX es un sistema de detección de inactividad utilizado para la gestión de la energía de la computadora bajo el control del sistema operativo, desarrollado en el Centro de Desarrollo Europeo (EDC) de Digital Research, Inc. en Hungerford, Reino Unido. Fue creado para abordar el nuevo género de computadoras personales portátiles ( laptops ) que funcionaban con energía de batería. Como tal, también fue una parte integral del sistema operativo PalmDOS 1.0 de Novell diseñado para los primeros palmtops en 1992.
El ahorro de energía en los ordenadores portátiles dependía tradicionalmente de temporizadores de inactividad de hardware para determinar si un ordenador estaba inactivo. Normalmente, pasarían varios minutos antes de que el ordenador pudiera identificar el comportamiento inactivo y cambiar a un estado de menor consumo de energía. Al supervisar las aplicaciones de software desde el sistema operativo , BatteryMAX puede reducir el tiempo que tarda en detectar el comportamiento inactivo de minutos a microsegundos. Además, puede cambiar de estado de energía unas 18 veces por segundo entre las pulsaciones de teclas de un usuario. La técnica se denominó Detección dinámica de inactividad e incluye la detención o parada de la CPU durante períodos de tan solo unos pocos microsegundos hasta que se produce un evento de hardware que la reinicia.
DR DOS 5.0 en 1990 fue el primer sistema operativo de computadora personal que incorporó un sistema de detección de inactividad para la administración de energía. [1] [2] Fue inventado por los ingenieros británicos Roger Alan Gross y John P. Constant en agosto de 1989. [3] Una patente estadounidense que describe el sistema de detección de inactividad fue presentada el 9 de marzo de 1990 y otorgada el 11 de octubre de 1994. [4]
A pesar de tomar la delantera desde el principio y contar con la protección de una patente, BatteryMAX no disfrutó de un éxito comercial significativo, habiendo quedado al margen tras el caos que siguió a la integración de Digital Research en Novell, Inc. en 1991. No fue hasta 1992, unos tres años después de la invención, que la gestión de energía del software bajo el control del sistema operativo se volvió omnipresente tras el lanzamiento de Advanced Power Management (APM) por parte de Microsoft e Intel .
BatteryMAX utiliza la técnica de detección dinámica de inactividad para proporcionar ahorro de energía al detectar lo que está haciendo la aplicación (si está inactiva) y cambiar los estados de energía (ingresar al modo de bajo consumo), extendiendo así la vida útil de la batería del producto.
BatteryMAX emplea un modelo en capas de software de detección encapsulado en un controlador de dispositivo de caracteres DOS$IDLE$ llamado que contiene todo el código dependiente del hardware para admitir la detección dinámica de inactividad. [5] Puede vincularse al BIOS del sistema operativo DR-DOS o cargarse dinámicamente utilizando la directiva CONFIG.SYS DEVICE , sobrecargando el controlador predeterminado integrado. Todas las versiones de DR-DOS desde la versión 5.0 han contenido soporte de detección dinámica de inactividad dentro del núcleo del sistema operativo . Cuando el sistema operativo cree que una aplicación está inactiva, llama a la $IDLE$capa BIOS/controlador, que ejecuta código personalizado escrito por el fabricante de la computadora o terceros para verificar la solicitud y cambiar los estados de energía. Usando el concepto de controlador de dispositivo, BatteryMAX puede integrarse con instalaciones de administración de energía relacionadas con el hardware, que pueden ser proporcionadas por el hardware subyacente, incluida la interfaz con BIOS de sistema APM o ACPI .
Los estados de energía dependen de la computadora y varían de un fabricante a otro. Se puede ahorrar energía de varias maneras, como reducir o detener la velocidad del reloj del procesador o apagar los subsistemas completos.
Antes de cambiar los estados de energía, el $IDLE$controlador utiliza cualquier asistencia de hardware disponible para detectar si la aplicación ha estado accediendo a otros componentes del sistema. Por ejemplo, la aplicación puede estar sondeando un puerto serie o actualizando una pantalla gráfica. Si este es el caso, el controlador del dispositivo determina que la aplicación no está inactiva y anula la llamada del núcleo para cambiar los estados de energía al pasar la información de vuelta a las capas y permitir que se reanude la ejecución de la aplicación.
COMMAND.COM en DR DOS 5.0 y superior implementa un comando interno IDLEque toma ON|OFFparámetros para habilitar o deshabilitar la detección inactiva dinámica. [6]
Una aplicación está inactiva si está esperando que se produzca algún evento externo, por ejemplo, que se presione una tecla o se mueva el ratón, o que transcurra un tiempo determinado. El núcleo DR-DOS supervisa todas las llamadas a la API de DOS y crea un perfil del comportamiento de la aplicación. Ciertas combinaciones de llamadas a la API sugieren que la aplicación está inactiva.
El $IDLE$controlador puede hacer una distinción sutil entre un programa que está realmente inactivo, por ejemplo, uno que está sondeando el teclado en un bucle cerrado, y uno que está activo pero también sondea el teclado para comprobar si se ha pulsado una tecla de cancelación. El controlador hace esta distinción controlando el tiempo que tarda en quedar inactivo. Si el tiempo está dentro de un período especificado, el controlador supone que el programa está inactivo, por ejemplo, sondeando en un bucle cerrado para comprobar si se ha pulsado una tecla. Si el tiempo está fuera del límite especificado, el controlador supone que se ha producido algún procesamiento entre los sondeos del teclado y permite que la ejecución de la aplicación se reanude sin cambiar los estados de energía. Una variable local, IDLE_CNTDN, especifica el tiempo con el que se compara el tiempo real que tarda en quedar inactivo. El valor de esta variable se calcula dinámicamente en la inicialización y se recalcula periódicamente.
La técnica de detección de inactividad se utilizó por primera vez para mejorar la multitarea de aplicaciones DOS de tarea única en el sistema operativo Concurrent DOS 386 (CDOS386) multitarea/multiusuario de Digital Research .
Los programas escritos para sistemas operativos monotarea como MS-DOS/PC DOS pueden entrar en bucles infinitos hasta que se interrumpen; por ejemplo, cuando esperan que un usuario presione una tecla. Si bien esto no es un problema cuando no hay otro proceso esperando para ejecutarse, desperdicia un valioso tiempo de procesador que podría ser utilizado por otros programas en un entorno multitarea/multiusuario como CDOS386. Las aplicaciones diseñadas para un entorno multitarea utilizan llamadas API para "dormir" cuando están inactivas durante un período de tiempo, pero las aplicaciones DOS normales no lo hacen, por lo que se debe utilizar la detección de inactividad.
La versión 386 de Concurrent DOS incluía una función de detección de inactividad en el núcleo del sistema operativo que supervisaba las llamadas a la API de DOS para determinar si la aplicación estaba realizando un trabajo útil o, de hecho, estaba inactiva. Si estaba inactiva, el proceso se suspendía y permitía al despachador programar otro proceso para su ejecución.
BatteryMAX y la patente de "detección de inactividad" jugaron un papel importante en una supuesta infracción de patente relacionada con la gestión de energía del software bajo el control del sistema operativo.
El 15 de mayo de 2009, St. Clair Intellectual Property Consultants presentó la acción civil n.º 09-354 en el Tribunal de Distrito de los Estados Unidos D. Delaware, contra los demandados Acer , Dell , Gateway y Lenovo y el 18 de septiembre de 2009 presentó la acción civil n.º 09-704 contra Apple y Toshiba . Las acciones alegaban la infracción de varias patentes estadounidenses que poseían relacionadas con la gestión de energía del software bajo el control del sistema operativo.
St. Clair afirmó que Henry Fung había inventado la gestión de energía del software bajo el control del sistema operativo y alegó que estas empresas habían infringido las patentes de St. Clair y, por lo tanto, debían pagos de regalías a St. Clair . Microsoft intervino en nombre de los demandados y presentó una sentencia declaratoria contra St. Clair el 7 de abril de 2010, solicitando sentencias de no infracción e invalidez de las patentes de Fung. (DI 1, CA No. 10-282). Intel presentó una intervención en nombre de los demandados y esta fue concedida el 4 de junio de 2010 (DI 178, CA No. 09-354).
El bufete de abogados de Seattle Perkins Coie , que representaba a los acusados, descubrió BatteryMAX y la patente de detección de inactividad de Gross durante una búsqueda de antecedentes . La patente de Gross tenía una fecha de prioridad anterior a la de las patentes de Fung, lo que, de demostrarse, socavaría el caso de St. Clair. El 28 de febrero de 2011, Intel contrató a Gross como experto en la materia para que prestara testimonio como testigo experto para los acusados en el caso. Gross proporcionó pruebas en su informe pericial de que él, no Fung, había inventado la gestión de energía de software bajo el control del sistema operativo y citó la patente de detección de inactividad y la existencia de BatteryMAX como prueba de ello.
St. Clair presentó una moción para excluir las opiniones relativas a BatteryMAX, en un intento de que se desestimara el informe pericial de Gross, pero el 29 de marzo de 2013, el tribunal de distrito rechazó la moción de St. Clair que declaraba admisible el testimonio de Gross a favor de los demandados, [7] [ se necesita una fuente no primaria ] afirmando que "El Tribunal está de acuerdo con los demandados en que hay pruebas suficientes que corroboran que BatteryMAX estaba disponible para el público antes de la fecha de prioridad de las patentes de Fung. Además, el Tribunal concluye que incluso si BatteryMAX no fuera anterior a las patentes de Fung, el testimonio del Sr. Gross [...] sería relevante y útil para el investigador de hechos en una investigación de obviedad ".
{{cite book}}: |work=ignorado ( ayuda ) (NB. NWDOSTIP.TXT es un trabajo exhaustivo sobre Novell DOS 7 y OpenDOS 7.01, que incluye la descripción de muchas características y componentes internos no documentados. Es parte de la MPDOSTIP.ZIPcolección aún más grande del autor mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace proporcionado apunta a una versión anterior del NWDOSTIP.TXTarchivo convertida a HTML). [1]{{cite book}}: |work=ignorado ( ayuda ) [2]