[DNSSD] Address resolve minimum lookup time seems to be too small for MTD/FTD Thread devices. #25049
Comments
|
@ArekBalysNordic I am not following the failure scenario. Is it possible to attach a log that shows the problem? The intent of the current timers is that we should:
So there are three ways a resolve can go:
We should not be waiting until the 45s timer if we have results sitting around waiting to be reported. |
|
@bzbarsky-apple, I've debugged it more today to collect as much info/logs as possible and I can see that behavior occurs only when the Lookup status time is near the There are some logs:
Hmm, It looks like a very rare case and maybe there is not enough time to start the timer or something is scheduled at the wrong time. |
|
OK, so in that case we are coming through We call This is then supposed to call The key part is that we are using different concepts of "now" for the 2231 - 2033 = 198, but 2236 - 2033 = 203, and so by the time we have decided to keep going we have already lost: we are past the 200ms mark, and will not schedule that timer. What probably needs to happen is that we use the same concept of "now" throughout one of these operations. Let me put together a possible fix. |
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Feb 16, 2023
If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip#25049
Or fix NextEventTimeout to handle this case right, which is what #25103 does. Please try that and see whether it fixes the issues you were seeing @ArekBalysNordic. |
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Feb 16, 2023
If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip#25049
|
@bzbarsky-apple It seems that your fix works properly. I've added a simple log: So, I can confirm that this fixes the issue. Thanks for your help! :) |
ArekBalysNordic
pushed a commit
to ArekBalysNordic/sdk-connectedhomeip
that referenced
this issue
Feb 16, 2023
If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip/connectedhomeip#25049
LuDuda
pushed a commit
to nrfconnect/sdk-connectedhomeip
that referenced
this issue
Feb 16, 2023
If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip/connectedhomeip#25049
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Feb 16, 2023
If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip#25049
bzbarsky-apple
added a commit
that referenced
this issue
Feb 20, 2023
If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes #25049
Damian-Nordic
pushed a commit
to Damian-Nordic/sdk-connectedhomeip
that referenced
this issue
Feb 21, 2023
If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip/connectedhomeip#25049
kkasperczyk-no
pushed a commit
to kkasperczyk-no/sdk-connectedhomeip
that referenced
this issue
Mar 15, 2023
If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip/connectedhomeip#25049
kkasperczyk-no
pushed a commit
to kkasperczyk-no/sdk-connectedhomeip
that referenced
this issue
Mar 15, 2023
If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip/connectedhomeip#25049
lecndav
pushed a commit
to lecndav/connectedhomeip
that referenced
this issue
Mar 22, 2023
…ip#25103) If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip#25049
GabrielCouturier
pushed a commit
to NXP/matter
that referenced
this issue
May 12, 2023
…ip#25103) If we cross our min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes project-chip#25049
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproduction steps
Currently, the address resolve's minimum lookup time is set to the default value of 200 ms (https://github.com/project-chip/connectedhomeip/blob/master/src/lib/address_resolve/AddressResolve.h#L144). After performing OTA firmware update the nRF53 device working as MTD/FTD Thread device tries to send the confirmation to an OTA provider and does DNS resolve within ~200 ms. Sometimes, the time of DNS resolve is less than 200 ms, which causes continuing searching here: https://github.com/project-chip/connectedhomeip/blob/master/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp#L80.
and the second attempt of sending confirmation to the OTA provider occurs after elapsing the maximum lookup time (45 seconds). That is a quite long time.
That issue doesn't exist on SED/SSED Thread device types, because there the resolving time is much higher.
Steps to reproduce:
Log from FTD/MTD nRF53 lighting-app example:
Checking node lookup status after 197 msLog from SED nRF53 doorlock-app example:
Checking node lookup status after 1076 msBug prevalence
1-2 times a day
GitHub hash of the SDK that was being used
6ce0f90
Platform
nrf
Platform Version(s)
NCS 2.2.0
Anything else?
No response
The text was updated successfully, but these errors were encountered: