Lotes

O que é o processamento em lote?

O agrupamento se refere ao armazenamento em buffer de eventos do sensor em um hub de sensores e/ou FIFO de hardware antes de informar os eventos pela Sensors HAL. O local em que os eventos do sensor são armazenados em buffer (hub do sensor e/ou FIFO de hardware) é chamado de "FIFO" nesta página. Quando o agrupamento de eventos do sensor não está ativo, os eventos do sensor são informados imediatamente ao HAL de sensores quando disponíveis.

O processamento em lote pode permitir uma economia de energia significativa, ativando apenas o processador principal de aplicativos (AP, na sigla em inglês), 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 de energia potencial está diretamente relacionada ao número de eventos que o hub do sensor e/ou FIFO podem armazenar em buffer: há um maior potencial de economia de energia se mais eventos puderem ser agrupados. O agrupamento aproveita o uso de memória de baixa potência para reduzir o número de ativações de AP de alta potência.

O agrupamento só pode ocorrer quando um sensor tem um FIFO de hardware e/ou pode armazenar eventos em buffer em um hub de sensor. Em ambos os casos, o sensor precisa informar o número máximo de eventos que podem ser agrupados de uma só vez usando SensorInfo.fifoMaxEventCount.

Se um sensor tiver espaço reservado em uma FIFO, ele precisará informar 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 compartilhado entre vários sensores, esse valor poderá ser zero. Um caso de uso comum é permitir que um sensor use todo o FIFO se ele for o único sensor ativo. Se vários sensores estiverem ativos, cada sensor terá espaço garantido para pelo menos SensorInfo.fifoReservedEventCount eventos na fila FIFO. Se um hub de sensores for usado, a garantia poderá ser aplicada pelo software.

Os eventos de sensor são agrupados nas seguintes situações:

  • A latência máxima atual do sensor é maior que zero, o que significa que os eventos do sensor podem ser atrasados até a latência máxima antes de serem informados pelo HAL.
  • O AP está no modo de suspensão, e o sensor não é de ativação. Nesse caso, os eventos não podem ativar o AP e precisam ser armazenados até que ele seja ativado.

Se um sensor não oferecer suporte a lotes e o AP estiver em repouso, apenas os eventos de ativação do sensor serão informados ao AP, e os eventos que não são de ativação não serão informados ao AP.

Parâmetros de lote

Os dois parâmetros que governam o comportamento do agrupamento 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 por quanto tempo o evento precisa ser informado ao HAL de sensores.

sampling_period_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 em que os eventos são gerados.
  • Na mudança: sampling_period_ns limita a taxa de amostragem de eventos, o que significa que os eventos são gerados a cada sampling_period_ns nanossegundos. Os períodos podem ser mais longos que sampling_period_ns se nenhum evento for gerado e os valores medidos não mudarem por períodos longos. Para mais detalhes, consulte o modo de relatório na mudança.
  • One-shot: sampling_period_ns é ignorado. Ela não tem efeito.
  • Especial: para saber como sampling_period_ns é usado para sensores especiais, consulte Tipos de sensores.

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

Para sensores contínuos e de mudança:

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

Às vezes, os sensores físicos têm limitações nas taxas de execução e na precisão dos relógios. Para isso, a frequência de amostragem real pode ser diferente da frequência solicitada, desde que atenda aos requisitos da tabela abaixo.

Se a frequência solicitada for

Então, a frequência real precisa ser

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

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

entre a 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 1.100 Hz

max_report_latency_ns

max_report_latency_ns define o tempo máximo em nanossegundos, em que os eventos podem ser atrasados e armazenados no FIFO de hardware antes de serem informados pelo HAL enquanto o AP está ativo.

Um valor de zero significa que os eventos precisam ser informados assim que são medidos, ignorando a FIFO ou esvaziando-a assim que um evento do sensor está presente.

Por exemplo, um acelerômetro ativado a 50 Hz com max_report_latency_ns=0 vai acionar 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 informados assim que são detectados. Eles podem ser armazenados temporariamente no FIFO e informados 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 ele mude para um modo de energia menor (inativo) enquanto o sensor captura e agrupa dados.

Cada evento tem um carimbo de data/hora associado a ele. A demora no momento em que um evento é informado não afeta o carimbo de data/hora. O carimbo de data/hora precisa ser preciso e corresponder ao momento em que o evento ocorreu fisicamente, não ao momento em que foi informado.

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

Eventos de ativação e não ativação

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

Da mesma forma, os eventos de sensores de sensores que não despertam precisam ser armazenados em uma ou mais FIFOs que não despertam.

Em todos os casos, os eventos de sensor de ativação e os eventos de sensor sem ativação não podem ser intercalados no mesmo FIFO. Os eventos de ativação precisam ser armazenados em uma FIFO de ativação, e os eventos não de ativação precisam ser armazenados em uma FIFO não de ativação.

Para o FIFO de ativação, o design FIFO único, grande e compartilhado oferece os melhores benefícios de energia. Para a FIFO sem despertar, a FIFO compartilhada única e grande e vários designs de FIFOs reservados pequenos têm características de energia semelhantes. Para 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 está no modo de suspensão), os eventos são armazenados temporariamente em FIFOs, desde que não sejam atrasados por mais de max_report_latency.

Enquanto o AP não entrar no modo de suspensão, nenhum evento será descartado ou perdido. Se as FIFOs internas ficarem cheias antes do término do max_report_latency, os eventos serão informados nesse momento para garantir que nenhum evento seja perdido.

Se vários sensores compartilharem a mesma FIFO e o max_report_latency de um deles expirar, todos os eventos da FIFO serão informados, mesmo que o max_report_latency dos outros sensores ainda não tenha expirado. Isso reduz o número de vezes que os lotes de eventos são informados. Quando um evento precisa ser informado, todos os eventos de todos os sensores são informados.

