Lorawan-stack: クラスCメッセージは、無効な絶対時間で断続的にスケジュールに失敗します

@virtualguyこの問題は解決していませんか？

データレートとは何ですか？また、どの地域にいますか？

130ms間隔で送信したい場合、放送時間を考慮していますか？

$ ttn-lw-cli events ...を介してゲートウェイとエンドデバイスのイベントをサブスクライブし、ゲートウェイサーバーがスケジュールが失敗する理由について報告する正確なエラーメッセージを貼り付けることができますか？

@virtualguyいくつかのデバッグ行を追加しました。 次のいずれかを選択してください：

1. パッチ調査を適用する
2. チェリーピックhttps://github.com/TheThingsNetwork/lorawan-stack/commit/f9bbda5db5090dd7eb7bc2d798c92bed82efc2dd
3. チェックアウトhttps://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing（$＃$ v3.10.7基づく）

#3487出力をgrepして、ここにコピーしてください。 これは、 stdout送られる唯一の出力でもあります（ログはstderr送られます）。

それはで言えばScheduleAt少なすぎるのRTTがあることを、あなたが増加する場合がありますTTN_LW_EXP_RTT_TTLのように、（時間を6h 6時間、デフォルトは30m 30分間）および/またはTTN_LW_EXP_SCHEDULE_MIN_RTT_COUNTを3程度に減らします（デフォルトは5）。 これらは一時的な機能フラグです。

cc @ymgupta

fyiパッチからログを収集する前に、＃3736でブロックされたように、ビルドしたバイナリの実行に問題があります@johanstokking

@virtualguy @johanstokkingパッチを適用したバージョンの実行からのログは次のとおりです： https ： //gist.github.com/kurtmc/75f4ecf93c2f7a1ee8373d3a9c7f181a

どうもありがとう。 応答が遅れたことをお詫びします。

これは非常に役立ちます。 根本的な原因を見つけるために、さらにいくつかのログエントリを追加しました。

https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timingを使用して、新しいビルドでこれを再度実行できます

v3.10.xでチェリーピックする場合は、チェリーピック50f56055ba2c0172c002784d0ef22f140b60903cおよびd1e5305d2363aa8ce8dc485b36c9977857da6b66

出力についても、最初から完全なトレースが必要です。

現在、ゲートウェイID（またはEUI）を出力していることに注意してください。 それが機密情報である場合は、それを別の意味のある値に編集するか、ログを電子メールで送信してください。

@kurtmc @virtualguyは、この設定をどのように支援できるかを教えてくれます。 Dockerイメージのバイナリを送信する必要がある場合は、お知らせください。

@johanstokking更新されたログ： https ： //gist.github.com/kurtmc/041dd593d24fd9f01784e56ec1deb325

@kurtmcに感謝します。 ここに「絶対時間なし」のエラーは表示されません。最初だけですが、これは正常です。 だからここでは、すべてが期待どおりに機能しましたよね？

@adriansmaresは、 https：//github.com/TheThingsNetwork/lorawan-stack/pull/3794で同期が修正されているレースが実際にここで行われています。 だからそれは本当です、見てください：

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

これらのステートメントは、基礎となるフラッシュのために順序が狂っていることに注意してください。 短いステートメントはすぐにフラッシュされ、長いステートメントは遅延するようです。

問題は、 (*rtts).Record()が書き込みロックを解放すると、両方の同時(*rtts).Stats()呼び出しが読み取りロックを取得するため、2つの同時(*Scheduler).ScheduleAt()呼び出しが完全に同期することだと思います。 それらが（別の）読み取りロックを取得しているときに、それらは同時に発生し、 Scheduler状態で破損します。

これはhttps://github.com/TheThingsNetwork/lorawan-stack/pull/3794で修正されてい

@kurtmcは、Things StackからもDEBUGレベルのログを取得できる可能性がありますか？ 設定YAMLでlog.level: debugを設定します。

@virtualguy @kurtmcこれが最新のv3.11解決されていることを確認できますか？

マイナーバンプに注意してください。DB移行を実行する必要があります。https：//github.com/TheThingsNetwork/lorawan-stack/blob/e56f7f70e60dba8c1ad584411fb63a8c35659e7c/CHANGELOG.md#3110 --- 2021-02-10を参照して

本日、3.11.1リリースをリリースする予定です。

＃3794で閉鎖

@virtualguy @kurtmc参考までに、これを3.10.10にバックポートしているので、インフラストラクチャをより早く更新できます。 ＃3800に注目するか、ここでリリース通知を購読してください。

@johanstokkingお知らせするために、本番環境を3.10.10にアップグレードしましたが、ログに絶対時間エラーが表示されています。

@kurtmc次の場合に予想されます：

1. ゲートウェイはGPSタイムスタンプを提供しないため、ゲートウェイに絶対時間はなく、ゲートウェイで計算する必要があります
2. ゲートウェイは5つを超えるダウンリンクメッセージを送信していません
3. ゲートウェイは、5つを超えるダウンリンクメッセージを確認していません（TX確認応答を介して）

ダウンリンクメッセージをスケジュールしてからTX確認応答を受信するまでの遅延をラウンドトリップ時間として使用します。 中央値を確実に取得するには、少なくとも5つが必要です。 次に、絶対時間でクラスCダウンリンクメッセージをスケジュールする場合、Gateway Serverは、サーバー時間とラウンドトリップ時間の中央値を使用して、絶対（サーバー）時間と対応するコンセントレーターのタイムスタンプを計算します。

それでも絶対時間エラーが表示される場合は、上記の場合を除いて、DEBUGレベルのサーバーログを提供してください。

3.10.10でもこの問題が発生していることは間違いありませんが、連続した送信（同じデバイスIDで1000ミリ秒離れている）で発生しているように見えます。 TTIサポートを介してDEBUGログを送信しました