Lote

O que é lote?

O lote refere-se ao armazenamento em buffer de eventos de sensor em um hub de sensor e/ou FIFO de hardware antes de relatar os eventos por meio do HAL de sensores . O local onde os eventos do sensor são armazenados em buffer (hub do sensor e/ou FIFO de hardware) é referido como "FIFO" nesta página. Quando o lote de eventos do sensor não está ativo, os eventos do sensor são imediatamente relatados ao HAL dos Sensores, quando disponíveis.

O processamento em lote pode permitir economias de energia significativas apenas ativando o processador de aplicativos (AP) principal, que executa o Android, quando muitos eventos do sensor estão prontos para serem processados, em vez de ativá-lo para cada evento individual. A economia potencial de energia está diretamente correlacionada ao número de eventos que o hub do sensor e/ou FIFO pode armazenar em buffer: há um potencial maior de economia de energia se mais eventos puderem ser agrupados. O lote aproveita o uso de memória de baixo consumo de energia para reduzir o número de ativações de pontos de acesso de alta potência.

O lote pode ocorrer somente quando um sensor possui um FIFO de hardware e/ou pode armazenar eventos em buffer dentro de um hub de sensor. Em ambos os casos, o sensor deve relatar o número máximo de eventos que podem ser agrupados em lote de uma vez por meio de SensorInfo.fifoMaxEventCount .

Se um sensor tiver espaço reservado em um FIFO, o sensor deverá relatar o número de eventos reservados por meio de SensorInfo.fifoReservedEventCount . Se o FIFO for dedicado ao sensor, SensorInfo.fifoReservedEventCount será o tamanho do FIFO. Se o FIFO for partilhado entre vários sensores, este valor pode ser zero. Um caso de uso comum é permitir que um sensor use todo o FIFO se for o único sensor ativo. Se vários sensores estiverem ativos, cada sensor terá espaço garantido para pelo menos eventos SensorInfo.fifoReservedEventCount no FIFO. Se for utilizado um hub de sensor, a garantia poderá ser executada através de software.

Os eventos do sensor são agrupados em lote nas seguintes situações:

  • A latência máxima atual do relatório do sensor é maior que zero, o que significa que os eventos do sensor podem ser atrasados ​​até a latência máxima do relatório antes de serem relatados através do HAL.
  • O AP está no modo suspenso e o sensor é um sensor sem ativação. Neste caso, os eventos não devem despertar o AP e devem ser armazenados até que o AP acorde.

Se um sensor não suportar lotes e o AP estiver adormecido, apenas os eventos do sensor de ativação serão relatados ao AP e os eventos que não forem de ativação não deverão ser relatados ao AP.

Parâmetros de lote

Os dois parâmetros que controlam o comportamento do lote são sampling_period_ns e max_report_latency_ns . sampling_period_ns determina com que frequência um novo evento de sensor é gerado e max_report_latency_ns determina quanto tempo até que o evento deve ser relatado ao Sensors HAL.

amostragem_período_ns

O que o parâmetro sampling_period_ns significa depende do modo de relatório do sensor especificado:

  • Contínuo: sampling_period_ns é a taxa de amostragem, ou seja, a taxa na qual os eventos são gerados.
  • Na mudança: sampling_period_ns limita a taxa de amostragem de eventos, o que significa que os eventos não são gerados mais rápido do que cada sampling_period_ns nanossegundos. Os períodos podem ser maiores que sampling_period_ns se nenhum evento for gerado e os valores medidos não mudarem por longos períodos. Para obter mais detalhes, consulte modo de relatório após alteração .
  • One-shot: sampling_period_ns é ignorado. Não tem efeito.
  • Especial: para obter detalhes sobre como sampling_period_ns é usado para sensores especiais, consulte Tipos de sensores .

Para obter mais informações sobre o impacto de sampling_period_ns nos diferentes modos, consulte Modos de relatório .

