Comment choisir la profondeur d’une file de messages sans accumuler des données obsolètes ?
La profondeur d’une file de messages doit absorber les variations prévues sans laisser s’accumuler des mesures trop anciennes pour la commande.
Domaine de connaissance
Affiner le parcours
Choisissez une branche plus précise ou continuez avec toutes les réponses ci-dessous.
Questions du domaine
76 résultats
La profondeur d’une file de messages doit absorber les variations prévues sans laisser s’accumuler des mesures trop anciennes pour la commande.
Sur un ordinateur monocarte partagé, on isole les tâches critiques par priorité, ressources réservées, permissions et voies de communication afin qu’un diagnostic ne bloque pas la commande.
Un stockage résistant aux coupures protège les données par écriture atomique, journalisation, réserve d’énergie et redémarrage vérifié plutôt que par une simple carte mémoire.
Maintenir un accélérateur sur plusieurs années demande de suivre pilotes, température, mémoire, compatibilité du modèle et disponibilité des pièces, avec une voie de retour.
Le gain énergétique d’un accélérateur se mesure en énergie par tâche, pas seulement en vitesse : il faut comparer consommation, temps de calcul et qualité obtenue.
Intégrer un accélérateur dans une boucle temps réel demande de borner transfert, calcul et retour, puis de préserver l’arrêt et la commande même si l’accélérateur tarde.
Un GPU favorise le calcul parallèle souple, un NPU les réseaux optimisés et un FPGA les pipelines déterministes reconfigurables ; le choix dépend du modèle et du délai.
Un accélérateur matériel est une puce spécialisée qui exécute certains calculs d’IA ou de signal plus vite et avec moins d’énergie qu’un processeur généraliste.
Un système temps réel en robotique produit une réponse dans un délai attendu et mesurable, en plus de fournir le bon résultat.
Lorsqu’une tâche temps réel dépasse son échéance, on identifie la cause, applique un comportement dégradé ou sûr et évite d’utiliser un résultat trop ancien comme s’il était actuel.
On mesure le temps d’exécution d’une tâche robotique avec des timestamps autour du code, des répétitions représentatives et une analyse du pire cas sous charge.
Le temps réel dur impose de respecter chaque échéance critique, alors que le temps réel souple tolère certains retards avec une qualité dégradée ou une réponse moins fraîche.
Une question plus précise ?