procesamiento por lotes

¿Qué es el procesamiento por lotes?

El procesamiento por lotes se refiere al almacenamiento en búfer de los eventos del sensor en un concentrador de sensores y/o FIFO de hardware antes de informar los eventos a través de Sensores HAL . La ubicación en la que se almacenan en búfer los eventos del sensor (concentrador de sensores y/o FIFO de hardware) se denomina "FIFO" en esta página. Cuando el procesamiento por lotes de eventos del sensor no está activo, los eventos del sensor se informan inmediatamente a la HAL de sensores cuando está disponible.

El procesamiento por lotes puede permitir un ahorro de energía significativo al activar solo el procesador de aplicaciones principal (AP), que ejecuta Android, cuando muchos eventos de sensores están listos para ser procesados, en lugar de activarlo para cada evento individual. El ahorro de energía potencial está directamente relacionado con la cantidad de eventos que el concentrador de sensores y/o FIFO pueden almacenar en búfer: existe un mayor potencial de ahorro de energía si se pueden agrupar más eventos. El procesamiento por lotes aprovecha el uso de memoria de bajo consumo para reducir la cantidad de activaciones de puntos de acceso de alto consumo.

El procesamiento por lotes solo puede ocurrir cuando un sensor posee un FIFO de hardware y/o puede almacenar eventos dentro de un concentrador de sensores. En cualquier caso, el sensor debe informar la cantidad máxima de eventos que se pueden agrupar a la vez a través SensorInfo.fifoMaxEventCount .

Si un sensor tiene espacio reservado dentro de un FIFO, el sensor debe informar la cantidad de eventos reservados a través de SensorInfo.fifoReservedEventCount . Si FIFO está dedicado al sensor, entonces SensorInfo.fifoReservedEventCount es el tamaño de FIFO. Si el FIFO se comparte entre varios sensores, este valor puede ser cero. Un caso de uso común es permitir que un sensor use todo el FIFO si es el único sensor activo. Si hay varios sensores activos, cada sensor tiene espacio garantizado para al menos eventos SensorInfo.fifoReservedEventCount en FIFO. Si se utiliza un concentrador de sensores, la garantía se puede hacer cumplir a través del software.

Los eventos del sensor se procesan por lotes en las siguientes situaciones:

• La latencia de informe máxima actual del sensor es mayor que cero, lo que significa que los eventos del sensor se pueden retrasar hasta la latencia de informe máxima antes de que se informe a través de HAL.
• El AP está en modo de suspensión y el sensor no es un sensor de activación. En este caso, los eventos no deben activar el AP y deben almacenarse hasta que el AP se active.

Si un sensor no admite procesamiento por lotes y el AP está inactivo, solo los eventos de activación del sensor se informan al AP y los eventos que no son de activación no se deben informar al AP.

Parámetros de dosificación

Los dos parámetros que rigen el comportamiento del procesamiento por lotes son sampling_period_ns y max_report_latency_ns . sampling_period_ns determina la frecuencia con la que se genera un nuevo evento de sensor, y max_report_latency_ns determina cuánto tiempo transcurre hasta que se debe informar el evento a Sensors HAL.

muestreo_período_ns

El significado del parámetro sampling_period_ns depende del modo de informe del sensor especificado:

• Continuo: sampling_period_ns es la tasa de muestreo, es decir, la tasa a la que se generan los eventos.
• Al cambiar: sampling_period_ns limita la frecuencia de muestreo de los eventos, lo que significa que los eventos no se generan más rápido que cada nanosegundo de sampling_period_ns . Los períodos pueden ser más largos que sampling_period_ns si no se genera ningún evento y los valores medidos no cambian durante períodos prolongados. Para obtener más detalles, consulte el modo de informe sobre cambios .
• One-shot: sampling_period_ns se ignora. No tiene efecto.
• Especial: para obtener detalles sobre cómo se usa el sampling_period_ns para sensores especiales, consulte Tipos de sensor .

