Riot: IEEE802.15.4: HW Auto ACK considerado dañino

En la mayoría de los casos, esta práctica puede ser dañina.

Hablando de manera realista, ¿con qué frecuencia causa esto un daño real? ¿Qué porcentaje de mensajes se confirman mientras que la MCU los descarta?

La radio cambia al modo TX al recibir (#11256)

Este caso es exclusivo de las radios con un búfer de recepción/transmisión compartido, ¿verdad? Por lo tanto, solo afecta a la clase de dispositivos at86rf2xx

Esto puede producir comportamientos extraños,…

¿Tiene algunos ejemplos en los que esto cause problemas?

Por lo tanto, propongo dejar Auto ACK como opcional e implementar la respuesta ACK en el software.

¿Tiene algunos números sobre el impacto en esto? Tamaño de flash/uso de RAM, pero también uso de energía ya que la MCU tiene que activarse por más tiempo. Además, ¿cuánto tiempo hay entre la recepción del cuadro y el tiempo de espera del acuse de recibo? ¿Es realista manejar los ACK en el software si la radio está conectada a través de SPI?

Además de tener un L2 más confiable

Soy un poco escéptico acerca de esta afirmación (si eso no quedó claro aún en mi comentario), el manejo de L2 acks es un caso suave en tiempo real (los plazos faltantes degradarán el servicio) y el manejo de ellos en el software impone un requisito difícil en el Comportamiento en tiempo real de RIOT.

No me importa el software L2 ACK si es un requisito difícil para algunas capas MAC específicas, pero eso no se menciona en la descripción aquí.

Hola @bergzand

Hablando de manera realista, ¿con qué frecuencia causa esto un daño real? ¿Qué porcentaje de mensajes se confirman mientras que la MCU los descarta?

Para las capas superiores no es gran cosa (considerando que generalmente son los mejores esfuerzos).
Sin embargo, algunas capas MAC y sub-MAC (OpenThread, TSCH) usan el ACK para actualizar la información del vecino.

Este caso es exclusivo de las radios con un búfer de recepción/transmisión compartido, ¿verdad? Por lo tanto, solo afecta a la clase de dispositivos at86rf2xx

Verdadero. Solo estoy señalando escenarios en los que esto podría suceder.

¿Tiene algunos ejemplos en los que esto cause problemas?

Dar información incorrecta a los usuarios de la capa MAC (por ejemplo, establecimiento de enlace de malla) probablemente afectaría la calidad del enlace. Soy consciente de que todavía no tenemos tal cosa en RIOT (y las pilas que lo usan ya implementan la función).

¿Tiene algunos números sobre el impacto en esto? Tamaño de flash/uso de RAM, pero también uso de energía ya que la MCU tiene que activarse por más tiempo. Además, ¿cuánto tiempo hay entre la recepción del cuadro y el tiempo de espera del acuse de recibo? ¿Es realista manejar los ACK en el software si la radio está conectada a través de SPI?

Lamentablemente no. Como no está implementado, no tengo números para comparar. Solo tengo algunas ramas de prueba con ACK automático, pero no probé más profundamente.

Soy un poco escéptico acerca de esta afirmación (si eso no quedó claro aún en mi comentario), el manejo de L2 acks es un caso suave en tiempo real (los plazos faltantes degradarán el servicio) y el manejo de ellos en el software impone un requisito difícil en el Comportamiento en tiempo real de RIOT.

Hay información de Tiny OS de que el software ACK tiende a tener caídas más altas (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt) pero al menos no hay falsos positivos.
AFAIK, el IEEE802.15.4 no habla de restricciones estrictas (solo sobre valores de tiempo de espera). Si un paquete ACK no se entrega a tiempo, se asume que se ha perdido. Pero como dije antes, no tengo información sobre qué tan bien funciona el sistema operativo con los ACK de software. Sería interesante tener algunos puntos de referencia

No me importa el software L2 ACK si es un requisito difícil para algunas capas MAC específicas, pero eso no se menciona en la descripción aquí.

Necesitamos implementar el software ACK de todos modos para las radios que no admiten Auto ACK y las funciones que no están disponibles en los aceleradores de hardware (para ser honesto, no conozco radios que admitan Enhanced ACK).
La pregunta es, ¿queremos que esto sea opcional u obligatorio para nuestras configuraciones predeterminadas? Como se describió anteriormente, la idea no es eliminar el soporte de Auto ACK sino tener un mejor soporte de L2. Todavía podemos habilitar Auto ACK si queremos (es por eso que propuse agregar límites de radio en https://github.com/RIOT-OS/RIOT/pull/11473)

Tal vez me equivoque pero la solución parece simple:

• Implementamos un ARQ (independiente del hardware) -> queremos eso independientemente de esta discusión.
• Comparamos el rendimiento (y la interoperabilidad) de las implementaciones de hardware y software.
• Decidimos por una configuración predeterminada específica de la plataforma, que no impide compilar la otra.

Como nodo secundario: el hecho de que nunca hayamos enfrentado el problema destacado por @jia200x puede estar relacionado con la falta de capas MAC en la parte superior de una radio en RIOT. Además, con las radios con pérdidas de baja potencia toleramos ciertas pérdidas de todos modos.

¿Qué tan importantes son los ACK de software para 6TiSCH? IIRC, OpenWSN usa software ACK en parte para rastrear la calidad del enlace entre vecinos.

¿Qué tan importantes son los ACK de software para 6TiSCH? IIRC, OpenWSN usa software ACK en parte para rastrear la calidad del enlace entre vecinos.

6TiSCH no habla en contra de los ACK de hardware, pero requiere ACK mejorados para pasar información de tiempo. En OpenWSN, esto lo gestiona el propio pkg.

* y los ACK mejorados no son compatibles con el hardware que conozco.

Además, el problema con las capacidades de reconocimiento del hardware en algunos casos es que asume la responsabilidad total del mecanismo sin exponer necesariamente la información relevante, como el ACK recibido o el número de reintentos. Con 6TiSCH, puede retransmitir un cuadro en otra celda, lo que requiere este tipo de información. Por lo tanto, OpenWSN se basa en un conjunto limitado de funciones de dispositivos de radio e implementa todos los demás componentes MAC en el software.

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Si desea que ignore este problema, márquelo con la etiqueta "Estado: no obsoleto". Gracias por sus aportaciones.