Fix delta calculation with extreme frequency offsets
This should prevent chronyd from getting stuck and refusing new samples due to failing test4 when the current measured frequency offset is close to 1.0. That can happen when the system clock is stepped forward behind chronyd's back.
This commit is contained in:
parent
b261693095
commit
0bb772c575
1 changed files with 1 additions and 1 deletions
|
@ -793,7 +793,7 @@ receive_packet(NTP_Packet *message, struct timeval *now, double now_err, NCR_Ins
|
|||
assuming worst case frequency error between us and the other
|
||||
source */
|
||||
|
||||
delta = local_interval - remote_interval / (1.0 - source_freq_lo);
|
||||
delta = local_interval - remote_interval * (1.0 + source_freq_lo);
|
||||
|
||||
/* Calculate theta. Following the NTP definition, this is negative
|
||||
if we are fast of the remote source. */
|
||||
|
|
Loading…
Reference in a new issue