Para sensores contínuos e em mudança:

  • se sampling_period_ns for menor que SensorInfo.minDelay , a implementação HAL deverá fixá-lo silenciosamente em max(SensorInfo.minDelay, 1ms) . O Android não oferece suporte à geração de eventos em mais de 1.000 Hz.
  • se sampling_period_ns for maior que SensorInfo.maxDelay , a implementação HAL deverá truncá-lo silenciosamente para SensorInfo.maxDelay .

Os sensores físicos às vezes têm limitações nas taxas de operação e na precisão de seus relógios. Para levar em conta isso, a frequência de amostragem real pode diferir da frequência solicitada, desde que atenda aos requisitos da tabela abaixo.

Se a frequência solicitada for

Então a frequência real deve ser

abaixo da frequência mínima (<1/maxDelay)

entre 90% e 110% da frequência mínima

entre frequência mínima e máxima

entre 90% e 220% da frequência solicitada

acima da frequência máxima (>1/minDelay)

entre 90% e 110% da frequência máxima e abaixo de 1100 Hz

max_report_latency_ns

max_report_latency_ns define o tempo máximo em nanossegundos, pelo qual os eventos podem ser atrasados ​​e armazenados no FIFO de hardware antes de serem relatados através do HAL enquanto o AP está ativo.

Um valor zero significa que os eventos devem ser relatados assim que forem medidos, ignorando completamente o FIFO ou esvaziando o FIFO assim que um evento do sensor estiver presente.

Por exemplo, um acelerômetro ativado em 50 Hz com max_report_latency_ns=0 irá disparar interrupções 50 vezes por segundo quando o AP estiver ativo.

Quando max_report_latency_ns>0 , os eventos do sensor não precisam ser relatados assim que são detectados. Eles podem ser armazenados temporariamente no FIFO e relatados em lotes, desde que nenhum evento seja atrasado por mais de max_report_latency_ns nanossegundos. Isso significa que todos os eventos desde o lote anterior são registrados e retornados de uma só vez. Isso reduz a quantidade de interrupções enviadas ao AP e permite que o AP mude para um modo de menor consumo de energia (inativo) enquanto o sensor captura e agrupa dados em lote.

Cada evento tem um carimbo de data/hora associado a ele. Atrasar o horário em que um evento é relatado não afeta o carimbo de data/hora do evento. O carimbo de data/hora deve ser preciso e corresponder ao horário em que o evento ocorreu fisicamente, e não ao horário em que foi relatado.

Permitir que eventos de sensores sejam armazenados temporariamente no FIFO não modifica o comportamento de envio de eventos ao HAL; eventos de diferentes sensores podem ser intercalados e todos os eventos do mesmo sensor são ordenados no tempo.

Eventos de despertar e não despertar

Os eventos dos sensores de despertar devem ser armazenados em um ou mais FIFOs de despertar. Um projeto comum é ter um FIFO de ativação único, grande e compartilhado, onde os eventos de todos os sensores de ativação são intercalados. Como alternativa, você pode ter um FIFO de despertar por sensor ou ter FIFOs dedicados para sensores de despertar específicos e um FIFO compartilhado para o restante dos sensores de despertar.

Da mesma forma, os eventos de sensores provenientes de sensores não ativados devem ser armazenados em um ou mais FIFOs não ativados.

Em todos os casos, os eventos do sensor de despertar e os eventos do sensor que não são de despertar não podem ser intercalados no mesmo FIFO. Os eventos de despertar devem ser armazenados em um FIFO de despertar, e os eventos de não despertar devem ser armazenados em um FIFO de não despertar.

Para o FIFO de ativação, o design FIFO único, grande e compartilhado oferece os melhores benefícios de energia. Para o FIFO sem despertar, o FIFO único e grande compartilhado e vários projetos de FIFOs pequenos reservados têm características de potência semelhantes. Para obter mais sugestões sobre como configurar cada FIFO, consulte Prioridade de alocação FIFO .

Comportamento fora do modo de suspensão

Quando o AP está ativo (não no modo de suspensão), os eventos são armazenados temporariamente em FIFOs, desde que não sejam atrasados ​​mais do que max_report_latency .