Para obtener más información sobre el impacto de sampling_period_ns en los diferentes modos, consulte Modos de generación de informes .

Para sensores continuos y de cambio:

• si sampling_period_ns es menor que SensorInfo.minDelay , entonces la implementación de HAL debe sujetarlo silenciosamente a max(SensorInfo.minDelay, 1ms) . Android no admite la generación de eventos a más de 1000 Hz.
• si sampling_period_ns es mayor que SensorInfo.maxDelay , la implementación de HAL debe truncarlo silenciosamente a SensorInfo.maxDelay .

Los sensores físicos a veces tienen limitaciones en las velocidades a las que pueden funcionar y la precisión de sus relojes. Para tener esto en cuenta, la frecuencia de muestreo real puede diferir de la frecuencia solicitada, siempre que cumpla con los requisitos de la siguiente tabla.

max_report_latency_ns

max_report_latency_ns establece el tiempo máximo en nanosegundos, por el cual los eventos pueden retrasarse y almacenarse en el FIFO del hardware antes de informarse a través de HAL mientras el AP está activo.

Un valor de cero significa que los eventos deben informarse tan pronto como se miden, ya sea omitiendo el FIFO por completo o vaciando el FIFO tan pronto como un evento del sensor esté presente.

Por ejemplo, un acelerómetro activado a 50 Hz con max_report_latency_ns=0 activará interrupciones 50 veces por segundo cuando el AP esté activo.

Cuando max_report_latency_ns>0 , no es necesario informar los eventos del sensor tan pronto como se detectan. Se pueden almacenar temporalmente en el FIFO e informar en lotes, siempre que ningún evento se retrase más de max_report_latency_ns nanosegundos. Esto significa que todos los eventos desde el lote anterior se registran y devuelven a la vez. Esto reduce la cantidad de interrupciones enviadas al AP y permite que el AP cambie a un modo de menor potencia (inactivo) mientras el sensor captura y agrupa datos.

Cada evento tiene una marca de tiempo asociada a él. Retrasar la hora a la que se informa un evento no afecta la marca de tiempo del evento. La marca de tiempo debe ser precisa y corresponder a la hora en que ocurrió físicamente el evento, no a la hora en que se informó.

Permitir que los eventos del sensor se almacenen temporalmente en FIFO no modifica el comportamiento de envío de eventos a HAL; los eventos de diferentes sensores se pueden intercalar y todos los eventos del mismo sensor están ordenados por tiempo.

Eventos de despertar y no despertar

Los eventos de sensor de los sensores de activación deben almacenarse en uno o más FIFO de activación. Un diseño común es tener un FIFO de activación único, grande y compartido donde los eventos de todos los sensores de activación se intercalan. Alternativamente, puede tener un FIFO de activación por sensor o tener FIFO dedicados para sensores de activación específicos y un FIFO compartido para el resto de los sensores de activación.

De manera similar, los eventos de sensor de sensores que no son de activación deben almacenarse en uno o más FIFO que no son de activación.

En todos los casos, los eventos del sensor de activación y los eventos del sensor que no son de activación no se pueden intercalar en el mismo FIFO. Los eventos de activación deben almacenarse en una FIFO de activación y los eventos que no son de activación deben almacenarse en una FIFO de no activación.

Para el FIFO de activación, el diseño FIFO único, grande y compartido proporciona los mejores beneficios de energía. Para el FIFO sin reactivación, el FIFO grande compartido único y varios diseños FIFO reservados pequeños tienen características de potencia similares. Para obtener más sugerencias sobre cómo configurar cada FIFO, consulte Prioridad de asignación de FIFO .

Comportamiento fuera del modo de suspensión

Cuando el AP está despierto (no en modo de suspensión), los eventos se almacenan temporalmente en FIFO siempre que no se retrasen más de max_report_latency .

Siempre que el AP no entre en modo de suspensión, no se descartará ni perderá ningún evento. Si los FIFO internos se llenan antes de que transcurra max_report_latency , los eventos se informan en ese momento para garantizar que no se pierda ningún evento.

