Hi folks,
I wanted to report a bug. We use chrony for time synchronization and we have a strict requirement that forces us to limit the slew rate to no more than 250ppm. We noticed that in some conditions, chrony exceeds this limit by >10x. I've collected an strace that shows chrony is indeed the culprit as it is calling the clock_adjtime syscall with the tick and frequency set to 9980 and -140765 which corresponds to roughly -2002ppm.
This bug shows up relatively infrequently under "normal" conditions, but I built a command line tool (
https://github.com/brt-adam-snaider/wreck_time) that continuously modifies the CLOCK_REALTIME with different parameters and found that a semi-consistent number of times, running it with the following configuration for around 30 minutes results in the aforementioned bug in our system (your mileage may vary).
$ sudo ./wreck_time random --frequency 2 --low 100ns --high 10ms
The relevant bits of configuration are
maxslewrate 250
makestep 500 -1 # Different for testing. Generally we have `makestep 0.004 -1`
maxclockerror 10
OS: Linux
Chrony version: Tested on 3.5 and 4.3
~Adam