Traitement par lot

Qu’est-ce que le batching ?

Le traitement par lots fait référence à la mise en mémoire tampon des événements de capteur dans un hub de capteurs et/ou un FIFO matériel avant de signaler les événements via le HAL des capteurs . L'emplacement où les événements du capteur sont mis en mémoire tampon (hub de capteur et/ou FIFO matériel) est appelé « FIFO » sur cette page. Lorsque le traitement par lots des événements de capteur n'est pas actif, les événements de capteur sont immédiatement signalés au HAL des capteurs lorsqu'ils sont disponibles.

Le traitement par lots peut permettre des économies d'énergie significatives en réveillant uniquement le processeur d'applications principal (AP), qui exécute Android, lorsque de nombreux événements de capteur sont prêts à être traités, au lieu de le réveiller pour chaque événement individuel. Les économies d'énergie potentielles sont directement corrélées au nombre d'événements que le hub de capteurs et/ou le FIFO peuvent mettre en mémoire tampon : le potentiel d'économie d'énergie est plus important si davantage d'événements peuvent être regroupés. Le traitement par lots exploite l'utilisation d'une mémoire à faible consommation afin de réduire le nombre de réveils de points d'accès à haute puissance.

Le traitement par lots ne peut se produire que lorsqu'un capteur possède un FIFO matériel et/ou peut mettre en mémoire tampon les événements au sein d'un hub de capteurs. Dans les deux cas, le capteur doit signaler le nombre maximum d'événements pouvant être regroupés simultanément via SensorInfo.fifoMaxEventCount .

Si un capteur dispose d'un espace réservé dans un FIFO, le capteur doit signaler le nombre d'événements réservés via SensorInfo.fifoReservedEventCount . Si le FIFO est dédié au capteur, alors SensorInfo.fifoReservedEventCount est la taille du FIFO. Si le FIFO est partagé entre plusieurs capteurs, cette valeur peut être nulle. Un cas d'utilisation courant consiste à permettre à un capteur d'utiliser l'intégralité de la FIFO s'il s'agit du seul capteur actif. Si plusieurs capteurs sont actifs, chaque capteur dispose d'un espace garanti pour au moins les événements SensorInfo.fifoReservedEventCount dans le FIFO. Si un hub de capteurs est utilisé, la garantie peut être appliquée via un logiciel.

Les événements de capteur sont regroupés dans les situations suivantes :

• La latence maximale actuelle du rapport du capteur est supérieure à zéro, ce qui signifie que les événements du capteur peuvent être retardés jusqu'à la latence maximale du rapport avant d'être signalés via le HAL.
• Le point d'accès est en mode suspension et le capteur est un capteur sans réveil. Dans ce cas, les événements ne doivent pas réveiller l'AP et doivent être stockés jusqu'à ce que l'AP se réveille.

Si un capteur ne prend pas en charge le traitement par lots et que l'AP est en veille, seuls les événements de réveil du capteur sont signalés à l'AP et les événements hors réveil ne doivent pas être signalés à l'AP.

Paramètres de traitement par lots

Les deux paramètres qui régissent le comportement du traitement par lots sont sampling_period_ns et max_report_latency_ns . sampling_period_ns détermine la fréquence à laquelle un nouvel événement de capteur est généré et max_report_latency_ns détermine combien de temps avant que l'événement ne soit signalé au HAL des capteurs.

échantillonnage_période_ns

La signification du paramètre sampling_period_ns dépend du mode de rapport du capteur spécifié :

• Continu : sampling_period_ns est le taux d'échantillonnage, c'est-à-dire la fréquence à laquelle les événements sont générés.
• En cas de changement : sampling_period_ns limite le taux d'échantillonnage des événements, ce qui signifie que les événements ne sont pas générés plus rapidement que toutes les nanosecondes sampling_period_ns . Les périodes peuvent être plus longues que sampling_period_ns si aucun événement n'est généré et que les valeurs mesurées ne changent pas pendant de longues périodes. Pour plus de détails, voir Mode de reporting en cas de modification .
• One-shot : sampling_period_ns est ignoré. Cela n’a aucun effet.
• Spécial : pour plus de détails sur la façon dont sampling_period_ns est utilisé pour les capteurs spéciaux, voir Types de capteurs .

