Riot: IEEE802.15.4：HW AutoACKは有害と見なされます

ほとんどの場合、この方法は有害です。

現実的に言えば、これが実際に害を及ぼす頻度はどれくらいですか？ 実際にMCUによって破棄されている間に、メッセージの何パーセントが確認されますか？

受信時に無線がTXモードに切り替わります（＃11256）

このケースは、受信/送信バッファが共有されている無線機に固有のものですよね？ したがって、at86rf2xxクラスのデバイスにのみ影響します

これにより、奇妙な動作が発生する可能性があります…

これが問題を引き起こす例はありますか？

したがって、自動ACKをオプションのままにして、ソフトウェアにACK応答を実装することを提案します。

これへの影響についていくつかの数字がありますか？ フラッシュサイズ/ RAM使用量だけでなく、MCUがより長くウェイクアップする必要があるため電力使用量もあります。 また、フレーム受信とackタイムアウトの間にはどのくらいの時間がありますか。無線がSPI経由で接続されている場合、ソフトウェアでACKを処理するのは現実的ですか。

より信頼性の高いL2を持っていることに加えて

私はこの主張に少し懐疑的です（私のコメントからまだ明らかではない場合）、L2 acksの処理はソフトリアルタイムのケースであり（期限を逃すとサービスが低下します）、ソフトウェアでそれらを処理することは厳しい要件を課しますRIOTのリアルタイム動作。

一部の特定のMAC層にとって厳しい要件である場合、ソフトウェアL2の問題は問題ありませんが、ここでの説明では言及されていません。

こんにちは@bergzand

現実的に言えば、これが実際に害を及ぼす頻度はどれくらいですか？ 実際にMCUによって破棄されている間に、メッセージの何パーセントが確認されますか？

上位層の場合、それは大したことではありません（通常は最善の努力であると考えてください）。
ただし、一部のMACおよびサブMACレイヤー（OpenThread、TSCH）は、ACKを使用してネイバー情報を更新します。

このケースは、受信/送信バッファが共有されている無線機に固有のものですよね？ したがって、at86rf2xxクラスのデバイスにのみ影響します

本当です。 これが発生する可能性のあるシナリオを指摘しているだけです。

これが問題を引き起こす例はありますか？

MAC層のユーザーに間違った情報を提供すると（メッシュリンクの確立など）、リンクの品質に影響を与える可能性があります。 RIOTにはまだそのようなものはありませんが（そしてそれを使用するスタックはすでに機能を実装しています）、私は知っています。

これへの影響についていくつかの数字がありますか？ フラッシュサイズ/ RAM使用量だけでなく、MCUがより長くウェイクアップする必要があるため電力使用量もあります。 また、フレーム受信とackタイムアウトの間にはどのくらいの時間がありますか。無線がSPI経由で接続されている場合、ソフトウェアでACKを処理するのは現実的ですか。

残念ながら違います。 実装されていないので、比較する数値がありません。 自動ACKを使用したテストブランチはいくつかありますが、それ以上のテストは行いませんでした。

私はこの主張に少し懐疑的です（私のコメントからまだ明らかではない場合）、L2 acksの処理はソフトリアルタイムのケースであり（期限を逃すとサービスが低下します）、ソフトウェアでそれらを処理することは厳しい要件を課しますRIOTのリアルタイム動作。

Tiny OSから、ソフトウェアACKのドロップが高くなる傾向があるという情報がいくつかあります（https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt）。誤検知はありません。
AFAIK IEEE802.15.4は、ハードコンストレイントについては説明していません（タイムアウト値についてのみ）。 ACKパケットが時間内に配信されない場合、失われたと見なされます。 しかし、前に述べたように、OSがソフトウェアACKでどれだけうまく機能するかについての情報はありません。 いくつかのベンチマークがあると面白いでしょう

一部の特定のMAC層にとって厳しい要件である場合、ソフトウェアL2の問題は問題ありませんが、ここでの説明では言及されていません。

とにかく、自動ACKをサポートしない無線とハードウェアアクセラレータでは利用できない機能に対してソフトウェアACKを実装する必要があります（正直に言うと、拡張ACKをサポートする無線を認識していません）。
問題は、これをデフォルト構成でオプションにするか必須にするかです。 前に説明したように、アイデアはAuto ACKサポートを削除するのではなく、L2のサポートを改善することです。 必要に応じて自動ACKを有効にすることもできます（そのため、https：//github.com/RIOT-OS/RIOT/pull/11473で無線キャップを追加することを提案しました）

たぶん私は間違っていますが、解決策は簡単なようです：

• （ハードウェアに依存しない）ARQを実装します->この議論に関係なくそれが必要です。
• ハードウェアとソフトウェアの実装のパフォーマンス（および相互運用性）を比較します。
• プラットフォーム固有のデフォルト設定を選択します。これにより、他の設定が妨げられることはありません。

サイドノードとして： @ jia200xによって強調された問題に直面したことがないという事実は、RIOTの無線機の上部にあるMACレイヤーの欠落に関連している可能性があります。 さらに、低電力の損失のある無線では、とにかく特定の損失を許容します。

6TiSCHのソフトウェアACKはどのくらい重要ですか？ IIRC、OpenWSNは、ソフトウェアACKを部分的に使用して、ネイバー間のリンク品質を追跡します。

6TiSCHのソフトウェアACKはどのくらい重要ですか？ IIRC、OpenWSNは、ソフトウェアACKを部分的に使用して、ネイバー間のリンク品質を追跡します。

6TiSCHはハードウェアACKに対抗しませんが、タイミング情報を渡すために拡張ACKが必要です。 OpenWSNでは、これはpkg自体によって処理されます。

*および拡張ACKは、私が知っているハードウェアではサポートされていません。

さらに、ハードウェア確認応答機能の問題は、受信したACKや再試行回数などの関連情報を必ずしも公開せずに、メカニズムの全責任を負うことです。 6TiSCHを使用すると、この種の情報を必要とする他のセルでフレームを再送信できます。 したがって、OpenWSNは、限られた無線デバイス機能セットに基づいており、他のすべてのMACコンポーネントをソフトウェアに実装します。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 この問題を無視したい場合は、「状態：古くない」というラベルを付けてください。 貢献していただきありがとうございます。