Mise en lot

Qu'est-ce que le traitement par lots ?

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

Le traitement par lots peut permettre d'importantes économies d'énergie en ne réveillant le processeur d'applications principal (AP), qui exécute Android, que 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 concentrateur de capteurs et/ou le FIFO peuvent mettre en mémoire tampon : il existe un plus grand potentiel d'économies d'énergie si davantage d'événements peuvent être regroupés. Le traitement par lots exploite l'utilisation de la mémoire basse 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 des événements au sein d'un concentrateur de capteurs. Dans les deux cas, le capteur doit signaler le nombre maximal 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 la FIFO est dédiée au capteur, alors SensorInfo.fifoReservedEventCount est la taille de la 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 la FIFO. Si un concentrateur 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 de rapport maximale actuelle du capteur est supérieure à zéro, ce qui signifie que les événements de capteur peuvent être retardés jusqu'à la latence de rapport maximale avant d'être signalés via HAL.
• Le point d'accès est en mode veille 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 capteur de réveil sont signalés à l'AP et les événements de non-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 jusqu'à ce que l'événement doive être signalé à la couche HAL Sensors.

é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 le taux auquel les événements sont générés.
• Au 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 de 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 rapport sur les modifications .
• 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 Sensor Types .

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

Pour les capteurs continus et à changement :

• si sampling_period_ns est inférieur à SensorInfo.minDelay , alors l'implémentation HAL doit le limiter silencieusement à max(SensorInfo.minDelay, 1ms) . Android ne prend pas en charge la génération d'événements à plus de 1000 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 limitations sur les vitesses auxquelles ils peuvent fonctionner 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 HAL pendant que l'AP est é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 la FIFO, soit en vidant la 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 stockés temporairement dans le FIFO et signalés par lots, tant qu'aucun événement n'est 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 au point d'accès de basculer vers un mode de consommation réduite (inactif) pendant que le capteur capture et regroupe les données.

Chaque événement est associé à un horodatage. Le fait de retarder l'heure à laquelle un événement est signalé n'a pas d'incidence 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 la FIFO ne modifie pas le comportement de soumission des événements à la HAL ; les événements 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 de non-réveil

Les événements de capteur provenant de capteurs de réveil doivent être stockés dans une ou plusieurs FIFO de réveil. Une conception courante consiste à avoir une seule FIFO de réveil partagée, de grande taille, où 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 le 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 unique, large et partagée du FIFO offre les meilleurs avantages en termes de puissance. Pour la FIFO sans réveil, la seule grande FIFO partagée et plusieurs petites FIFO réservées ont des caractéristiques de puissance similaires. Pour plus de suggestions sur la configuration de 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 veille), les événements sont stockés temporairement dans des FIFO tant qu'ils ne sont pas retardés de plus de max_report_latency .

Tant que le point d'accès n'entre pas en mode suspension, aucun événement ne doit être abandonné ou perdu. Si les FIFO internes sont pleines avant l'expiration de max_report_latency , les événements sont signalés à ce stade pour s'assurer 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 que 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 batch avec max_report_latency = 20s
• gyroscope groupé avec max_report_latency = 5s

Les lots de l'accéléromètre sont signalés en même temps que les lots du gyroscope sont signalés (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 suspendu

Le traitement par lots est particulièrement avantageux pour collecter des données de capteur en arrière-plan sans maintenir 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 entrer en mode veille 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 non-réveil se remplit, il doit s'enrouler et se comporter comme un tampon circulaire, écrasant les événements plus anciens avec les nouveaux événements remplaçant les anciens. max_report_latency n'a aucun impact sur les FIFO sans réveil en mode veille.

Lorsqu'un FIFO de réveil se remplit, ou lorsque le max_report_latency de l'un des capteurs de réveil s'est écoulé, 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 le point d'accès sort du mode veille, un batch est produit avec le contenu de tous 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 veille et, par conséquent, minimise la consommation d'énergie.

*Une exception notable pour les conducteurs qui ne sont pas autorisés à détenir un verrou de réveil 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 pilote peut maintenir un verrou de réveil car le point d'accès n'a pas le temps d'entrer en mode veille, car il serait réveillé par un événement de réveil avant d'atteindre le mode veille.

Précautions à prendre lors du regroupement des capteurs de réveil

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

Précautions à prendre lors du regroupement de capteurs sans réveil sur changement

Les capteurs de changement ne génèrent des événements que lorsque la valeur qu'ils mesurent change. Si la valeur mesurée change alors que l'AP est en mode veille, les applications s'attendent à recevoir un événement dès que l'AP se réveille. Pour cette raison, le regroupement des événements de capteur sans réveil lors du changement doit être effectué avec précaution si le capteur partage son 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 le point d'accès se réveille, une fois que tous les événements du FIFO ont été signalés, le dernier événement de capteur de changement doit être signalé.

Voici une situation à éviter :

1. Une application s'enregistre auprès du compteur de pas sans réveil (sur changement) et de 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 marche 20 pas, provoquant l'entrelacement des événements de compteur de pas et d'accéléromètre, le dernier événement de compteur de pas étant step_count = 1020 steps .
5. L'utilisateur ne bouge pas pendant une longue période, ce qui fait que les événements de l'accéléromètre continuent de s'accumuler dans le FIFO, écrasant finalement chaque événement step_count dans le FIFO partagé.
6. AP se réveille et tous les événements du FIFO sont envoyés à l'application.
7. L'application ne reçoit que les événements de l'accéléromètre et pense que l'utilisateur n'a pas marché.

En enregistrant le dernier événement de compteur de pas en dehors de la FIFO, la 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 l'AP se réveille.

Mise en œuvre du traitement par lots

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

Si le traitement par lots est effectué dans un concentrateur de capteurs, la consommation d'énergie du concentrateur de capteurs doit être réduite au minimum.

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 avoir à 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 place sur les différents capteurs.

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

Temps de mise en lot cible : 1 à 10 minutes

Capteurs à regrouper :

• 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 navigation à l'estime des piétons tout en laissant le point d'accès se suspendre.

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

Temps de traitement par lot 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 à maintenir le point d'accès éveillé pendant la collecte des données.

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

Temps de mise en lot 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 continu des activités et des gestes arbitraires sans avoir à maintenir 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 par lot cible : < 1 seconde

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

Si le gyroscope est réglé sur 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 mise en lot cible : 1 à 10 minutes

Capteurs à regrouper :

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

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

Valeur moyenne-basse : collecte continue de tous les capteurs

Temps de mise en lot cible : 1 à 10 minutes

Capteurs à regrouper : Tous les 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 veille. Ne considérez que si l'espace FIFO n'est pas un problème.