Pour plus d'informations sur l'impact de sampling_period_ns dans les différents modes, voir Modes de reporting .

Pour les capteurs continus et à changement :

• si sampling_period_ns est inférieur à SensorInfo.minDelay , alors l'implémentation HAL doit le fixer silencieusement à max(SensorInfo.minDelay, 1ms) . Android ne prend pas en charge la génération d'événements à plus de 1 000 Hz.
• si sampling_period_ns est supérieur à SensorInfo.maxDelay , alors l'implémentation HAL doit le tronquer silencieusement en SensorInfo.maxDelay .

Les capteurs physiques ont parfois des limites quant à leur vitesse de fonctionnement et à la précision de leurs horloges. Pour tenir compte de cela, la fréquence d'échantillonnage réelle peut différer de la fréquence demandée tant qu'elle satisfait aux exigences du tableau ci-dessous.

max_report_latency_ns

max_report_latency_ns définit le temps maximum en nanosecondes pendant lequel les événements peuvent être retardés et stockés dans la FIFO matérielle avant d'être signalés via le HAL pendant que le point d'accès est réveillé.

Une valeur de zéro signifie que les événements doivent être signalés dès qu'ils sont mesurés, soit en sautant complètement le FIFO, soit en vidant le FIFO dès qu'un événement du capteur est présent.

Par exemple, un accéléromètre activé à 50 Hz avec max_report_latency_ns=0 déclenchera des interruptions 50 fois par seconde lorsque l'AP est réveillé.

Lorsque max_report_latency_ns>0 , les événements de capteur n'ont pas besoin d'être signalés dès qu'ils sont détectés. Ils peuvent être temporairement stockés dans le FIFO et signalés par lots, à condition qu'aucun événement ne soit retardé de plus de max_report_latency_ns nanosecondes. Cela signifie que tous les événements depuis le lot précédent sont enregistrés et renvoyés en même temps. Cela réduit le nombre d'interruptions envoyées au point d'accès et permet à ce dernier de passer à un mode de consommation inférieure (inactif) pendant que le capteur capture et regroupe les données.

Chaque événement est associé à un horodatage. Le retardement de l'heure à laquelle un événement est signalé n'a pas d'impact sur l'horodatage de l'événement. L'horodatage doit être précis et correspondre à l'heure à laquelle l'événement s'est produit physiquement, et non à l'heure à laquelle il a été signalé.

Autoriser le stockage temporaire des événements de capteur dans le FIFO ne modifie pas le comportement de soumission des événements au HAL ; les événements provenant de différents capteurs peuvent être entrelacés et tous les événements du même capteur sont classés dans le temps.

Événements de réveil et hors réveil

Les événements de capteur provenant des capteurs de réveil doivent être stockés dans une ou plusieurs FIFO de réveil. Une conception courante consiste à disposer d'un seul grand FIFO de réveil partagé dans lequel les événements de tous les capteurs de réveil sont entrelacés. Alternativement, vous pouvez avoir un FIFO de réveil par capteur ou avoir des FIFO dédiés pour des capteurs de réveil particuliers et un FIFO partagé pour le reste des capteurs de réveil.

De même, les événements de capteur provenant de capteurs sans réveil doivent être stockés dans un ou plusieurs FIFO sans réveil.

Dans tous les cas, les événements de capteur de réveil et les événements de capteur de non-réveil ne peuvent pas être entrelacés dans la même FIFO. Les événements de réveil doivent être stockés dans une FIFO de réveil, et les événements de non-réveil doivent être stockés dans une FIFO de non-réveil.

Pour le FIFO de réveil, la conception FIFO unique, grande et partagée offre les meilleurs avantages en termes de puissance. Pour le FIFO sans réveil, les conceptions de FIFO unique et grand partagé et de plusieurs petits FIFO réservés ont des caractéristiques de puissance similaires. Pour plus de suggestions sur la façon de configurer chaque FIFO, consultez Priorité d'allocation FIFO .

Comportement en dehors du mode suspension

Lorsque le point d'accès est réveillé (pas en mode suspension), les événements sont stockés temporairement dans les FIFO tant qu'ils ne sont pas retardés de plus de max_report_latency .

