Batch

Cos'è il raggruppamento?

Il batching si riferisce al buffering degli eventi dei sensori in un hub di sensori e/o in un FIFO hardware prima di segnalare gli eventi tramite l' HAL dei sensori . La posizione in cui vengono memorizzati nel buffer gli eventi del sensore (hub sensore e/o FIFO hardware) viene definita "FIFO" in questa pagina. Quando l'invio in batch degli eventi del sensore non è attivo, gli eventi del sensore vengono immediatamente segnalati all'HAL dei sensori quando disponibile.

Il batching può consentire notevoli risparmi energetici riattivando il processore delle applicazioni principali (AP), che esegue Android, solo quando molti eventi del sensore sono pronti per essere elaborati, invece di riattivarlo per ogni singolo evento. Il potenziale risparmio energetico è direttamente correlato al numero di eventi che l'hub dei sensori e/o il FIFO possono bufferizzare: esiste un maggiore potenziale di risparmio energetico se è possibile raggruppare più eventi. Il batch sfrutta l'uso di memoria a basso consumo per ridurre il numero di riattivazioni di AP ad alta potenza.

Il batch può verificarsi solo quando un sensore possiede una FIFO hardware e/o può bufferizzare eventi all'interno di un hub di sensori. In entrambi i casi, il sensore deve segnalare il numero massimo di eventi che possono essere raggruppati contemporaneamente tramite SensorInfo.fifoMaxEventCount .

Se un sensore ha spazio riservato all'interno di una FIFO, il sensore deve segnalare il numero di eventi riservati tramite SensorInfo.fifoReservedEventCount . Se la FIFO è dedicata al sensore, SensorInfo.fifoReservedEventCount è la dimensione della FIFO. Se la FIFO è condivisa tra più sensori, questo valore può essere zero. Un caso d'uso comune è consentire a un sensore di utilizzare l'intero FIFO se è l'unico sensore attivo. Se sono attivi più sensori, a ciascun sensore viene garantito lo spazio per almeno gli eventi SensorInfo.fifoReservedEventCount nel FIFO. Se viene utilizzato un hub di sensori, la garanzia può essere applicata tramite software.

Gli eventi del sensore vengono raggruppati nelle seguenti situazioni:

  • La latenza massima del report corrente del sensore è maggiore di zero, il che significa che gli eventi del sensore possono essere ritardati fino alla latenza massima del report prima di essere segnalati tramite l'HAL.
  • L'AP è in modalità di sospensione e il sensore è un sensore di non riattivazione. In questo caso gli eventi non devono riattivare l'AP e devono essere memorizzati fino al riattivazione dell'AP.

Se un sensore non supporta l'invio in batch e l'AP è in modalità di sospensione, all'AP vengono segnalati solo gli eventi del sensore di riattivazione e gli eventi di non riattivazione non devono essere segnalati all'AP.

Parametri di dosaggio

I due parametri che governano il comportamento del batching sono sampling_period_ns e max_report_latency_ns . sampling_period_ns determina la frequenza con cui viene generato un nuovo evento del sensore e max_report_latency_ns determina quanto tempo occorre prima che l'evento venga segnalato all'HAL dei sensori.

periodo_campionamento_ns

Il significato del parametro sampling_period_ns dipende dalla modalità di reporting del sensore specificato:

  • Continuo: sampling_period_ns è la frequenza di campionamento, ovvero la frequenza con cui vengono generati gli eventi.
  • In variazione: sampling_period_ns limita la frequenza di campionamento degli eventi, il che significa che gli eventi non vengono generati più velocemente di ogni nanosecondi sampling_period_ns . I periodi possono essere più lunghi di sampling_period_ns se non viene generato alcun evento e i valori misurati non cambiano per lunghi periodi. Per ulteriori dettagli, vedere la modalità di reporting sulle modifiche .
  • One-shot: sampling_period_ns viene ignorato. Non ha alcun effetto.
  • Speciale: per dettagli su come viene utilizzato sampling_period_ns per sensori speciali, vedere Tipi di sensori .

Per ulteriori informazioni sull'impatto di sampling_period_ns nelle diverse modalità, consulta Modalità di reporting .

