Riot: IEEE802.15.4: HW Auto ACK считается вредным

В большинстве случаев эта практика может быть вредной.

Реально говоря, как часто это причиняет реальный вред? Какой процент сообщений получает подтверждение, но фактически отбрасывается MCU?

Радиостанция переключается в режим TX при приеме (#11256)

Этот случай уникален для радиостанций с общим буфером приема/передачи, верно? Так что влияет только на класс устройств at86rf2xx

Это может привести к странному поведению,…

У вас есть примеры, когда это вызывает проблемы?

Таким образом, я предлагаю оставить Auto ACK необязательным и реализовать ответ ACK в программном обеспечении.

У вас есть какие-то цифры о влиянии на это? Размер флэш-памяти/использование ОЗУ, а также энергопотребление, поскольку микроконтроллеру приходится дольше просыпаться. Кроме того, сколько времени проходит между приемом кадра и тайм-аутом подтверждения, и реально ли обрабатывать ACK в программном обеспечении, если радио подключено через SPI?

Помимо наличия более надежного L2

Я немного скептически отношусь к этому утверждению (если это еще не ясно из моего комментария), обработка пакетов L2 — это мягкий случай в реальном времени (отсутствие крайних сроков ухудшит обслуживание), а обработка их в программном обеспечении предъявляет жесткие требования к поведение RIOT в реальном времени.

Я не возражаю против программных подтверждений L2, если это жесткое требование для некоторых конкретных уровней MAC, но это не упоминается в описании здесь.

Привет @bergzand

Реально говоря, как часто это причиняет реальный вред? Какой процент сообщений получает подтверждение, но фактически отбрасывается MCU?

Для верхних слоев это не имеет большого значения (учитывая, что они обычно делают все возможное).
Однако некоторые уровни MAC и суб-MAC (OpenThread, TSCH) используют ACK для обновления информации о соседях.

Этот случай уникален для радиостанций с общим буфером приема/передачи, верно? Так что влияет только на класс устройств at86rf2xx

Истинный. Я просто указываю сценарии, в которых это может произойти.

У вас есть примеры, когда это вызывает проблемы?

Предоставление неверной информации пользователям MAC-уровня (например, об установлении связи Mesh), вероятно, повлияет на качество связи. Я знаю, хотя у нас пока нет такой вещи в RIOT (и стеки, которые ее используют, уже реализуют эту функцию).

У вас есть какие-то цифры о влиянии на это? Размер флэш-памяти/использование ОЗУ, а также энергопотребление, поскольку микроконтроллеру приходится дольше просыпаться. Кроме того, сколько времени проходит между приемом кадра и тайм-аутом подтверждения, и реально ли обрабатывать ACK в программном обеспечении, если радио подключено через SPI?

К сожалению нет. Поскольку это не реализовано, у меня нет цифр для сравнения. У меня есть только несколько тестовых веток с автоматическим ACK, но я не тестировал глубже.

Я немного скептически отношусь к этому утверждению (если это еще не ясно из моего комментария), обработка пакетов L2 — это мягкий случай в режиме реального времени (отсутствие крайних сроков ухудшит обслуживание), а обработка их в программном обеспечении предъявляет жесткие требования к поведение RIOT в реальном времени.

Есть некоторая информация от Tiny OS о том, что программное обеспечение ACK, как правило, имеет более высокие потери (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt), но, по крайней мере, нет ложных срабатываний.
Насколько я знаю, IEEE802.15.4 не говорит о жестких ограничениях (только о значениях времени ожидания). Если пакет ACK не доставлен вовремя, он считается потерянным. Но, как было сказано ранее, у меня нет информации о том, насколько хорошо ОС работает с программными ACK. Было бы интересно получить бенчмарки

Я не возражаю против программных подтверждений L2, если это жесткое требование для некоторых конкретных уровней MAC, но это не упоминается в описании здесь.

В любом случае нам необходимо внедрить программный ACK для радиостанций, которые не поддерживают Auto ACK и функции, недоступные в аппаратных ускорителях (честно говоря, я не знаю радиостанций, поддерживающих Enhanced ACK).
Вопрос в том, хотим ли мы, чтобы это было необязательным или обязательным для наших конфигураций по умолчанию? Как описано выше, идея состоит не в том, чтобы убрать поддержку Auto ACK, а в том, чтобы улучшить поддержку L2. Мы все еще можем включить Auto ACK, если захотим (поэтому я предложил добавить заглавные буквы радио в https://github.com/RIOT-OS/RIOT/pull/11473)

Возможно, я ошибаюсь, но решение кажется простым:

• Мы реализуем (аппаратно-независимый) ARQ -> мы хотим этого независимо от этого обсуждения.
• Мы сравниваем производительность (и совместимость) аппаратных и программных реализаций.
• Мы хотим использовать настройку по умолчанию для конкретной платформы, которая не мешает компилировать другую.

В качестве побочного узла: тот факт, что мы никогда не сталкивались с проблемой, отмеченной @jia200x , может быть связан с отсутствием MAC-уровней поверх радио в RIOT. Кроме того, с маломощными радиоприемниками с потерями мы все равно допускаем определенные потери.

Насколько важны программные ACK для 6TiSCH? IIRC, OpenWSN частично использует программные ACK для отслеживания качества связи между соседями.

Насколько важны программные ACK для 6TiSCH? IIRC, OpenWSN частично использует программные ACK для отслеживания качества связи между соседями.

6TiSCH не выступает против аппаратных ACK, но требует, чтобы Enhanced ACK передавали информацию о времени. В OpenWSN этим занимается сам pkg.

* и Enhanced ACK не поддерживаются известным мне оборудованием.

Кроме того, проблема с возможностями аппаратного подтверждения в некоторых случаях заключается в том, что он берет на себя полную ответственность за механизм, не обязательно раскрывая соответствующую информацию, такую ​​как полученный ACK или количество повторных попыток. С 6TiSCH вы можете повторно передать кадр в другую ячейку, для которой требуется такая информация. Таким образом, OpenWSN основывается на ограниченном наборе функций радиоустройства и реализует все остальные компоненты MAC в программном обеспечении.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время в ней не было активности. Он будет закрыт, если никакой дальнейшей активности не произойдет. Если вы хотите, чтобы я проигнорировал эту проблему, отметьте ее меткой «Состояние: не устареть». Спасибо за ваш вклад.