Tant que l'AP n'entre pas en mode suspension, aucun événement ne sera abandonné ou perdu. Si les FIFO internes sont saturés avant l'expiration max_report_latency , les événements sont signalés à ce stade pour garantir qu'aucun événement n'est perdu.

Si plusieurs capteurs partagent le même FIFO et que le max_report_latency de l'un d'eux est écoulé, tous les événements du FIFO sont signalés, même si le max_report_latency des autres capteurs n'est pas encore écoulé. Cela réduit le nombre de fois où des lots d'événements sont signalés. Lorsqu'un événement doit être signalé, tous les événements de tous les capteurs sont signalés.

Par exemple, si les capteurs suivants sont activés :

• accéléromètre groupé avec max_report_latency = 20s
• gyroscope groupé avec max_report_latency = 5s

Les lots d'accéléromètres sont signalés en même temps que les lots de gyroscopes (toutes les 5 secondes), même si l'accéléromètre et le gyroscope ne partagent pas le même FIFO.

Comportement en mode suspension

Le traitement par lots est particulièrement bénéfique pour collecter les données des capteurs en arrière-plan sans garder le point d'accès éveillé. Étant donné que les pilotes de capteur et l'implémentation HAL ne sont pas autorisés à maintenir un wake-lock*, le point d'accès peut passer en mode suspension même pendant la collecte des données du capteur.

Le comportement des capteurs lorsque le point d'accès est suspendu dépend du fait que le capteur est un capteur de réveil. Pour plus de détails, voir Capteurs de réveil .

Lorsqu'un FIFO sans réveil se remplit, il doit s'enrouler et se comporter comme un tampon circulaire, écrasant les événements plus anciens et les nouveaux événements remplaçant les anciens. max_report_latency n'a aucun impact sur les FIFO sans réveil en mode suspension.

Lorsqu'un FIFO de réveil se remplit, ou lorsque la max_report_latency de l'un des capteurs de réveil est écoulée, le matériel doit réveiller le point d'accès et signaler les données.

Dans les deux cas (réveil et non réveil), dès que l'AP sort du mode suspension, un batch est produit avec le contenu de toutes les FIFO, même si max_report_latency de certains capteurs n'est pas encore écoulé. Cela minimise le risque que le point d'accès doive se réveiller peu de temps après son retour en mode suspension et, par conséquent, minimise la consommation d'énergie.

*Une exception notable à laquelle les conducteurs ne sont pas autorisés à détenir un wakelock est lorsqu'un capteur de réveil avec le mode de rapport continu est activé avec max_report_latency < 1 seconde. Dans ce cas, le conducteur peut maintenir un wakelock car le point d'accès n'a pas le temps de passer en mode suspension, car il serait réveillé par un événement de réveil avant d'atteindre le mode suspension.

Précautions lors du regroupement de capteurs de réveil

Selon l'appareil, cela peut prendre quelques millisecondes pour que le point d'accès sorte complètement du mode suspension et commence à vider le FIFO. Une marge suffisante doit être allouée dans la FIFO pour permettre à l'appareil de sortir du mode suspension sans que la FIFO de réveil ne déborde. Aucun événement ne doit être perdu et le max_report_latency doit être respecté.

Précautions lors du traitement par lots de capteurs sans réveil lors du changement

Les capteurs en cas de changement génèrent des événements uniquement lorsque la valeur qu'ils mesurent change. Si la valeur mesurée change alors que le point d'accès est en mode suspension, les applications s'attendent à recevoir un événement dès le réveil du point d'accès. Pour cette raison, le traitement par lots des événements de capteur sans réveil lors d'un changement doit être effectué avec soin si le capteur partage sa FIFO avec d'autres capteurs. Le dernier événement généré par chaque capteur en cas de changement doit toujours être enregistré en dehors de la FIFO partagée afin qu'il ne puisse jamais être écrasé par d'autres événements. Lorsque l'AP se réveille, une fois que tous les événements du FIFO ont été signalés, le dernier événement de capteur en cours de changement doit être signalé.

Voici une situation à éviter :

