Mensagens de classe C falham intermitentemente ao agendar com "tempo absoluto inválido definido no downlink do aplicativo" quando espaçadas próximas.
Existe um tempo mínimo entre as mensagens para o mesmo dispositivo? O ideal seria que eles fossem programados com 130 ms de distância, mas tentamos aumentar o espaçamento para 1000 ms para mitigar o problema
Vemos isso aproximadamente a cada 15 dowlinks
17/11/2020 14:09:30.783 +1300 Sending TTN V3 multicast. topic: v3/halter/devices/2704aee7-7c77-4c99-8d26-cf110b1a90a7/down/push. Payload: {"downlinks":[{"f_port":1,"frm_payload":"ChQKEgoQEg4IAxIFDbQiy10YASDjAQ==","priority":"ABOVE_NORMAL","class_b_c":{"absolute_time":"2020-11-17T01:09:37.000Z","gateways":[{"gateway_ids":{"gateway_id":"eui-00800000a0003582"}}]}}]}
17/11/2020 14:09:30.883 +1300 Sending TTN V3 multicast. topic: v3/halter/devices/2704aee7-7c77-4c99-8d26-cf110b1a90a7/down/push. Payload: {"downlinks":[{"f_port":1,"frm_payload":"ChQKEgoQEg4IAxIFDbQiy10YASDjAQ==","priority":"ABOVE_NORMAL","class_b_c":{"absolute_time":"2020-11-17T01:09:38.000Z","gateways":[{"gateway_ids":{"gateway_id":"eui-00800000a0005314"}}]}}]}
17/11/2020 14:09:37.068 +1300 Serial 2704aee7-7c77-4c99-8d26-cf110b1a90a7: Receiving DownlinkFailed. Payload: {"end_device_ids":{"device_id":"2704aee7-7c77-4c99-8d26-cf110b1a90a7","application_ids":{"application_id":"halter"},"dev_addr":"01415A3E"},"correlation_ids":["as:downlink:01EQ9VZT44AARKQ3V190WBSXZA","as:up:01EQ9W005A64G2W1Y3GQA9S3SR"],"received_at":"2020-11-17T01:09:37.066774351Z","downlink_failed":{"downlink":{"f_port":1,"f_cnt":56,"frm_payload":"ChQKEgoQEg4IAxIFDbQiy10YASDjAQ==","class_b_c":{"gateways":[{"gateway_ids":{"gateway_id":"eui-00800000a0005314"}}],"absolute_time":"2020-11-17T01:09:38Z"},"priority":"ABOVE_NORMAL","correlation_ids":["as:downlink:01EQ9VZT44AARKQ3V190WBSXZA"]},"error":{"namespace":"pkg/networkserver","name":"absolute_time","message_format":"invalid absolute time set in application downlink","code":3}}}
17/11/2020 14:09:37.068 +1300 Serial 2704aee7-7c77-4c99-8d26-cf110b1a90a7: Receiving DownlinkFailed. Payload: {"end_device_ids":{"device_id":"2704aee7-7c77-4c99-8d26-cf110b1a90a7","application_ids":{"application_id":"halter"},"dev_addr":"01415A3E"},"correlation_ids":["as:downlink:01EQ9VZT44AARKQ3V190WBSXZA","as:up:01EQ9W005A64G2W1Y3GQA9S3SR"],"received_at":"2020-11-17T01:09:37.066774351Z","downlink_failed":{"downlink":{"f_port":1,"f_cnt":56,"frm_payload":"ChQKEgoQEg4IAxIFDbQiy10YASDjAQ==","class_b_c":{"gateways":[{"gateway_ids":{"gateway_id":"eui-00800000a0005314"}}],"absolute_time":"2020-11-17T01:09:38Z"},"priority":"ABOVE_NORMAL","correlation_ids":["as:downlink:01EQ9VZT44AARKQ3V190WBSXZA"]},"error":{"namespace":"pkg/networkserver","name":"absolute_time","message_format":"invalid absolute time set in application downlink","code":3}}}
Sem falhas de downlink e mensagens emitidas do gateway
A pilha de coisas para LoRaWAN: ttn-lw-stack
Versão: 3.9.4
Data de construção: 2020-09-23T09: 56: 19Z
Git commit: c4be55c
Versão Go: go1.15.2
OS / Arch: linux / amd64
Determine as causas do tempo absoluto inválido e resolva se há um bug
Fico feliz em testar um PR em nosso ambiente de desenvolvimento
@rvolosatovs ?
@virtualguy esse problema persiste?
Qual é a taxa de dados e em que região você está?
Quando você diz que deseja transmitir com 130 ms de intervalo, está levando em consideração o tempo no ar?
Você pode se inscrever no gateway e eventos do dispositivo final, por meio de $ ttn-lw-cli events ...
, e colar as mensagens de erro exatas que o servidor do gateway relata por que o agendamento falha?
@virtualguy Eu adicionei algumas linhas de depuração extras. Escolha um dos seguintes:
v3.10.7
)Execute grep por #3487
e copie aqui. Também é a única saída que vai para stdout
(como logs vão para stderr
).
Se disser em ScheduleAt
que há poucos RTTs, você pode querer aumentar TTN_LW_EXP_RTT_TTL
(duração, como 6h
por 6 horas, o padrão é 30m
por 30 minutos) e / ou diminua TTN_LW_EXP_SCHEDULE_MIN_RTT_COUNT
para 3 ou algo assim (o padrão é 5). Estes são sinalizadores de recursos temporários.
cc @ymgupta
estamos tendo alguns binários problemáticos em execução que criamos bloqueados em # 3736 antes de podermos coletar logs de seu patch @johanstokking
@virtualguy @johanstokking Aqui estão alguns registros da execução da versão corrigida: https://gist.github.com/kurtmc/75f4ecf93c2f7a1ee8373d3a9c7f181a
Muito obrigado. Desculpas pela resposta atrasada.
Isso vai ser muito útil. Para encontrar a causa raiz, adicionei mais algumas entradas de registro.
Você pode executar isso novamente, com uma nova compilação, usando https://github.com/TheThingsNetwork/lorawan-stack/tree/investigate/3487-abs-downlink-timing?
Se você quiser escolher a dedo em v3.10.x, escolha a dedo 50f56055ba2c0172c002784d0ef22f140b60903c e d1e5305d2363aa8ce8dc485b36c9977857da6b66
Também para a saída, preciso do rastreamento completo, desde o início.
Observe que agora estamos imprimindo o ID do gateway (ou EUI). Se essa for uma informação sensível, redija-a para outro valor significativo ou envie o log por e-mail.
@kurtmc @virtualguy deixe-me saber como podemos ajudar nesta configuração. Se eu precisar enviar a você um binário de imagem do Docker, é só me avisar.
@johanstokking Registros atualizados: https://gist.github.com/kurtmc/041dd593d24fd9f01784e56ec1deb325
Obrigado @kurtmc. Não vejo os erros "sem tempo absoluto" aparecendo aqui, apenas no início, mas isso é normal. Então aqui tudo funcionou conforme o esperado, certo?
@adriansmares a corrida para a qual a sincronização foi corrigida com https://github.com/TheThingsNetwork/lorawan-stack/pull/3794 está realmente acontecendo aqui. Então isso é real, veja:
"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}}]"
Observe que essas instruções estão fora de ordem devido à liberação subjacente; parece que as instruções curtas são liberadas imediatamente e as instruções mais longas são atrasadas.
Eu acho que o problema é que quando (*rtts).Record()
libera o bloqueio de gravação, ambas as chamadas (*rtts).Stats()
simultâneas adquirem um bloqueio de leitura e, portanto, duas chamadas simultâneas (*Scheduler).ScheduleAt()
tornam-se exatamente em sincronia. Como esses estão adquirindo (outro) bloqueio de leitura, eles acontecem simultaneamente, levando à corrupção no estado Scheduler
.
Isso foi corrigido com https://github.com/TheThingsNetwork/lorawan-stack/pull/3794.
@kurtmc existe uma chance de obtermos logs de nível DEBUG
da Pilha de Coisas também? Defina log.level: debug
na configuração YAML.
@virtualguy @kurtmc você pode verificar se isso foi resolvido no último v3.11
?
Observe o pequeno problema, você precisa executar migrações de banco de dados, consulte https://github.com/TheThingsNetwork/lorawan-stack/blob/e56f7f70e60dba8c1ad584411fb63a8c35659e7c/CHANGELOG.md#3110 --- 2021-02-10
Estaremos lançando uma versão 3.11.1 hoje.
Fechado por # 3794
@virtualguy @kurtmc Para
@johanstokking Apenas para informá-lo, atualizamos nosso ambiente de produção para 3.10.10 e ainda estamos vendo o erro de tempo absoluto nos logs.
@kurtmc é esperado no seguinte caso:
Usamos a latência entre o agendamento da mensagem de downlink e o recebimento da confirmação de TX como o tempo de ida e volta. Precisamos de pelo menos 5 deles para obter o valor mediano de forma confiável. Então, ao programar uma mensagem de downlink de classe C com tempo absoluto, o Gateway Server usa o tempo do servidor e o tempo médio de ida e volta para calcular o tempo absoluto (servidor) e o carimbo de data / hora do concentrador correspondente.
Se você ainda vir erros de tempo absolutos, fora dos casos acima, forneça logs de servidor de nível DEBUG.
Definitivamente, ainda estou vendo esse problema no 3.10.10, parece que isso acontece em transmissões consecutivas (1000ms de distância no mesmo dispositivo-id). Enviei através do DEBUG logs via suporte TTI