Lote

O que é loteamento?

Batching 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 Sensors HAL . O local onde os eventos do sensor são armazenados em buffer (hub do sensor e/ou FIFO de hardware) são referidos 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 Sensors HAL quando disponíveis.

Os lotes podem permitir economias de energia significativas apenas ativando o processador principal de aplicativos (AP), que executa o Android, quando muitos eventos do sensor estiverem prontos para serem processados, em vez de ativá-lo para cada evento individual. A economia de energia potencial 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. Os lotes aproveitam o uso de memória de baixo consumo para reduzir o número de ativações de AP 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 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 compartilhado 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 um hub de sensor for usado, a garantia pode ser aplicada por meio de software.

Os eventos do sensor são agrupados 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 por meio do HAL.
• O AP está no modo de suspensão e o sensor é um sensor sem despertar. Nesse caso, os eventos não devem acordar o AP e devem ser armazenados até que o AP acorde.

Se um sensor não oferecer suporte a lotes e o AP estiver em suspensão, somente os eventos do sensor de ativação serão relatados ao AP e os eventos de não 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 a frequência com que um novo evento de sensor é gerado e max_report_latency_ns determina quanto tempo até que o evento deva ser relatado ao Sensors HAL.

sampling_period_ns

O significado do parâmetro sampling_period_ns 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 a 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 o modo de relatório de 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 sensor .

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 de HAL deverá fixá-lo silenciosamente em max(SensorInfo.minDelay, 1ms) . O Android não suporta a geração de eventos em mais de 1000 Hz.
• se sampling_period_ns for maior que SensorInfo.maxDelay , a implementação de HAL deverá truncá-lo silenciosamente para SensorInfo.maxDelay .

Os sensores físicos às vezes têm limitações nas taxas em que podem ser executados 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 satisfaça os requisitos da tabela abaixo.

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 de 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 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 relatados assim que forem 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 devolvidos de uma só vez. Isso reduz a quantidade de interrupções enviadas ao AP e permite que o AP alterne para um modo de menor consumo de energia (inativo) enquanto o sensor está capturando e agrupando dados.

Cada evento tem um timestamp associado a ele. Atrasar a hora 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 à hora em que o evento aconteceu fisicamente, não à hora em que foi relatado.

Permitir que os eventos do sensor 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 por tempo.

Eventos de despertar e não despertar

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

Da mesma forma, eventos de sensores de sensores sem despertar devem ser armazenados em uma ou mais FIFOs sem despertar.

Em todos os casos, eventos de sensor de despertar e eventos de sensor de não 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 único, grande FIFO compartilhado e vários pequenos projetos de FIFOs reservados têm características de potência semelhantes. Para obter mais sugestões sobre como configurar cada FIFO, consulte Prioridade de alocação de FIFO .

Comportamento fora do modo de suspensão

Quando o AP está acordado (não 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 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 expira, todos os eventos do FIFO são relatados, mesmo que o max_report_latency dos outros sensores ainda não tenha decorrido. Isso reduz o número de vezes que os lotes de eventos são relatados. Quando um evento deve ser relatado, todos os eventos de todos os sensores são relatados.

Por exemplo, se os seguintes sensores estiverem 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 relatados 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 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 acordado. Como os drivers do sensor e a implementação de 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 não-despertador é preenchido, ele deve se envolver e 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 sem despertar enquanto estiver no modo de suspensão.

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

Em ambos os casos (acordar e não acordar), assim que o AP sai do modo de suspensão, é produzido um lote com o conteúdo de todas as FIFOs, mesmo que max_report_latency de alguns sensores ainda não tenha decorrido. Isso minimiza o risco de o 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 motoristas que não podem manter um wake lock é quando um sensor de despertar com o modo de relatório contínuo é ativado com max_report_latency < 1 segundo. Nesse caso, o driver pode manter um wake lock porque o AP não tem tempo para entrar no modo de suspensão, pois seria despertado por um evento de ativação antes de atingir o modo de suspensão.

Precauções a serem tomadas ao agrupar sensores de ativação em lote

Dependendo do dispositivo, pode levar alguns milissegundos para o AP sair completamente do modo de suspensão e começar a liberar o FIFO. Deve ser alocado espaço de cabeça suficiente no FIFO para permitir que o dispositivo saia do modo de suspensão sem o estouro do FIFO de ativação. Nenhum evento deve ser perdido, e a max_report_latency deve ser respeitada.

Precauções a serem tomadas ao agrupar sensores que não despertam na 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 acordar. Por causa disso, o lote de eventos de sensor de não ativação na mudança deve ser realizado 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 desperta, após todos os eventos do FIFO terem sido relatados, o último evento do sensor em mudança deve ser relatado.

Aqui está uma situação a evitar:

1. Um aplicativo se registra no contador de passos sem despertar (na mudança) e no acelerômetro sem despertar (contínuo), ambos compartilhando o mesmo FIFO.
2. A aplicação recebe um evento de contador de passos step_count=1000 steps code>.
3. O AP vai para 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 substituindo cada evento step_count no FIFO compartilhado.
6. O AP acorda e todos os eventos do FIFO são enviados para o aplicativo.
7. O aplicativo recebe apenas eventos do acelerômetro e acha que o usuário não andou.

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

Implementando lotes

Para economizar energia, o batching deve ser implementado sem a ajuda do AP, e o AP deve ser suspenso durante o batching.

Se o lote for executado em um hub de sensor, o uso de energia do hub de sensor deve 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 FIFO de hardware e/ou o tamanho do buffer 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 aplicações possíveis quando o batching é implementado nos diferentes sensores.

Alto valor: contagem de pedestres de baixa potência

Tempo de lote desejado: 1 a 10 minutos

Sensores para lote:

• Detetor de degrau 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 ativação em 5 Hz

O agrupamento desses dados permite realizar a contagem de mortos de pedestres enquanto deixa o AP em suspensão.

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

Tempo de lote desejado: 3 segundos

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

O lote desses dados permite reconhecer periodicamente atividades e gestos arbitrários sem ter que manter o AP acordado enquanto os dados são coletados.

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

Tempo de lote desejado: 1 a 3 minutos

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

O lote desses dados permite reconhecer continuamente atividades e gestos arbitrários sem ter que manter o AP acordado 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 desejado: 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 aplicativos de monitoramento com baixo consumo de 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 despertar, em altas frequências

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