Lorawan-stack: Nachrichten der Klasse C können zeitweise nicht mit ungültiger absoluter Zeit geplant werden

@virtualguy besteht dieses Problem weiterhin?

Wie hoch ist die Datenrate und in welcher Region befindest du dich?

Wenn Sie sagen, dass Sie mit 130 ms Abstand senden möchten, berücksichtigen Sie dann die Sendezeit?

Können Sie die Gateway- und Endgeräteereignisse über $ ttn-lw-cli events ... abonnieren und die genauen Fehlermeldungen einfügen, die der Gateway-Server meldet, warum die Planung fehlschlägt?

@virtualguy Ich habe einige zusätzliche Debug-Zeilen hinzugefügt. Wählen Sie eine von:

1. Wenden Sie den Patch an Untersuchung-3487.txt
2. Rosinenpick https://github.com/TheThingsNetwork/lorawan-stack/commit/f9bbda5db5090dd7eb7bc2d798c92bed82efc2dd
3. Check-out https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing (basierend auf v3.10.7 )

Bitte grep die Ausgabe von #3487 und kopiere sie hier. Es ist auch die einzige Ausgabe, die an stdout (da Protokolle an stderr ).

Wenn in ScheduleAt dass es zu wenige RTTs gibt, möchten Sie vielleicht TTN_LW_EXP_RTT_TTL erhöhen (Dauer, z. B. 6h für 6 Stunden, Standardwert ist 30m für 30 Minuten) und/oder verringern Sie TTN_LW_EXP_SCHEDULE_MIN_RTT_COUNT auf 3 oder etwas (Standard ist 5). Dies sind temporäre Feature-Flags.

cc @ymgupta

Zu Ihrer Information, wir haben einige problematische laufende Binärdateien, die wir auf #3736 erstellt haben, also blockiert, bevor wir Protokolle von Ihrem Patch sammeln können

@virtualguy @johanstokking Hier sind einige Protokolle von der Ausführung der gepatchten Version: https://gist.github.com/kurtmc/75f4ecf93c2f7a1ee8373d3a9c7f181a

Danke vielmals. Entschuldigung für die verspätete Antwort.

Das wird super hilfreich sein. Um die Ursache zu finden, habe ich noch ein paar Log-Einträge hinzugefügt.

Können Sie dies mit einem neuen Build erneut ausführen, indem Sie https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing verwenden?

Wenn Sie auf v3.10.x Rosinenpicken möchten, wählen Sie 50f56055ba2c0172c002784d0ef22f140b60903c und d1e5305d2363aa8ce8dc485b36c9977857da6b66

Auch für die Ausgabe benötige ich den vollständigen Trace, von Anfang an.

Beachten Sie, dass wir jetzt die Gateway-ID (oder EUI) drucken. Wenn es sich um sensible Informationen handelt, ändern Sie diese bitte auf einen anderen aussagekräftigen Wert oder senden Sie das Protokoll per E-Mail.

@kurtmc @virtualguy lassen Sie mich wissen, wie wir dies bei der Einrichtung unterstützen können. Wenn ich Ihnen eine Binärdatei des Docker-Images senden muss, lassen Sie es mich einfach wissen.

@johanstokking Aktualisierte Protokolle: https://gist.github.com/kurtmc/041dd593d24fd9f01784e56ec1deb325

Danke @kurtmc. Ich sehe hier keine "keine absolute Zeit"-Fehler, nur am Anfang, aber das ist normal. Hier hat also alles wie erwartet funktioniert, oder?

@adriansmares das Rennen, für das die Synchronisierung mit https://github.com/TheThingsNetwork/lorawan-stack/pull/3794 behoben wurde, findet hier tatsächlich statt. Das ist also echt, siehe:

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

Beachten Sie, dass diese Anweisungen aufgrund des zugrunde liegenden Flushing nicht in der richtigen Reihenfolge sind. es sieht so aus, als ob kurze Anweisungen sofort geleert und längere Anweisungen verzögert werden.

Ich denke, das Problem besteht darin, dass, wenn (*rtts).Record() die Schreibsperre aufhebt, beide gleichzeitigen (*rtts).Stats() Aufrufe eine Lesesperre erhalten, und so werden zwei gleichzeitige (*Scheduler).ScheduleAt() Aufrufe genau synchron. Wenn diese (eine weitere) Lesesperre erwerben, passieren sie gleichzeitig, was zu einer Beschädigung des Zustands Scheduler .

Dies wird mit https://github.com/TheThingsNetwork/lorawan-stack/pull/3794 behoben

@kurtmc gibt es eine Chance, dass wir auch DEBUG Level-Logs von The Things Stack bekommen? Legen Sie log.level: debug in der YAML-Konfiguration fest.

@virtualguy @kurtmc können Sie überprüfen, ob dies auf den neuesten v3.11 behoben wurde?

Beachten Sie die kleine Beule, Sie müssen DB-Migrationen ausführen, siehe https://github.com/TheThingsNetwork/lorawan-stack/blob/e56f7f70e60dba8c1ad584411fb63a8c35659e7c/CHANGELOG.md#3110 ---2021-02-10

Wir werden heute eine Version 3.11.1 veröffentlichen.

Geschlossen von #3794

@virtualguy @kurtmc Zur Info wir portieren dies auf 3.10.10, damit wir unsere Infrastruktur früher aktualisieren können. Bitte behalten Sie #3800 im Auge und/oder abonnieren Sie hier Release-Benachrichtigungen.

@johanstokking Nur um Sie wissen zu lassen, wir haben unsere Produktionsumgebung auf 3.10.10 aktualisiert und sehen immer noch den absoluten Zeitfehler in den Protokollen.

@kurtmc wird im folgenden Fall erwartet:

1. Das Gateway stellt keine GPS-Zeitstempel zur Verfügung, daher gibt es keine absolute Zeit auf dem Gateway und muss auf dem Gateway berechnet werden
2. Das Gateway hat nicht mehr als 5 Downlink-Nachrichten übertragen
3. Das Gateway hat nicht mehr als 5 Downlink-Nachrichten bestätigt (über TX-Bestätigung)

Wir verwenden die Latenz zwischen der Planung der Downlink-Nachricht und dem Empfangen der TX-Bestätigung als Round-Trip-Zeit. Wir benötigen mindestens 5 davon, um den Medianwert zuverlässig zu ermitteln. Wenn dann eine Klasse-C-Downlink-Nachricht mit absoluter Zeit geplant wird, verwendet Gateway-Server die Serverzeit und die mittlere Umlaufzeit, um die absolute (Server-)Zeit und den entsprechenden Konzentrator-Zeitstempel zu berechnen.

Wenn Sie außerhalb der oben genannten Fälle immer noch absolute Zeitfehler sehen, stellen Sie bitte die Serverprotokolle auf DEBUG-Ebene bereit.

Dieses Problem wird auf jeden Fall in 3.10.10 immer noch angezeigt, es sieht so aus, als ob es bei Übertragungen hintereinander passiert (1000 ms auseinander auf derselben Geräte-ID). Ich habe DEBUG-Protokolle über den TTI-Support gesendet