On 2014-09-21, Markus Wernig <liste...@wernig.net> wrote: > But the system keeps constantly loosing time, at a rate of about two > seconds per minute (which of course makes it unusable).
adjtime(2) can only skew the clock by a maximum of +/- 5ms each second. > Sep 21 13:12:37 secure ntpd[26259]: adjusting local clock by 53.514878s > Sep 21 13:14:47 secure ntpd[26259]: adjusting local clock by 52.869489s > Sep 21 13:16:27 secure ntpd[26259]: adjusting local clock by 54.363131s > > The offest is correct, by the time it writes that message, the system > clock is really that much off the real ntp time. Only that the local > clock never does get adjusted. It gets adjusted, but the drift exceeds the largest possible adjustment. > The clock frequency is also never adjusted, and ntp.drift remains > untouched. ntpd will not establish the frequency correction until the clock has been synced. In short, your system loses time faster than ntpd can correct. -- Christian "naddy" Weisgerber na...@mips.inka.de
