RTEMS: NTP falls out of sync by 1 minute increments

[mdavidsaver]

On RTEMS osdNTPGet() is called once a minute and uses rtems_bsdnet_get_ntp() to send a request, wait for a response, from an NTP server. This is done with a UDP socket created/bound during osdNTPInit() and kept open between calls to osdNTPGet().

The implementation of rtems_bsdnet_get_ntp() up to at least RTEMS 4.10.2 is to send a single UDP packet, then wait for a single packet in response. If however, the response is not the first packet in the socket receive buffer, then rtems_bsdnet_get_ntp() will operate on old/invalid data.

Prior to Base 3.14.12 the UDP socket used was bound to the well known ntp port (123). So any NTP broadcasts would be received. This causes intermittent "glitches" which vary in magnitude depending on the frequency of broadcasts, and the time between the broadcast and the period with which the "NTPTimeSync" thread call osdNTPGet(). If broadcasts are sent more than once per minute, then the NTP time source will fall behind consistently.

Base 3.14.12 changed to binding a random port so broadcasts will no longer be received unintentionally.

With this fix there is still the possibility for duplication or late arrival of reply packets to cause the NTP time source to fall behind. While unlikely, I have observed this. The symptom is that the NTP time falls behind in increments of 1 minute each minute to a maximum determined by the socket buffer size.

This issue can be observed in the output of 'generalTimeReport(2)' and 'NTPTime_Report(2)'.

[mdavidsaver (mdavidsaver)]

This patch adds a call recvfrom() with MSG_DONTWAIT in a loop just before calling rtems_bsdnet_get_ntp() to clear out the receive buffer.

I'd like to apply this to the 3.14 branch.