Per sensori continui e in variazione:

  • se sampling_period_ns è inferiore a SensorInfo.minDelay , l'implementazione HAL deve bloccarlo silenziosamente su max(SensorInfo.minDelay, 1ms) . Android non supporta la generazione di eventi a più di 1000 Hz.
  • se sampling_period_ns è maggiore di SensorInfo.maxDelay , l'implementazione HAL deve troncarlo automaticamente in SensorInfo.maxDelay .

I sensori fisici a volte hanno limitazioni sulla velocità a cui possono funzionare e sulla precisione dei loro orologi. Per tenere conto di ciò, la frequenza di campionamento effettiva può differire dalla frequenza richiesta purché soddisfi i requisiti nella tabella seguente.

Se la frequenza richiesta è

Quindi la frequenza effettiva deve essere

al di sotto della frequenza minima (<1/maxDelay)

tra il 90% e il 110% della frequenza minima

tra la frequenza minima e massima

tra il 90% e il 220% della frequenza richiesta

sopra la frequenza massima (>1/minDelay)

tra il 90% e il 110% della frequenza massima e inferiore a 1100 Hz

max_report_latency_ns

max_report_latency_ns imposta il tempo massimo in nanosecondi entro il quale gli eventi possono essere ritardati e archiviati nella FIFO hardware prima di essere segnalati tramite l'HAL mentre l'AP è attivo.

Un valore pari a zero significa che gli eventi devono essere segnalati non appena vengono misurati, saltando del tutto la FIFO o svuotando la FIFO non appena è presente un evento dal sensore.

Ad esempio, un accelerometro attivato a 50 Hz con max_report_latency_ns=0 attiverà gli interrupt 50 volte al secondo quando l'AP è attivo.

Quando max_report_latency_ns>0 , gli eventi del sensore non devono essere segnalati non appena vengono rilevati. Possono essere temporaneamente archiviati nel FIFO e riportati in batch, a condizione che nessun evento venga ritardato di più di max_report_latency_ns nanosecondi. Ciò significa che tutti gli eventi successivi al batch precedente vengono registrati e restituiti contemporaneamente. Ciò riduce la quantità di interruzioni inviate all'AP e consente all'AP di passare a una modalità di consumo ridotto (inattività) mentre il sensore acquisisce e raggruppa i dati.

Ad ogni evento è associato un timestamp. Il ritardo nell'orario in cui viene segnalato un evento non influisce sul timestamp dell'evento. La marcatura temporale deve essere precisa e corrispondere all'ora in cui l'evento si è verificato fisicamente e non all'ora in cui è stato segnalato.

Consentire la memorizzazione temporanea degli eventi del sensore nella FIFO non modifica il comportamento di invio degli eventi all'HAL; gli eventi provenienti da sensori diversi possono essere intercalati e tutti gli eventi provenienti dallo stesso sensore sono ordinati nel tempo.

Eventi di risveglio e di non risveglio

Gli eventi dei sensori provenienti dai sensori di riattivazione devono essere memorizzati in uno o più FIFO di riattivazione. Un progetto comune consiste nell'avere un unico FIFO di risveglio condiviso, di grandi dimensioni, in cui gli eventi provenienti da tutti i sensori di risveglio sono interlacciati. In alternativa, puoi avere una FIFO di riattivazione per sensore oppure avere FIFO dedicate per particolari sensori di riattivazione e una FIFO condivisa per il resto dei sensori di riattivazione.

Allo stesso modo, gli eventi dei sensori provenienti da sensori non di riattivazione devono essere memorizzati in uno o più FIFO di non riattivazione.

In tutti i casi, gli eventi del sensore di riattivazione e gli eventi del sensore non di riattivazione non possono essere intercalati nella stessa FIFO. Gli eventi di attivazione devono essere archiviati in una FIFO di attivazione e gli eventi di non attivazione devono essere archiviati in una FIFO di non attivazione.

Per quanto riguarda la FIFO di riattivazione, il design FIFO singolo, grande e condiviso offre i migliori vantaggi in termini di potenza. Per la FIFO di non risveglio, il design della FIFO singola, grande condivisa e diversi piccoli FIFO riservati hanno caratteristiche di potenza simili. Per ulteriori suggerimenti su come configurare ciascuna FIFO, vedere Priorità di allocazione FIFO .

Comportamento al di fuori della modalità di sospensione

Quando l'AP è attivo (non in modalità di sospensione), gli eventi vengono archiviati temporaneamente nelle FIFO purché non vengano ritardati di oltre max_report_latency .