Por exemplo, se os seguintes sensores forem ativados:

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

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

Comportamento no modo de suspensão

O agrupamento é especialmente benéfico para coletar dados do sensor em segundo plano sem manter o AP ativo. Como os drivers do sensor e a implementação do HAL não podem manter um bloqueio de ativação*, 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 ativação. Para mais detalhes, consulte Sensores de ativação.

Quando um FIFO sem ativação é preenchido, ele precisa ser agrupado e se comportar como um buffer circular, substituindo eventos mais antigos pelos novos, substituindo os antigos. max_report_latency não tem impacto em FIFOs que não despertam no modo de suspensão.

Quando um FIFO de ativação fica cheio ou quando o max_report_latency de um dos sensores de ativação expira, o hardware precisa ativar o AP e informar os dados.

Em ambos os casos (ativação e não ativação), assim que o AP sai do modo de suspensão, um lote é produzido com o conteúdo de todos os FIFOs, mesmo que max_report_latency de alguns sensores ainda não tenham decorrido. Isso minimiza o risco de o AP precisar ser ativado novamente logo após retornar ao modo de suspensão e, portanto, minimiza o consumo de energia.

*Uma exceção notável de drivers que não podem manter um bloqueio de ativação é quando um sensor de ativação com o modo de relatório contínuo é ativado com max_report_latency < 1 segundo. Nesse caso, o driver pode manter um bloqueio de ativação porque o AP não tem tempo para entrar no modo de suspensão, já que ele é ativado por um evento de ativação antes de chegar ao 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 limpar o FIFO. É necessário alocar espaço suficiente no FIFO para que o dispositivo saia do modo de suspensão sem que o FIFO de ativação transborde. Nenhum evento será perdido, e o max_report_latency precisa ser respeitado.

Precauções ao agrupar sensores de mudança sem ativação

Os sensores de mudança geram eventos apenas quando o valor que eles estão medindo está mudando. Se o valor medido mudar enquanto o AP estiver no modo de suspensão, os aplicativos vão esperar receber um evento assim que o AP for ativado. Por isso, o agrupamento de eventos de sensor de não ativação na mudança precisa ser realizado com cuidado se o sensor compartilhar o FIFO com outros sensores. O último evento gerado por cada sensor de mudança precisa ser salvo fora do FIFO compartilhado para que nunca seja substituído por outros eventos. Quando o AP é ativado, depois que todos os eventos do FIFO são informados, o último evento do sensor de mudança precisa ser informado.

Esta é uma situação a evitar:

  1. Um aplicativo se registra no contador de etapas sem despertar (na mudança) 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 stepscode>.
  3. O AP vai ser suspenso.
  4. O usuário dá 20 passos, fazendo com que os eventos do pedômetro e do acelerômetro sejam intercalados, sendo o último evento do pedômetro step_count = 1020 steps.
  5. O usuário não se move por um longo período, fazendo com que os eventos do acelerômetro continuem se acumulando na FIFO, eventualmente substituindo todos os eventos step_count na FIFO compartilhada.
  6. O AP é ativado, e todos os eventos do FIFO são enviados para o aplicativo.
  7. O aplicativo recebe apenas eventos do acelerômetro e pensa que o usuário não caminhou.

Ao salvar o último evento do contador de passos fora do FIFO, o HAL poderá informar esse evento quando o AP for ativado, mesmo que todos os outros eventos do contador de passos tenham sido substituídos por eventos do acelerômetro. Dessa forma, o aplicativo recebe step_count = 1020 steps quando o AP é ativado.

Implementar o envio em lote

Para economizar energia, a execução em lote precisa ser implementada sem a ajuda do AP, e o AP precisa ser suspenso durante a execução em lote.

Se a execução em lote for realizada em um hub de sensores, o consumo de energia do hub precisa ser minimizado.

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

Prioridade de alocação FIFO

Em plataformas em que o tamanho do buffer do FIFO de hardware e/ou do hub do sensor é limitado, os designers do sistema podem ter que escolher a quantidade de FIFO a ser reservada para cada sensor. Para ajudar nessa escolha, confira uma lista de possíveis aplicações quando o lote for implementado nos diferentes sensores.

Valor alto: estimativa de posição por dead reckoning para pedestres de baixa potência

Tempo de lote desejado: 1 a 10 minutos

Sensores para lote:

  • Detector de passos de ativação
  • Vetor de rotação de ativação do jogo a 5 Hz
  • Barômetro de ativação a 5 Hz
  • Despertador do magnetômetro não calibrado a 5 Hz

Agrupar esses dados permite realizar a navegação estimada para pedestres enquanto o AP é suspenso.

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

Tempo de lote desejado: 3 segundos

Sensores para lote: acelerômetro sem ativação a 50 Hz

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

Valor médio: reconhecimento de atividade/gesto contínuo de potência média

Tempo de lote desejado: de 1 a 3 minutos

Sensores em lote: acelerômetro de ativação a 50 Hz

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

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

Tempo de lote desejado: < 1 segundo

Sensores em lote: qualquer sensor de alta frequência, geralmente sem ativação.

Se o giroscópio estiver definido em 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 desejado: 1 a 10 minutos

Sensores para lote:

  • Barômetro de ativação a 1 Hz
  • Ativar o sensor de umidade a 1 Hz
  • Outros sensores de ativação de baixa frequência com taxas semelhantes

Permite criar aplicativos de monitoramento com pouca energia.

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

Tempo de lote desejado: 1 a 10 minutos

Sensores para lote: todos os sensores de ativação, em altas frequências

Permite a coleta completa de dados do sensor, deixando o AP no modo de suspensão. Considere isso apenas se o espaço FIFO não for um problema.