Si varios sensores comparten el mismo FIFO y transcurre el max_report_latency de uno de ellos, se informan todos los eventos del FIFO, incluso si el max_report_latency de los otros sensores aún no ha transcurrido. Esto reduce el número de veces que se notifican lotes de eventos. Cuando se debe informar un evento, se informan todos los eventos de todos los sensores.

Por ejemplo, si los siguientes sensores están activados:

• acelerómetro agrupado con max_report_latency = 20 s
• giroscopio por lotes con max_report_latency = 5s

Los lotes del acelerómetro se informan al mismo tiempo que los lotes del giroscopio (cada 5 segundos), incluso si el acelerómetro y el giroscopio no comparten el mismo FIFO.

Comportamiento en modo de suspensión

El procesamiento por lotes es particularmente beneficioso para recopilar datos de sensores en segundo plano sin mantener el AP despierto. Debido a que los controladores de sensores y la implementación de HAL no pueden mantener un wake-lock*, el AP puede ingresar al modo de suspensión incluso mientras se recopilan los datos del sensor.

El comportamiento de los sensores mientras el AP está suspendido depende de si el sensor es un sensor de activación. Para obtener más detalles, consulte Sensores de activación .

Cuando se llena un FIFO que no es de activación, debe envolverse y comportarse como un búfer circular, sobrescribiendo los eventos más antiguos con los nuevos eventos reemplazando a los antiguos. max_report_latency no tiene impacto en los FIFO que no son de activación mientras está en modo de suspensión.

Cuando se llena un FIFO de activación, o cuando max_report_latency de uno de los sensores de activación, el hardware debe activar el AP e informar los datos.

En ambos casos (wake-up y non-wake-up), tan pronto como el AP sale del modo de suspensión, se produce un lote con el contenido de todos los FIFO, incluso si aún no ha transcurrido max_report_latency de algunos sensores. Esto minimiza el riesgo de que el AP tenga que reactivarse poco después de volver al modo de suspensión y, por lo tanto, minimiza el consumo de energía.

*Una excepción notable de los conductores que no pueden mantener un bloqueo de activación es cuando se activa un sensor de activación con el modo de informe continuo con max_report_latency < 1 segundo. En este caso, el controlador puede mantener un bloqueo de activación porque el AP no tiene tiempo para ingresar al modo de suspensión, ya que un evento de activación lo despertaría antes de llegar al modo de suspensión.

Precauciones a tomar al agrupar sensores de activación

Dependiendo del dispositivo, el AP puede tardar algunos milisegundos en salir completamente del modo de suspensión y comenzar a vaciar el FIFO. Se debe asignar suficiente espacio libre en el FIFO para permitir que el dispositivo salga del modo de suspensión sin que se desborde el FIFO de activación. No se perderá ningún evento y se deberá respetar max_report_latency .

Precauciones que se deben tomar al agrupar sensores de cambio sin activación

Los sensores de cambio solo generan eventos cuando el valor que están midiendo está cambiando. Si el valor medido cambia mientras el AP está en modo de suspensión, las aplicaciones esperan recibir un evento tan pronto como el AP se despierte. Debido a esto, el procesamiento por lotes de los eventos de sensor de cambio que no se activan debe realizarse con cuidado si el sensor comparte su FIFO con otros sensores. El último evento generado por cada sensor de cambio siempre debe guardarse fuera del FIFO compartido para que nunca pueda ser sobrescrito por otros eventos. Cuando el AP se despierta, después de que se hayan informado todos los eventos del FIFO, se debe informar el último evento del sensor de cambio.

Aquí hay una situación a evitar:

1. Una aplicación se registra en el contador de pasos sin activación (en cambio) y el acelerómetro sin activación (continuo), ambos comparten el mismo FIFO.
2. La aplicación recibe un evento de contador de pasos step_count=1000 steps >.
3. El AP va a suspender.
4. El usuario camina 20 pasos, lo que hace que los eventos del contador de pasos y del acelerómetro se intercalen, siendo el último evento del contador de pasos step_count = 1020 steps .
5. El usuario no se mueve durante mucho tiempo, lo que hace que los eventos del acelerómetro continúen acumulándose en el FIFO, y eventualmente sobrescriba cada evento step_count en el FIFO compartido.
6. El AP se despierta y todos los eventos del FIFO se envían a la aplicación.
7. La aplicación solo recibe eventos del acelerómetro y piensa que el usuario no caminó.

Al guardar el último evento del contador de pasos fuera de FIFO, el HAL puede informar este evento cuando el AP se activa, incluso si todos los demás eventos del contador de pasos fueron sobrescritos por eventos del acelerómetro. De esta forma, la aplicación recibe step_count = 1020 steps cuando el AP se despierta.

Implementación de procesamiento por lotes

Para ahorrar energía, el procesamiento por lotes debe implementarse sin la ayuda del AP, y se debe permitir que el AP se suspenda durante el procesamiento por lotes.

Si el procesamiento por lotes se realiza en un concentrador de sensores, se debe minimizar el uso de energía del concentrador de sensores.

La latencia máxima del informe se puede modificar en cualquier momento, en particular, mientras el sensor especificado ya está habilitado; y esto no debería resultar en la pérdida de eventos.

Prioridad de asignación FIFO

En las plataformas en las que el tamaño del búfer del concentrador de sensores y/o FIFO de hardware es limitado, los diseñadores de sistemas pueden tener que elegir cuánto FIFO reservar para cada sensor. Para ayudar con esta elección, aquí hay una lista de posibles aplicaciones cuando se implementa el procesamiento por lotes en los diferentes sensores.

Valor alto: navegación a estima para peatones de baja potencia

Tiempo objetivo de dosificación: 1 a 10 minutos

Sensores a lote:

• Detector de pasos de despertador
• Vector de rotación del juego de despertador a 5 Hz
• Barómetro despertador a 5 Hz
• Magnetómetro despertador no calibrado a 5 Hz

El procesamiento por lotes de estos datos permite realizar navegación a estima para peatones mientras se deja que el punto de acceso se suspenda.

Valor alto: actividad intermitente de potencia media/reconocimiento de gestos

Tiempo de procesamiento por lotes objetivo: 3 segundos

Sensores a lote: Acelerómetro no despertador a 50 Hz

El procesamiento por lotes de estos datos permite reconocer periódicamente actividades y gestos arbitrarios sin tener que mantener despierto el AP mientras se recopilan los datos.

Valor medio: Actividad continua de potencia media/reconocimiento de gestos

Tiempo objetivo de dosificación: 1 a 3 minutos

Sensores a lote: Acelerómetro despertador a 50 Hz

El procesamiento por lotes de estos datos permite reconocer continuamente actividades y gestos arbitrarios sin tener que mantener despierto el AP mientras se recopilan los datos.

Valor medio-alto: Reducción de carga de interrupción

Tiempo de procesamiento por lotes objetivo: < 1 segundo

Sensores a lote: cualquier sensor de alta frecuencia, normalmente no despertador.

Si el giroscopio se configura a 240 Hz, incluso el procesamiento por lotes de solo 10 eventos de giroscopio puede reducir el número de interrupciones de 240/segundo a 24/segundo.

Valor medio: recopilación continua de datos de baja frecuencia

Tiempo objetivo de dosificación: 1 a 10 minutos

Sensores a lote:

• Barómetro despertador a 1 Hz
• Sensor de humedad despertador a 1 Hz
• Otros sensores de activación de baja frecuencia a velocidades similares

Permite crear aplicaciones de monitorización a bajo consumo.

Valor medio-bajo: recopilación continua de sensores completos

Tiempo objetivo de dosificación: 1 a 10 minutos

Sensores por lotes: Todos los sensores despertadores, a altas frecuencias

Permite la recopilación completa de datos del sensor mientras deja el AP en modo de suspensión. Considere solo si el espacio FIFO no es un problema.