RTEMS: NTP falls out of sync by 1 minute increments
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
Low
|
mdavidsaver |
Bug Description
On RTEMS osdNTPGet() is called once a minute and uses rtems_bsdnet_
The implementation of rtems_bsdnet_
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 'generalTimeRep
Related branches
Changed in epics-base: | |
status: | Triaged → Fix Committed |
Changed in epics-base: | |
status: | Fix Committed → Fix Released |
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.