procesamiento por lotes

¿Qué es el procesamiento por lotes?

El procesamiento por lotes se refiere a almacenar en búfer los eventos del sensor en un concentrador de sensores y/o hardware FIFO antes de informar los eventos a través de Sensors HAL . La ubicación donde se almacenan 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 Sensors HAL cuando están disponibles.

El procesamiento por lotes puede permitir ahorros significativos de energía al activar solo el procesador de aplicaciones (AP) principal, que ejecuta Android, cuando muchos eventos de sensores están listos para ser procesados, en lugar de activarlo para cada evento individual. El ahorro potencial de energía está directamente relacionado con la cantidad de eventos que el concentrador de sensores y/o FIFO pueden almacenar en buffer: 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 AP de alta potencia.

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 de 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 el FIFO está dedicado al sensor, entonces SensorInfo.fifoReservedEventCount es el tamaño del 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 utilice todo el FIFO si es el único sensor activo. Si hay varios sensores activos, a cada sensor se le garantiza espacio para al menos eventos SensorInfo.fifoReservedEventCount en FIFO. Si se utiliza un concentrador de sensores, la garantía puede hacerse cumplir a través del software.

Los eventos del sensor se agrupan en las siguientes situaciones:

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

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

Parámetros de procesamiento por lotes

Los dos parámetros que gobiernan 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 hasta que el evento debe informarse a Sensors HAL.

periodo_muestreo_ns

Lo que significa el parámetro sampling_period_ns depende del modo de informe del sensor especificado:

• Continuo: sampling_period_ns es la frecuencia de muestreo, es decir, la velocidad a la que se generan los eventos.
• En cambio: sampling_period_ns limita la velocidad de muestreo de los eventos, lo que significa que los eventos no se generan más rápido que cada nanosegundo 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 Modo de informe sobre cambios .
• One-shot: se ignora sampling_period_ns . No tiene ningún efecto.
• Especial: para obtener detalles sobre cómo se utiliza sampling_period_ns para sensores especiales, consulte Tipos de sensores .

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

Para sensores continuos y en cambio:

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

Los sensores físicos a veces tienen limitaciones en cuanto a la velocidad a la que pueden funcionar y la precisión de sus relojes. Para tener en cuenta esto, 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, durante el cual los eventos pueden retrasarse y almacenarse en el FIFO del hardware antes de ser informados 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 esté presente un evento del sensor.

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é despierto.

Cuando max_report_latency_ns>0 , no es necesario informar los eventos del sensor tan pronto como se detectan. Se pueden almacenar temporalmente en 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 se devuelven a la vez. Esto reduce la cantidad de interrupciones enviadas al AP y permite que el AP cambie a un modo de menor energía (inactivo) mientras el sensor captura y procesa datos por lotes.

Cada evento tiene una marca de tiempo asociada. 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 en el tiempo.

Eventos de despertar y no despertar

Los eventos de los sensores de activación deben almacenarse en uno o más FIFO de activación. Un diseño común es tener una FIFO de activación única, grande y compartida donde se intercalan los eventos de todos los sensores de activación. 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 los 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 que no es de 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 activación, el diseño único y grande de FIFO compartido y varios diseños de 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á activo (no en modo suspendido), los eventos se almacenan temporalmente en FIFO siempre que no se retrasen más de max_report_latency .

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

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

Por ejemplo, si se activan los siguientes sensores:

• acelerómetro por lotes con max_report_latency = 20s
• giroscopio agrupado 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 suspendido

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 bloqueo de activación*, el AP puede ingresar al modo de suspensión incluso mientras se recopilan 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 despertador .

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

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

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

*Una excepción notable de los conductores a los que no se les permite 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 conductor puede mantener un bloqueo de activación porque el AP no tiene tiempo de ingresar al modo de suspensión, ya que un evento de activación lo despertaría antes de alcanzar el modo de suspensión.

Precauciones al agrupar sensores de despertador por lotes

Dependiendo del dispositivo, el AP puede tardar unos 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 el FIFO de activación se desborde. No se perderá ningún evento y se debe respetar max_report_latency .

Precauciones al agrupar sensores que no se activan al cambiar

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 active. Debido a esto, el procesamiento por lotes de eventos de sensores que no se activan al cambiar se debe realizar 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 despertar (en cambio) y en el acelerómetro sin despertar (continuo), ambos comparten el mismo FIFO.
2. La aplicación recibe un evento de contador de pasos step_count=1000 steps >.
3. La AP va a suspender.
4. El usuario camina 20 pasos, lo que provoca 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 sigan acumulándose en el FIFO y, finalmente, sobrescriban cada evento step_count en el FIFO compartido.
6. AP se activa y todos los eventos del FIFO se envían a la aplicación.
7. La aplicación recibe sólo eventos del acelerómetro y piensa que el usuario no caminó.

Al guardar el último evento del contador de pasos fuera del FIFO, 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 manera, la aplicación recibe step_count = 1020 steps cuando el AP se activa.

Implementar procesamiento por lotes

Para ahorrar energía, se debe implementar el procesamiento por lotes 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 plataformas en las que el tamaño del búfer del concentrador de sensores y/o FIFO de hardware es limitado, es posible que los diseñadores de sistemas tengan 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.

Alto valor: navegación a estima para peatones de baja potencia

Tiempo de procesamiento por lotes objetivo: de 1 a 10 minutos

Sensores para lotear:

• Detector de pasos para despertar
• Vector de rotación del juego de despertador a 5 Hz
• Barómetro del despertador a 5 Hz
• Despertador magnetómetro no calibrado a 5 Hz

El procesamiento por lotes de estos datos permite realizar una navegación a estima de peatones mientras se deja que el AP 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 sin despertar a 50 Hz

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

Valor medio: potencia media actividad continua/reconocimiento de gestos

Tiempo de procesamiento por lotes objetivo: 1 a 3 minutos

Sensores para lotear: Acelerómetro de despertador a 50 Hz

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

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

Tiempo de procesamiento por lotes objetivo: < 1 segundo

Sensores para lotear: cualquier sensor de alta frecuencia, generalmente sin activación.

Si el giroscopio está configurado a 240 Hz, incluso agrupar solo 10 eventos de giroscopio puede reducir la cantidad de interrupciones de 240/segundo a 24/segundo.

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

Tiempo de procesamiento por lotes objetivo: de 1 a 10 minutos

Sensores para lotear:

• Barómetro del despertador a 1 Hz
• Sensor de humedad para despertar a 1 Hz
• Otros sensores de despertador 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 de procesamiento por lotes objetivo: de 1 a 10 minutos

Sensores para lotear: Todos los sensores de despertador, en altas frecuencias

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