Riot: IEEE802.15.4 : HW Auto ACK considéré comme nuisible

Dans la plupart des cas, cette pratique peut être nocive.

De manière réaliste, à quelle fréquence cela cause-t-il un préjudice réel ? Quel pourcentage de messages sont acquittés alors qu'ils sont réellement rejetés par le MCU ?

La radio passe en mode TX lors de la réception (#11256)

Ce cas est unique aux radios avec un tampon de réception/transmission partagé, n'est-ce pas ? N'affecte donc que la classe d'appareils at86rf2xx

Cela peut produire des comportements étranges, …

Avez-vous des exemples où cela cause des problèmes?

Ainsi, je propose de laisser Auto ACK en option et d'implémenter la réponse ACK dans le logiciel

Avez-vous des chiffres sur l'impact là-dessus? Taille du flash/utilisation de la RAM, mais aussi consommation d'énergie car le MCU doit se réveiller plus longtemps. De plus, combien de temps y a-t-il entre la réception de la trame et le délai d'expiration de l'accusé de réception et est-il réaliste de gérer les ACK dans le logiciel si la radio est connectée via SPI ?

En plus d'avoir une L2 plus fiable

Je suis un peu sceptique à propos de cette affirmation (si ce n'était pas encore clair d'après mon commentaire), la gestion des accusés de réception L2 est un cas souple en temps réel (les délais manquants dégraderont le service) et leur gestion dans le logiciel impose une exigence stricte sur le comportement en temps réel de RIOT.

Cela ne me dérange pas que le logiciel L2 acks s'il s'agit d'une exigence stricte pour certaines couches MAC spécifiques, mais cela n'est pas mentionné dans la description ici.

Salut @bergzand

De manière réaliste, à quelle fréquence cela cause-t-il un préjudice réel ? Quel pourcentage de messages sont acquittés alors qu'ils sont réellement rejetés par le MCU ?

Pour les couches supérieures, ce n'est pas si grave (étant donné qu'il s'agit généralement de meilleurs efforts).
Cependant, certaines couches MAC et sous-MAC (OpenThread, TSCH) utilisent l'ACK pour mettre à jour les informations de voisinage.

Ce cas est unique aux radios avec un tampon de réception/transmission partagé, n'est-ce pas ? N'affecte donc que la classe d'appareils at86rf2xx

Vrai. Je ne fais que souligner des scénarios où cela pourrait se produire.

Avez-vous des exemples où cela cause des problèmes?

Donner des informations erronées aux utilisateurs de la couche MAC (par exemple Mesh Link Establishment) affecterait probablement la qualité de la liaison. Je suis conscient que nous n'avons pas encore une telle chose dans RIOT (et les piles qui l'utilisent implémentent déjà la fonctionnalité).

Avez-vous des chiffres sur l'impact là-dessus? Taille du flash/utilisation de la RAM, mais aussi consommation d'énergie car le MCU doit se réveiller plus longtemps. De plus, combien de temps y a-t-il entre la réception de la trame et le délai d'expiration de l'accusé de réception et est-il réaliste de gérer les ACK dans le logiciel si la radio est connectée via SPI ?

Malheureusement non. Comme il n'est pas mis en œuvre, je n'ai pas de chiffres à comparer. Je n'ai que quelques branches de test avec auto ACK, mais je n'ai pas testé plus profondément.

Je suis un peu sceptique à propos de cette affirmation (si ce n'était pas encore clair d'après mon commentaire), la gestion des accusés de réception L2 est un cas souple en temps réel (les délais manquants dégraderont le service) et leur gestion dans le logiciel impose une exigence stricte sur le comportement en temps réel de RIOT.

Il y a des informations de Tiny OS selon lesquelles les logiciels ACK ont tendance à avoir des baisses plus élevées (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt) mais au moins il n'y a pas de faux positifs.
AFAIK, l'IEEE802.15.4 ne parle pas de contraintes strictes (uniquement des valeurs de délai d'attente). Si un paquet ACK n'est pas livré à temps, il est considéré comme perdu. Mais comme dit précédemment, je n'ai aucune information sur les performances du système d'exploitation avec les ACK logiciels. Ce serait intéressant d'avoir des repères

Cela ne me dérange pas que le logiciel L2 acks s'il s'agit d'une exigence stricte pour certaines couches MAC spécifiques, mais cela n'est pas mentionné dans la description ici.

Nous devons de toute façon implémenter le logiciel ACK pour les radios qui ne prennent pas en charge l'Auto ACK et les fonctionnalités qui ne sont pas disponibles dans les accélérateurs matériels (je ne connais pas de radios qui prennent en charge les Enhanced ACK pour être honnête).
La question est, voulons-nous que cela soit facultatif ou obligatoire pour nos configurations par défaut ? Comme décrit précédemment, l'idée n'est pas de supprimer le support Auto ACK mais d'avoir un meilleur support de L2. On peut toujours activer Auto ACK si on veut (c'est pourquoi j'ai proposé d'ajouter des caps radio dans https://github.com/RIOT-OS/RIOT/pull/11473)

Peut-être que je me trompe mais la solution semble simple :

• Nous implémentons un ARQ (indépendant du matériel) -> nous le voulons indépendamment de cette discussion.
• Nous comparons les performances (et l'interopérabilité) des implémentations matérielles et logicielles.
• Nous optons pour un paramètre par défaut spécifique à la plate-forme, ce qui n'empêche pas de compiler l'autre.

En tant que nœud secondaire : le fait que nous n'ayons jamais été confrontés au problème mis en évidence par @ jia200x peut être lié à des couches MAC manquantes au-dessus d'une radio dans RIOT. De plus, avec les radios à faible puissance, nous tolérons de toute façon certaines pertes.

Quelle est l'importance des ACK logiciels pour 6TiSCH ? IIRC, OpenWSN utilise des ACK logiciels en partie pour suivre la qualité des liens entre voisins.

Quelle est l'importance des ACK logiciels pour 6TiSCH ? IIRC, OpenWSN utilise des ACK logiciels en partie pour suivre la qualité des liens entre voisins.

6TiSCH ne parle pas contre les ACK matériels, mais nécessite des ACK améliorés pour transmettre les informations de synchronisation. Dans OpenWSN, cela est géré par le pkg lui-même.

* et les ACK améliorés ne sont pas pris en charge par le matériel que je connais.

De plus, le problème avec les capacités d'accusé de réception du matériel dans certains cas est qu'il assume l'entière responsabilité du mécanisme sans nécessairement exposer les informations pertinentes, telles que l'ACK reçu ou le nombre de tentatives. Avec 6TiSCH, vous pouvez retransmettre une trame dans une autre cellule, ce qui nécessite ce type d'informations. Ainsi, OpenWSN se base sur un ensemble limité de fonctionnalités de périphérique radio et implémente tous les autres composants MAC dans le logiciel.

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé s'il n'y a plus d'activité. Si vous voulez que j'ignore ce problème, veuillez le marquer avec l'étiquette "State: don't stale". Merci pour vos contributions.