Contanto que o AP não entre no modo de suspensão, nenhum evento será descartado ou perdido. Se os FIFOs internos ficarem cheios antes de max_report_latency expirar, os eventos serão relatados nesse ponto para garantir que nenhum evento seja perdido.

Se vários sensores compartilham o mesmo FIFO e o max_report_latency de um deles expirar, todos os eventos do FIFO serão reportados, mesmo que o max_report_latency dos outros sensores ainda não tenha decorrido. Isso reduz o número de vezes que lotes de eventos são relatados. Quando um evento precisar ser relatado, todos os eventos de todos os sensores serão relatados.

Por exemplo, se os seguintes sensores estiverem ativados:

  • acelerômetro agrupado com max_report_latency = 20s
  • giroscópio agrupado com max_report_latency = 5s

Os lotes do acelerômetro são relatados ao mesmo tempo que os lotes do giroscópio são relatados (a cada 5 segundos), mesmo que o acelerômetro e o giroscópio não compartilhem o mesmo FIFO.

Comportamento no modo de suspensão

O lote é particularmente benéfico para coletar dados do sensor em segundo plano sem manter o AP ativo. Como os drivers do sensor e a implementação HAL não têm permissão para manter um wake-lock*, o AP pode entrar no modo de suspensão mesmo enquanto os dados do sensor estão sendo coletados.

O comportamento dos sensores enquanto o AP está suspenso depende se o sensor é um sensor de despertar. Para obter mais detalhes, consulte Sensores de despertar .

Quando um FIFO sem despertar é preenchido, ele deve se comportar como um buffer circular, substituindo os eventos mais antigos pelos novos eventos, substituindo os antigos. max_report_latency não tem impacto em FIFOs que não são ativados durante o modo de suspensão.

Quando um FIFO de ativação é preenchido ou quando o max_report_latency de um dos sensores de ativação expira, o hardware deve ativar o AP e reportar os dados.

Em ambos os casos (despertar e não despertar), assim que o AP sai do modo de suspensão, é produzido um lote com o conteúdo de todos os FIFOs, mesmo que max_report_latency de alguns sensores ainda não tenha decorrido. Isto minimiza o risco do AP ter que acordar novamente logo após retornar ao modo de suspensão e, portanto, minimiza o consumo de energia.

*Uma exceção notável de que os motoristas não podem manter um wake lock é quando um sensor de despertar com modo de relatório contínuo é ativado com max_report_latency < 1 segundo. Neste caso, o driver pode manter um wake lock porque o AP não tem tempo para entrar no modo de suspensão, pois seria acordado por um evento de ativação antes de atingir o modo de suspensão.

Precauções ao agrupar sensores de ativação

Dependendo do dispositivo, pode levar alguns milissegundos para que o AP saia completamente do modo de suspensão e comece a liberar o FIFO. Espaço suficiente deve ser alocado no FIFO para permitir que o dispositivo saia do modo de suspensão sem transbordar o FIFO de ativação. Nenhum evento será perdido e o max_report_latency deve ser respeitado.

Precauções ao agrupar sensores sem despertar durante a mudança

Os sensores on-change só geram eventos quando o valor que estão medindo está mudando. Se o valor medido mudar enquanto o AP estiver no modo de suspensão, os aplicativos esperam receber um evento assim que o AP for ativado. Por causa disso, o lote de eventos de sensor que não são ativados durante a mudança deve ser executado com cuidado se o sensor compartilhar seu FIFO com outros sensores. O último evento gerado por cada sensor on-change deve sempre ser salvo fora do FIFO compartilhado para que nunca possa ser substituído por outros eventos. Quando o AP acordar, após todos os eventos do FIFO terem sido relatados, o último evento do sensor durante a mudança deverá ser relatado.

