Chrony – A versatile implementation of the Network Time Protocol | Hacker News Reader

Chrony – A versatile implementation of the Network Time Protocol

chrony.tuxfamily.org

21 pointsingve7 comments

I've been using chrony to sync 18 CPUs in a realtime application. I've found it to be a mixed bag. Once it gets syncing, it's really good. I've got it set up so I'm accurate to w/in a few microseconds on my LAN. But getting the initial sync fast is extremely unintuitive, impossible, poorly documented or some combo of all three. I don't think it was designed with the thought that the machines would get rebooted every night -- which is our case. I had to write some upstart scripts to perform the initial sync and then let chrony take over from there...

I've found it needs the following config. Overall far fewer mystery sync issues than the reference ntpd though, nice software.

  initstepslew 300 ntp.server.example.com

chrony maintainer here. If the initial sync is slow, it probably means the initial offset of the clock is large and chronyd is correcting it by slewing, which may take a long time. You can use the initstepslew or makestep directive to step the clock on start. A configuration optimized for a fast and tight sync with a local NTP server could be:

  server ntp.lan minpoll 2 maxpoll 4 iburst
  makestep 0.1 1

Thanks! I'll try it.

I used to use this and then just switched to systemd's timesyncd. It's already integrated and less dependencies.

https://wiki.archlinux.org/index.php/Systemd-timesyncd

http://www.freedesktop.org/software/systemd/man/systemd-time...

Not sure i would consider being part of the whole systemd blob as having "less dependencies".

Maybe if your chosen distro has adopted systemd already, but then the dependencies are masked but that fact rather than reduced in a real sense.

djb's clockspeed is amazingly simple, straightforward, and reliable: http://cr.yp.to/clockspeed.html . I prefer it to the more complicated ntp daemons because I can make it do exactly what I want in weird situations.

Reply on news.ycombinator.com