 | 1 | initial version |
From the capture you provided, none of the "Origin Timestamp" values from the server match any of the client's "Transmit Timestamp" values. The NTP server should copy the value of the NTP client's ntp.xmt field (the "Transmit Timestamp") verbatim into the NTP server's ntp.org field (the "Origin Timestamp").
As to the quality of the IoT's NTP client:
All of the NTP client requests are sourced from the same ephemeral UDP port value of 50023. Generally NTP clients will use different ephemeral port numbers for subsequent request. But because of the "Origin Timestamp" issue, the NTP client can not match the NTP server reply with the the request. It's likely the same NTP client process keeps sending the request resulting in the the same ephemeral port. The IoT NTP client does appear to control the rate of its retries by sending a maximum of four requests before waiting about 10 seconds to try again.