Finché l'AP non entra in modalità di sospensione, nessun evento verrà eliminato o perso. Se i FIFO interni si riempiono prima che scada max_report_latency , gli eventi vengono segnalati in quel momento per garantire che nessun evento venga perso.

Se più sensori condividono la stessa FIFO e scade il max_report_latency di uno di essi, vengono segnalati tutti gli eventi del FIFO, anche se il max_report_latency degli altri sensori non è ancora trascorso. Ciò riduce il numero di volte in cui vengono segnalati batch di eventi. Quando è necessario segnalare un evento, vengono segnalati tutti gli eventi di tutti i sensori.

Ad esempio, se sono attivati ​​i seguenti sensori:

  • accelerometro raggruppato con max_report_latency = 20s
  • giroscopio raggruppato con max_report_latency = 5s

I batch dell'accelerometro vengono riportati contemporaneamente a quelli del giroscopio (ogni 5 secondi), anche se l'accelerometro e il giroscopio non condividono lo stesso FIFO.

Comportamento in modalità sospensione

Il batching è particolarmente utile per raccogliere i dati dei sensori in background senza tenere sveglio l'AP. Poiché i driver del sensore e l'implementazione dell'HAL non possono mantenere un wakelock*, l'AP può entrare in modalità di sospensione anche durante la raccolta dei dati del sensore.

Il comportamento dei sensori mentre l'AP è sospeso dipende dal fatto che il sensore sia un sensore di riattivazione. Per ulteriori dettagli, vedere Sensori di riattivazione .

Quando una FIFO non sveglia si riempie, deve avvolgersi e comportarsi come un buffer circolare, sovrascrivendo gli eventi più vecchi con i nuovi eventi che sostituiscono quelli vecchi. max_report_latency non ha alcun impatto sui FIFO di non riattivazione durante la modalità di sospensione.

Quando un FIFO di riattivazione si riempie o quando scade la max_report_latency di uno dei sensori di riattivazione, l'hardware deve riattivare l'AP e segnalare i dati.

In entrambi i casi (wake-up e non-wake-up), non appena l'AP esce dalla modalità di sospensione, viene prodotto un batch con il contenuto di tutte le FIFO, anche se max_report_latency di alcuni sensori non è ancora trascorsa. Ciò riduce al minimo il rischio che l'AP debba riattivarsi subito dopo essere tornato in modalità di sospensione e, pertanto, riduce al minimo il consumo energetico.

*Un'eccezione notevole in cui ai conducenti non è consentito mantenere un wakelock è quando un sensore di sveglia con modalità di reporting continuo viene attivato con max_report_latency < 1 secondo. In questo caso, il conducente può mantenere un wakelock perché l'AP non ha il tempo di entrare in modalità di sospensione, poiché verrebbe svegliato da un evento di riattivazione prima di raggiungere la modalità di sospensione.

Precauzioni durante il dosaggio dei sensori di riattivazione

A seconda del dispositivo, potrebbero essere necessari alcuni millisecondi prima che l'AP esca completamente dalla modalità di sospensione e inizi a svuotare il FIFO. È necessario allocare spazio sufficiente nella FIFO per consentire al dispositivo di uscire dalla modalità di sospensione senza che la FIFO di riattivazione trabocchi. Nessun evento andrà perso e il max_report_latency deve essere rispettato.

Precauzioni durante il dosaggio di sensori in variazione non attivati

I sensori in variazione generano eventi solo quando il valore che stanno misurando cambia. Se il valore misurato cambia mentre l'AP è in modalità di sospensione, le applicazioni si aspettano di ricevere un evento non appena l'AP si riattiva. Per questo motivo, l'invio in batch degli eventi del sensore in fase di modifica senza riattivazione deve essere eseguito con attenzione se il sensore condivide la FIFO con altri sensori. L'ultimo evento generato da ciascun sensore in variazione deve essere sempre salvato al di fuori della FIFO condivisa in modo che non possa mai essere sovrascritto da altri eventi. Quando l'AP si riattiva, dopo che tutti gli eventi dal FIFO sono stati segnalati, deve essere segnalato l'ultimo evento del sensore di modifica.