Aqui está uma situação a evitar:

  1. Um aplicativo é registrado no contador de passos sem despertar (on-change) e no acelerômetro sem despertar (contínuo), ambos compartilhando o mesmo FIFO.
  2. O aplicativo recebe um evento de contador de passos step_count=1000 steps code>.
  3. A AP vai suspender.
  4. O usuário caminha 20 passos, fazendo com que os eventos do contador de passos e do acelerômetro sejam intercalados, sendo o último evento do contador de passos step_count = 1020 steps .
  5. O usuário não se move por um longo tempo, fazendo com que os eventos do acelerômetro continuem se acumulando no FIFO, eventualmente sobrescrevendo cada evento step_count no FIFO compartilhado.
  6. O AP é ativado e todos os eventos do FIFO são enviados para a aplicação.
  7. A aplicação recebe apenas eventos do acelerômetro e pensa que o usuário não andou.

Ao salvar o último evento do contador de passos fora do FIFO, o HAL pode reportar este evento quando o AP acordar, mesmo que todos os outros eventos do contador de passos tenham sido substituídos por eventos do acelerômetro. Dessa forma, a aplicação recebe step_count = 1020 steps quando o AP é ativado.

Implementar lotes

Para economizar energia, o processamento em lote deve ser implementado sem a ajuda do AP, e o AP deve poder ser suspenso durante o processamento em lote.

Se o lote for realizado em um hub de sensor, o uso de energia do hub de sensor deverá ser minimizado.

A latência máxima do relatório pode ser modificada a qualquer momento, principalmente enquanto o sensor especificado já estiver habilitado; e isso não deve resultar na perda de eventos.

Prioridade de alocação FIFO

Em plataformas nas quais o tamanho do buffer do hardware FIFO e/ou do hub do sensor é limitado, os projetistas do sistema podem ter que escolher quanto FIFO reservar para cada sensor. Para ajudar nessa escolha, aqui está uma lista de possíveis aplicações quando o batching é implementado nos diferentes sensores.

Valor alto: cálculo morto de pedestres de baixa potência

Tempo de lote alvo: 1 a 10 minutos

Sensores para lote:

  • Detector de passos de despertar
  • Vetor de rotação do jogo de despertar a 5 Hz
  • Barômetro de despertar a 5 Hz
  • Magnetômetro não calibrado de despertar a 5 Hz

O agrupamento desses dados permite realizar o cálculo da mortandade de pedestres e, ao mesmo tempo, deixar o AP entrar em suspensão.

Valor alto: atividade intermitente de potência média/reconhecimento de gestos

Tempo de lote alvo: 3 segundos

Sensores para lote: Acelerômetro sem despertar a 50 Hz

O agrupamento desses dados permite reconhecer periodicamente atividades e gestos arbitrários sem a necessidade de manter o AP ativo enquanto os dados são coletados.

Valor médio: atividade contínua de potência média/reconhecimento de gestos

Tempo de lote alvo: 1 a 3 minutos

Sensores para lote: Acelerômetro de despertar a 50 Hz

O agrupamento desses dados permite reconhecer continuamente atividades e gestos arbitrários sem a necessidade de manter o AP ativo enquanto os dados são coletados.

Valor médio-alto: redução de carga de interrupção

Tempo de lote desejado: <1 segundo

Sensores para lote: qualquer sensor de alta frequência, geralmente sem despertar.

Se o giroscópio estiver configurado para 240 Hz, mesmo agrupar apenas 10 eventos de giroscópio pode reduzir o número de interrupções de 240/segundo para 24/segundo.

Valor médio: coleta contínua de dados de baixa frequência

Tempo de lote alvo: 1 a 10 minutos

Sensores para lote:

  • Barômetro de despertar a 1 Hz
  • Sensor de umidade de despertar a 1 Hz
  • Outros sensores de despertar de baixa frequência em taxas semelhantes

Permite criar aplicações de monitoramento com baixo consumo de energia.

Valor médio-baixo: Coleta contínua de sensores completos

Tempo de lote alvo: 1 a 10 minutos

Sensores em lote: Todos os sensores de despertar, em altas frequências

Permite a coleta completa de dados do sensor enquanto deixa o AP em modo suspenso. Considere apenas se o espaço FIFO não for um problema.