1. Une application s'enregistre sur le compteur de pas sans réveil (en cas de changement) et sur l'accéléromètre sans réveil (continu), tous deux partageant le même FIFO.
2. L'application reçoit un événement de compteur de pas step_count=1000 steps code>.
3. L'AP va se suspendre.
4. L'utilisateur fait 20 pas, ce qui entraîne l'entrelacement des événements du compteur de pas et de l'accéléromètre, le dernier événement du compteur de pas étant step_count = 1020 steps .
5. L'utilisateur ne bouge pas pendant une longue période, ce qui entraîne une accumulation continue d'événements d'accéléromètre dans la FIFO, finissant par écraser chaque événement step_count dans la FIFO partagée.
6. AP se réveille et tous les événements du FIFO sont envoyés à l'application.
7. L'application reçoit uniquement les événements de l'accéléromètre et considère que l'utilisateur n'a pas marché.

En enregistrant le dernier événement de compteur de pas en dehors du FIFO, le HAL peut signaler cet événement lorsque l'AP se réveille, même si tous les autres événements de compteur de pas ont été écrasés par des événements d'accéléromètre. De cette façon, l'application reçoit step_count = 1020 steps lorsque le point d'accès se réveille.

Implémenter le traitement par lots

Pour économiser de l'énergie, le traitement par lots doit être mis en œuvre sans l'aide de l'AP, et celui-ci doit pouvoir se suspendre pendant le traitement par lots.

Si le traitement par lots est effectué dans un concentrateur de capteurs, la consommation électrique de ce dernier doit être minimisée.

La latence maximale du rapport peut être modifiée à tout moment, notamment lorsque le capteur spécifié est déjà activé ; et cela ne devrait pas entraîner la perte d'événements.

Priorité d'allocation FIFO

Sur les plates-formes dans lesquelles la taille du tampon FIFO matériel et/ou du concentrateur de capteurs est limitée, les concepteurs de systèmes peuvent devoir choisir la quantité de FIFO à réserver pour chaque capteur. Pour vous aider dans ce choix, voici une liste d'applications possibles lorsque le batching est mis en œuvre sur les différents capteurs.

Valeur élevée : estimation à l'estime des piétons à faible puissance

Temps de dosage cible : 1 à 10 minutes

Capteurs à lotir :

• Détecteur de pas de réveil
• Vecteur de rotation du jeu de réveil à 5 ​​Hz
• Baromètre de réveil à 5 ​​Hz
• Réveil magnétomètre non calibré à 5 Hz

Le regroupement de ces données permet d'effectuer une estimation à l'estime des piétons tout en laissant le point d'accès se suspendre.

Valeur élevée : activité intermittente/reconnaissance des gestes de puissance moyenne

Temps de traitement cible : 3 secondes

Capteurs à batch : Accéléromètre sans réveil à 50 Hz

Le regroupement de ces données permet de reconnaître périodiquement des activités et des gestes arbitraires sans avoir à garder le point d'accès éveillé pendant la collecte des données.

Valeur moyenne : activité continue/reconnaissance de gestes de puissance moyenne

Temps de dosage cible : 1 à 3 minutes

Capteurs à batch : Accéléromètre de réveil à 50 Hz

Le regroupement de ces données permet de reconnaître en permanence des activités et des gestes arbitraires sans avoir à garder le point d'accès éveillé pendant la collecte des données.

Valeur moyenne-élevée : réduction de la charge d'interruption

Temps de traitement cible : < 1 seconde

Capteurs à batch : tout capteur haute fréquence, généralement sans réveil.

Si le gyroscope est réglé à 240 Hz, même le regroupement de seulement 10 événements gyroscopiques peut réduire le nombre d'interruptions de 240/seconde à 24/seconde.

Valeur moyenne : collecte continue de données à basse fréquence

Temps de dosage cible : 1 à 10 minutes

Capteurs à lotir :

• Baromètre de réveil à 1 Hz
• Capteur d'humidité de réveil à 1 Hz
• Autres capteurs de réveil basse fréquence à des rythmes similaires

Permet de créer des applications de surveillance à faible consommation.

Valeur moyenne-basse : collecte continue de capteurs complets

Temps de dosage cible : 1 à 10 minutes

Capteurs à batch : Tous capteurs de réveil, à hautes fréquences

Permet la collecte complète des données du capteur tout en laissant le point d'accès en mode suspension. Considérez uniquement si l'espace FIFO n'est pas un problème.