Ecco una situazione da evitare:

  1. Un'applicazione si registra sul contapassi non riattivato (in variazione) e sull'accelerometro non riattivato (continuo), entrambi che condividono lo stesso FIFO.
  2. L'applicazione riceve un evento contatore di passi step_count=1000 steps codice>.
  3. L'AP va in sospensione.
  4. L'utente cammina per 20 passi, causando l'interlacciamento degli eventi del contatore dei passi e dell'accelerometro, dove l'ultimo evento del contatore dei passi è step_count = 1020 steps .
  5. L'utente non si muove per molto tempo, provocando l'accumulo di eventi dell'accelerometro nella FIFO, sovrascrivendo infine ogni evento step_count nella FIFO condivisa.
  6. L'AP si sveglia e tutti gli eventi dal FIFO vengono inviati all'applicazione.
  7. L'applicazione riceve solo gli eventi dell'accelerometro e ritiene che l'utente non abbia camminato.

Salvando l'ultimo evento del contatore di passi al di fuori del FIFO, l'HAL può segnalare questo evento quando l'AP si riattiva, anche se tutti gli altri eventi del contatore di passi sono stati sovrascritti dagli eventi dell'accelerometro. In questo modo, l'applicazione riceve step_count = 1020 steps quando l'AP si riattiva.

Implementare il batching

Per risparmiare energia, il batching deve essere implementato senza l'ausilio dell'AP e l'AP deve poter essere sospeso durante il batching.

Se l'invio in batch viene eseguito in un hub di sensori, il consumo energetico dell'hub di sensori deve essere ridotto al minimo.

La latenza massima del report può essere modificata in qualsiasi momento, in particolare mentre il sensore specificato è già abilitato; e questo non dovrebbe comportare la perdita di eventi.

Priorità di allocazione FIFO

Sulle piattaforme in cui la dimensione del buffer FIFO hardware e/o hub sensore è limitata, i progettisti di sistema potrebbero dover scegliere la quantità FIFO riservare per ciascun sensore. Per facilitare questa scelta, ecco un elenco di possibili applicazioni quando il batching viene implementato sui diversi sensori.

Valore alto: navigazione stimata dei pedoni a bassa potenza

Tempo di dosaggio previsto: da 1 a 10 minuti

Sensori per batch:

  • Rilevatore di passi di sveglia
  • Vettore di rotazione del gioco di risveglio a 5 Hz
  • Barometro del risveglio a 5 Hz
  • Magnetometro non calibrato di risveglio a 5 Hz

Il raggruppamento di questi dati consente di eseguire la navigazione stimata dei pedoni lasciando l'AP andare in sospensione.

Valore alto: riconoscimento di attività/gesti intermittenti di potenza media

Tempo di dosaggio target: 3 secondi

Sensori per batch: accelerometro non riattivato a 50 Hz

L'accumulo di questi dati consente di riconoscere periodicamente attività e gesti arbitrari senza dover tenere sveglio l'AP durante la raccolta dei dati.

Valore medio: riconoscimento di attività/gesti continui di potenza media

Tempo di dosaggio previsto: da 1 a 3 minuti

Sensori batch: Accelerometro di risveglio a 50 Hz

Il raggruppamento di questi dati consente di riconoscere continuamente attività e gesti arbitrari senza dover tenere sveglio l'AP durante la raccolta dei dati.

Valore medio-alto: Riduzione del carico di interrupt

Tempo di dosaggio target: < 1 secondo

Sensori per batch: qualsiasi sensore ad alta frequenza, solitamente non riattivato.

Se il giroscopio è impostato a 240 Hz, anche raggruppando solo 10 eventi giroscopici è possibile ridurre il numero di interruzioni da 240/secondo a 24/secondo.

Valore medio: raccolta continua di dati a bassa frequenza

Tempo di dosaggio previsto: da 1 a 10 minuti

Sensori per batch:

  • Barometro del risveglio a 1 Hz
  • Sensore di umidità al risveglio a 1 Hz
  • Altri sensori di risveglio a bassa frequenza a velocità simili

Consente di creare applicazioni di monitoraggio a basso consumo.

Valore medio-basso: raccolta continua di tutti i sensori

Tempo di dosaggio previsto: da 1 a 10 minuti

Sensori per batch: tutti i sensori di risveglio, ad alte frequenze

Consente la raccolta completa dei dati del sensore lasciando l'AP in modalità di sospensione. Considera solo se lo spazio FIFO non è un problema.