htpd: increase MIN_FREQHOLD by 3
This means we'll start correcting frequency ~5 minutes after start, not ~3.5 ones. With previos settings I still often see largish ~0.7s initial offsets only about 1/2 corrected before frequency correction kicks in, resulting in ~200ppm "correction" which is then slowly undone. Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
parent
1ab3899d49
commit
79153cb6bc
@ -149,7 +149,7 @@
|
||||
*/
|
||||
|
||||
#define INITIAL_SAMPLES 4 /* how many samples do we want for init */
|
||||
#define MIN_FREQHOLD 10 /* adjust offset, but not freq in this many first adjustments */
|
||||
#define MIN_FREQHOLD 12 /* adjust offset, but not freq in this many first adjustments */
|
||||
#define BAD_DELAY_GROWTH 4 /* drop packet if its delay grew by more than this */
|
||||
|
||||
#define RETRY_INTERVAL 32 /* on send/recv error, retry in N secs (need to be power of 2) */
|
||||
@ -1777,9 +1777,9 @@ update_local_clock(peer_t *p)
|
||||
//15:31:53.473 update from:<IP> offset:+0.000007 delay:0.158142 jitter:0.010922 clock drift:+9.343ppm tc:6
|
||||
//15:32:58.902 update from:<IP> offset:-0.000728 delay:0.158222 jitter:0.009454 clock drift:+9.298ppm tc:6
|
||||
/*
|
||||
* This expression would choose MIN_FREQHOLD + 7 in the above example.
|
||||
* This expression would choose MIN_FREQHOLD + 8 in the above example.
|
||||
*/
|
||||
G.FREQHOLD_cnt = MIN_FREQHOLD + ((unsigned)(abs(tmx.offset)) >> 16);
|
||||
G.FREQHOLD_cnt = 1 + MIN_FREQHOLD + ((unsigned)(abs(tmx.offset)) >> 16);
|
||||
}
|
||||
G.FREQHOLD_cnt--;
|
||||
tmx.status |= STA_FREQHOLD;
|
||||
|
Loading…
Reference in New Issue
Block a user