Lorawan-stack: Les messages de classe C ne sont pas programmés par intermittence avec une heure absolue invalide

@virtualguy est-ce que ce problème persiste ?

Quel est le débit de données et dans quelle région êtes-vous ?

Quand vous dites que vous voulez émettre avec un intervalle de 130 ms, tenez-vous compte du temps d'antenne ?

Pouvez-vous vous abonner aux événements de passerelle et de périphérique final, via $ ttn-lw-cli events ... , et coller les messages d'erreur exacts que Gateway Server signale sur les raisons de l'échec de la planification ?

@virtualguy J'ai ajouté quelques lignes de débogage supplémentaires. Choisissez l'un des éléments suivants :

1. Appliquer le correctif enquête-3487.txt
2. Cherry-pick https://github.com/TheThingsNetwork/lorawan-stack/commit/f9bbda5db5090dd7eb7bc2d798c92bed82efc2dd
3. Consultez https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing (basé sur v3.10.7 )

Veuillez saisir la sortie par #3487 et copier ici. C'est également la seule sortie qui va à stdout (comme les journaux vont à stderr ).

S'il est indiqué dans ScheduleAt qu'il y a trop peu de RTT, vous voudrez peut-être augmenter TTN_LW_EXP_RTT_TTL (durée, comme 6h pour 6 heures, la valeur par défaut est 30m pendant 30 minutes) et/ou diminuez TTN_LW_EXP_SCHEDULE_MIN_RTT_COUNT à 3 ou quelque chose (la valeur par défaut est 5). Ce sont des indicateurs de fonctionnalité temporaires.

cc @ymgupta

Pour info, nous avons des problèmes de fonctionnement des binaires que nous avons construits, donc bloqués sur #3736 avant de pouvoir collecter les journaux de votre patch @johanstokking

@virtualguy @johanstokking Voici quelques journaux de l'exécution de la version corrigée : https://gist.github.com/kurtmc/75f4ecf93c2f7a1ee8373d3a9c7f181a

Merci beaucoup. Désolé pour la réponse tardive.

Cela va être super utile. Pour trouver la cause première, j'ai ajouté quelques entrées de journal supplémentaires.

Pouvez-vous l'exécuter à nouveau, avec une nouvelle version, en utilisant https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing ?

Si vous voulez choisir la version 3.10.x, choisissez 50f56055ba2c0172c002784d0ef22f140b60903c et d1e5305d2363aa8ce8dc485b36c9977857da6b66

Aussi pour la sortie, j'ai besoin de la trace complète, depuis le début.

Notez que nous imprimons maintenant l'ID de la passerelle (ou EUI). S'il s'agit d'informations sensibles, veuillez les rédiger en une autre valeur significative ou envoyer le journal par e-mail.

@kurtmc @virtualguy m'a fait savoir comment nous pouvons aider cette configuration. Si je dois vous envoyer une image binaire de Docker, faites-le moi savoir.

@johanstokking Journaux mis à jour : https://gist.github.com/kurtmc/041dd593d24fd9f01784e56ec1deb325

Merci @kurtmc. Je ne vois pas les erreurs "pas de temps absolu" apparaître ici, seulement au début mais c'est normal. Alors là, tout a fonctionné comme prévu, non ?

@adriansmares la course pour laquelle la synchronisation est corrigée avec https://github.com/TheThingsNetwork/lorawan-stack/pull/3794 se passe réellement ici. Donc c'est vrai, voir :

"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}}]"

Notez que ces instructions sont dans le désordre en raison d'un vidage sous-jacent ; il semble que les instructions courtes soient supprimées immédiatement et que les instructions plus longues soient retardées.

Je pense que le problème est que lorsque (*rtts).Record() libère le verrou en écriture, les deux appels (*rtts).Stats() simultanés acquièrent un verrou en lecture, et donc deux appels (*Scheduler).ScheduleAt() simultanés deviennent exactement synchronisés. Au fur et à mesure que ceux-ci acquièrent (un autre) verrou en lecture, ils se produisent simultanément, entraînant une corruption dans l'état Scheduler .

Ceci est corrigé avec https://github.com/TheThingsNetwork/lorawan-stack/pull/3794.

@kurtmc y a-t-il une chance que nous puissions également obtenir des journaux de niveau DEBUG de The Things Stack ? Définissez log.level: debug dans la configuration YAML.

@virtualguy @kurtmc pouvez-vous vérifier que cela est résolu le dernier v3.11 ?

Notez la petite bosse, vous devez exécuter des migrations de bases de données, voir https://github.com/TheThingsNetwork/lorawan-stack/blob/e56f7f70e60dba8c1ad584411fb63a8c35659e7c/CHANGELOG.md#3110 ---2021-02-10

Nous allons lancer une version 3.11.1 aujourd'hui.

Fermé par #3794

@virtualguy @kurtmc Pour info, nous rétroportons ceci vers 3.10.10 afin que nous puissions mettre à jour notre infrastructure plus tôt. Veuillez garder un œil sur #3800 et/ou abonnez-vous aux notifications de publication ici.

@johanstokking Juste pour vous informer, nous avons mis à niveau notre environnement de production vers 3.10.10 et nous voyons toujours l'erreur de temps absolue dans les journaux.

@kurtmc il est attendu dans le cas suivant :

1. La passerelle ne fournit pas d'horodatage GPS, il n'y a donc pas d'heure absolue sur la passerelle et elle doit être calculée sur la passerelle
2. La passerelle n'a pas transmis plus de 5 messages descendants
3. La passerelle n'a pas confirmé plus de 5 messages de liaison descendante (via l'accusé de réception TX)

Nous utilisons la latence entre la planification du message de liaison descendante et la réception de l'accusé de réception TX comme temps d'aller-retour. Nous avons besoin d'au moins 5 d'entre eux pour prendre la valeur médiane de manière fiable. Ensuite, lors de la planification d'un message de liaison descendante de classe C avec une heure absolue, Gateway Server utilise l'heure du serveur et la durée médiane aller-retour pour calculer l'heure absolue (serveur) et l'horodatage du concentrateur correspondant.

Si vous voyez encore des erreurs de temps absolu, en dehors des cas ci-dessus, veuillez fournir les journaux du serveur de niveau DEBUG.

Voyant certainement toujours ce problème dans 3.10.10, il semble que cela se produise lors de transmissions dos à dos (à 1000 ms d'intervalle sur le même identifiant de périphérique). J'ai envoyé des journaux DEBUG via le support TTI