Lorawan-stack: Los mensajes de clase C no se programan de forma intermitente con un tiempo absoluto no válido

@virtualguy, ¿persiste este problema?

¿Cuál es la tasa de datos y en qué región se encuentra?

Cuando dice que quiere transmitir con 130 ms de diferencia, ¿está teniendo en cuenta el tiempo al aire?

¿Puede suscribirse a los eventos de la puerta de enlace y del dispositivo final, a través de $ ttn-lw-cli events ... , y pegar los mensajes de error exactos que el servidor de puerta de enlace informa sobre por qué falla la programación?

@virtualguy Agregué algunas líneas de depuración adicionales. Elija cualquiera de:

1. Aplicar el parche research-3487.txt
2. Cherry-pick https://github.com/TheThingsNetwork/lorawan-stack/commit/f9bbda5db5090dd7eb7bc2d798c92bed82efc2dd
3. Salida https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing (basado en v3.10.7 )

Por favor grep la salida por #3487 y cópiela aquí. También es la única salida que va a stdout (ya que los registros van a stderr ).

Si dice en ScheduleAt que hay muy pocos RTT, es posible que desee aumentar TTN_LW_EXP_RTT_TTL (duración, como 6h durante 6 horas, el valor predeterminado es 30m durante 30 minutos) y / o disminuir TTN_LW_EXP_SCHEDULE_MIN_RTT_COUNT a 3 o algo (el valor predeterminado es 5). Estos son indicadores de características temporales.

cc @ymgupta

para su información, estamos teniendo algunos binarios en ejecución problemáticos que hemos creado, por lo que están bloqueados en # 3736 antes de que podamos recopilar registros de su parche @johanstokking

@virtualguy @johanstokking Aquí hay algunos registros de la ejecución de la versión parcheada: https://gist.github.com/kurtmc/75f4ecf93c2f7a1ee8373d3a9c7f181a

Muchas gracias. Disculpas por la demora en la respuesta.

Esto va a ser muy útil. Para encontrar la causa raíz, agregué algunas entradas de registro más.

¿Puede ejecutar esto nuevamente, con una nueva compilación, usando https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing?

Si desea seleccionar la v3.10.x, seleccione 50f56055ba2c0172c002784d0ef22f140b60903c y d1e5305d2363aa8ce8dc485b36c9977857da6b66

También para la salida, necesito el seguimiento completo, desde el principio.

Tenga en cuenta que ahora estamos imprimiendo el ID de la puerta de enlace (o EUI). Si se trata de información confidencial, elimínela a otro valor significativo o envíe el registro por correo electrónico.

@kurtmc @virtualguy déjame saber cómo podemos ayudar a configurar esto. Si necesito enviarle una imagen binaria de Docker, hágamelo saber.

@johanstokking Registros actualizados: https://gist.github.com/kurtmc/041dd593d24fd9f01784e56ec1deb325

Gracias @kurtmc. No veo los errores de "tiempo absoluto" que aparecen aquí, solo al principio, pero eso es normal. Entonces aquí, todo funcionó como se esperaba, ¿verdad?

@adriansmares, la carrera para la que se corrige la sincronización con https://github.com/TheThingsNetwork/lorawan-stack/pull/3794 realmente está sucediendo aquí. Entonces eso es real, vea:

"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: median is 30.900256ms"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: median is 30.900256ms"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: relative time downlink"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: relative time downlink"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: scheduled"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 1 ScheduleAt: scheduled"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 Record: 30.629582ms at 2021-02-14 21:58:36.014795727 +0000 UTC m=+86.734546258"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 Stats: sorted items: [{30446978 {13835767378842655859 75767631763 0x3a7a1c0}} {30504816 {13835767372765423622 70132850448 0x3a7a1c0}} {30639590 {13835767387106897922 83515681039 0x3a7a1c0}} {30830194 {13835767336362635015 36237283864 0x3a7a1c0}} {30834436 {13835767341445058316 40950998050 0x3a7a1c0}} {30835582 {13835767336764530097 36639178949 0x3a7a1c0}} {30842181 {13835767341958726238 41464666012 0x3a7a1c0}} {30845267 {13835767320071738555 21052514770 0x3a7a1c0}} {30847416 {13835767323811969378 24571520108 0x3a7a1c0}} {30889585 {13835767369324628633 66913280952 0x3a7a1c0}} {30910927 {13835767324288677194 24974486184 0x3a7a1c0}} {30943729 {13835767344594801745 43879516001 0x3a7a1c0}} {30952793 {13835767349113727476 48103474433 0x3a7a1c0}} {30963569 {13835767326445257112 26983582371 0x3a7a1c0}} {30993783 {13835767329486798315 29803898110 0x3a7a1c0}} {31018584 {13835767328128331563 28592914998 0x3a7a1c0}} {31045641 {13835767318515021603 19643281462 0x3a7a1c0}} {31073394 {13835767334606151403 34628283902 0x3a7a1c0}} {31090774 {13835767382891657128 79595407630 0x3a7a1c0}} {31249183 {13835767338921164328 38648329532 0x3a7a1c0}}]"
"1613339916024","15/02/2021 10:58:36.024 +1300","stack_1  | #3487 Stats: sorted items: [{30446978 {13835767378842655859 75767631763 0x3a7a1c0}} {30504816 {13835767372765423622 70132850448 0x3a7a1c0}} {30639590 {13835767387106897922 83515681039 0x3a7a1c0}} {30830194 {13835767336362635015 36237283864 0x3a7a1c0}} {30834436 {13835767341445058316 40950998050 0x3a7a1c0}} {30835582 {13835767336764530097 36639178949 0x3a7a1c0}} {30842181 {13835767341958726238 41464666012 0x3a7a1c0}} {30845267 {13835767320071738555 21052514770 0x3a7a1c0}} {30847416 {13835767323811969378 24571520108 0x3a7a1c0}} {30889585 {13835767369324628633 66913280952 0x3a7a1c0}} {30910927 {13835767324288677194 24974486184 0x3a7a1c0}} {30943729 {13835767344594801745 43879516001 0x3a7a1c0}} {30952793 {13835767349113727476 48103474433 0x3a7a1c0}} {30963569 {13835767326445257112 26983582371 0x3a7a1c0}} {30993783 {13835767329486798315 29803898110 0x3a7a1c0}} {31018584 {13835767328128331563 28592914998 0x3a7a1c0}} {31045641 {13835767318515021603 19643281462 0x3a7a1c0}} {31073394 {13835767334606151403 34628283902 0x3a7a1c0}} {31090774 {13835767382891657128 79595407630 0x3a7a1c0}} {31249183 {13835767338921164328 38648329532 0x3a7a1c0}}]"

Tenga en cuenta que estas declaraciones están fuera de servicio debido a un lavado subyacente; parece que las declaraciones cortas se eliminan inmediatamente y las declaraciones más largas se retrasan.

Creo que el problema es que cuando (*rtts).Record() libera el bloqueo de escritura, ambas llamadas (*rtts).Stats() simultáneas adquieren un bloqueo de lectura, por lo que dos llamadas (*Scheduler).ScheduleAt() simultáneas se sincronizan exactamente. A medida que adquieren (otro) bloqueo de lectura, suceden al mismo tiempo, lo que lleva a la corrupción en el estado Scheduler .

Esto se soluciona con https://github.com/TheThingsNetwork/lorawan-stack/pull/3794.

@kurtmc, ¿hay alguna posibilidad de que podamos obtener registros de nivel de DEBUG de The Things Stack también? Establezca log.level: debug en la configuración YAML.

@virtualguy @kurtmc ¿puedes verificar que esto se resuelva en el último v3.11 ?

Tenga en cuenta el pequeño aumento, debe ejecutar migraciones de base de datos, consulte https://github.com/TheThingsNetwork/lorawan-stack/blob/e56f7f70e60dba8c1ad584411fb63a8c35659e7c/CHANGELOG.md#3110 --- 2021-02-10

Lanzaremos una versión 3.11.1 hoy.

Cerrado por # 3794

@virtualguy @kurtmc Para su información, estamos respaldando esto a 3.10.10 para que podamos actualizar nuestra infraestructura antes. Esté atento al # 3800 y / o suscríbase para recibir notificaciones de lanzamiento aquí.

@johanstokking Solo para informarle, hemos actualizado nuestro entorno de producción a 3.10.10 y todavía vemos el error de tiempo absoluto en los registros.

@kurtmc se espera en el siguiente caso:

1. La puerta de enlace no proporciona marcas de tiempo GPS, por lo que no hay una hora absoluta en la puerta de enlace y debe calcularse en la puerta de enlace.
2. La puerta de enlace no ha transmitido más de 5 mensajes de enlace descendente.
3. La puerta de enlace no ha confirmado más de 5 mensajes de enlace descendente (mediante reconocimiento de TX)

Usamos la latencia entre la programación del mensaje de enlace descendente y la recepción del acuse de recibo de TX como tiempo de ida y vuelta. Necesitamos al menos 5 de ellos para tomar el valor mediano de manera confiable. Luego, al programar un mensaje de enlace descendente de clase C con tiempo absoluto, Gateway Server utiliza el tiempo del servidor y el tiempo medio de ida y vuelta para calcular el tiempo absoluto (servidor) y la marca de tiempo del concentrador correspondiente.

Si aún ve errores de tiempo absoluto, fuera de los casos anteriores, proporcione los registros del servidor de nivel DEBUG.

Definitivamente, aún viendo este problema en 3.10.10, parece que sucede en transmisiones consecutivas (1000ms de diferencia en el mismo ID de dispositivo). He enviado los registros de DEBUG a través del soporte de TTI