Riot: IEEE802.15.4: HW Auto ACK gilt als schädlich

In den meisten Fällen kann diese Praxis schädlich sein.

Realistisch gesehen, wie oft verursacht dies tatsächlich Schaden? Wie viel Prozent der Nachrichten werden bestätigt, während sie tatsächlich von der MCU verworfen werden?

Das Funkgerät wechselt beim Empfang in den TX-Modus (#11256)

Dieser Fall ist einzigartig für Radios mit einem gemeinsamen Empfangs-/Sendepuffer, richtig? Betrifft also nur die Geräteklasse at86rf2xx

Dies kann zu seltsamen Verhaltensweisen führen, …

Haben Sie einige Beispiele, wo dies zu Problemen führt?

Daher schlage ich vor, Auto ACK als optional zu belassen und die ACK-Antwort in Software zu implementieren

Haben Sie Zahlen zu den Auswirkungen? Flash-Größe/RAM-Auslastung, aber auch Stromverbrauch, da die MCU länger aufwachen muss. Wie viel Zeit vergeht zwischen Frame-Empfang und Ack-Timeout und ist es realistisch, ACKs in Software zu handhaben, wenn das Funkgerät über SPI verbunden ist?

Neben einem zuverlässigeren L2

Ich bin etwas skeptisch gegenüber dieser Behauptung (falls das aus meinem Kommentar noch nicht klar war), die Handhabung von L2-Acks ist ein weicher Echtzeitfall (fehlende Fristen beeinträchtigen den Service) und die Handhabung in Software stellt eine harte Anforderung an die Echtzeitverhalten von RIOT.

Ich habe nichts gegen Software-L2-Acks, wenn dies eine harte Anforderung für einige bestimmte MAC-Schichten ist, aber das wird in der Beschreibung hier nicht erwähnt.

Hallo @bergzand

Realistisch gesehen, wie oft verursacht dies tatsächlich Schaden? Wie viel Prozent der Nachrichten werden bestätigt, während sie tatsächlich von der MCU verworfen werden?

Für die oberen Schichten ist es keine große Sache (wenn man bedenkt, dass sie normalerweise die besten Bemühungen sind).
Einige MAC- und Sub-MAC-Schichten (OpenThread, TSCH) verwenden jedoch die ACK zum Aktualisieren von Nachbarinformationen.

Dieser Fall ist einzigartig für Radios mit einem gemeinsamen Empfangs-/Sendepuffer, richtig? Betrifft also nur die Geräteklasse at86rf2xx

Wahr. Ich weise nur auf Szenarien hin, in denen dies passieren könnte.

Haben Sie einige Beispiele, wo dies zu Problemen führt?

Wenn Benutzern der MAC-Schicht falsche Informationen gegeben werden (z. B. Mesh Link Establishment), würde dies wahrscheinlich die Verbindungsqualität beeinträchtigen. Mir ist bewusst, dass wir so etwas noch nicht in RIOT haben (und Stacks, die es verwenden, implementieren das Feature bereits).

Haben Sie Zahlen zu den Auswirkungen? Flash-Größe/RAM-Auslastung, aber auch Stromverbrauch, da die MCU länger aufwachen muss. Wie viel Zeit vergeht zwischen Frame-Empfang und Ack-Timeout und ist es realistisch, ACKs in Software zu handhaben, wenn das Funkgerät über SPI verbunden ist?

Leider nicht. Da es nicht implementiert ist, habe ich keine Zahlen zum Vergleichen. Ich habe nur einige Testzweige mit automatischer Bestätigung, aber ich habe nicht tiefer getestet.

Ich bin etwas skeptisch gegenüber dieser Behauptung (falls das aus meinem Kommentar noch nicht klar war), die Handhabung von L2-Acks ist ein weicher Echtzeitfall (fehlende Fristen beeinträchtigen den Service) und die Handhabung in Software stellt eine harte Anforderung an die Echtzeitverhalten von RIOT.

Es gibt einige Informationen von Tiny OS, dass Software-ACK tendenziell höhere Drops haben (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt), aber zumindest es gibt keine Fehlalarme.
AFAIK IEEE802.15.4 spricht nicht über harte Einschränkungen (nur über Timeout-Werte). Wenn ein ACK-Paket nicht rechtzeitig geliefert wird, wird es als verloren angenommen. Aber wie gesagt, ich habe keine Informationen darüber, wie gut das Betriebssystem mit Software-ACKs funktioniert. Wäre interessant ein paar Benchmarks zu haben

Ich habe nichts gegen Software-L2-Acks, wenn dies eine harte Anforderung für einige bestimmte MAC-Schichten ist, aber das wird in der Beschreibung hier nicht erwähnt.

Wir müssen Software-ACK sowieso für Radios implementieren, die Auto ACK nicht unterstützen, und Funktionen, die in Hardwarebeschleunigern nicht verfügbar sind (ich kenne keine Radios, die Enhanced ACKs unterstützen, um ehrlich zu sein).
Die Frage ist, wollen wir, dass dies für unsere Standardkonfigurationen optional oder obligatorisch ist? Wie zuvor beschrieben, besteht die Idee nicht darin, die Auto ACK-Unterstützung zu entfernen, sondern eine bessere Unterstützung von L2 zu haben. Wir können Auto ACK immer noch aktivieren, wenn wir wollen (deshalb habe ich vorgeschlagen, Radio Caps in https://github.com/RIOT-OS/RIOT/pull/11473 hinzuzufügen)

Vielleicht irre ich mich, aber die Lösung scheint einfach:

• Wir implementieren eine (hardwareunabhängige) ARQ -> das wollen wir unabhängig von dieser Diskussion.
• Wir vergleichen die Leistung (und Interoperabilität) von Hardware- und Softwareimplementierungen.
• Wir entscheiden uns für eine plattformspezifische Voreinstellung, die das Kompilieren der anderen nicht verhindert.

Als Nebenknoten: Die Tatsache, dass wir nie mit dem von @jia200x hervorgehobenen Problem konfrontiert waren, kann mit fehlenden MAC-Schichten auf einem Radio in RIOT zusammenhängen. Darüber hinaus tolerieren wir bei verlustbehafteten Funkgeräten mit geringer Leistung sowieso einen gewissen Verlust.

Wie wichtig sind Software-ACKs für 6TiSCH? IIRC, OpenWSN verwendet Software-ACKs teilweise, um die Verbindungsqualität zwischen Nachbarn zu verfolgen.

Wie wichtig sind Software-ACKs für 6TiSCH? IIRC, OpenWSN verwendet Software-ACKs teilweise, um die Verbindungsqualität zwischen Nachbarn zu verfolgen.

6TiSCH spricht nicht gegen Hardware-ACKs, erfordert aber erweiterte ACKs, um Timing-Informationen weiterzugeben. In OpenWSN wird dies vom Paket selbst gehandhabt.

* und Enhanced ACKs werden von der mir bekannten Hardware nicht unterstützt.

Darüber hinaus besteht das Problem mit Hardware-Bestätigungsfunktionen in einigen Fällen darin, dass sie die volle Verantwortung für den Mechanismus übernehmen, ohne notwendigerweise relevante Informationen offenzulegen, wie z. B. empfangene ACK oder Anzahl der Wiederholungen. Mit 6TiSCH können Sie einen Frame in einer anderen Zelle erneut übertragen, was diese Art von Informationen erfordert. Daher basiert OpenWSN auf einem eingeschränkten Funktionsumfang von Funkgeräten und implementiert alle anderen MAC-Komponenten in Software.

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität gab. Es wird geschlossen, wenn keine weiteren Aktivitäten stattfinden. Wenn Sie möchten, dass ich dieses Problem ignoriere, markieren Sie es bitte mit dem Label „State: don’t stale“. Vielen Dank für Ihre Beiträge.