On Fri, Jul 26, 2019 at 11:32 AM YUE Daian <[email protected]> wrote: > > I switched to a faster NTP server. It still takes some seconds but > better than before. > > Maybe you are right. Having correct system time is more important than > several seconds...
You're never going to make NTP fast unless you're using a VERY low-latency server - like something on your own LAN. That is just the nature of the protocol - it has to do a round trip, and of course to do anything it needs the interface up, DNS, and so on, and all of these will be starting from cold caches. If you have non-local DNS and non-local NTP then that is multiple round-trips to the internet. > > By the way does "rc_parallel" really makes a difference? > I tried it once before but did not really see much difference. I haven't used OpenRC in ages, but I'm guessing that NTP is set as a dependency somewhere in the chain. It does make sense - lots of services do not like abrupt time changes so generic dependencies will probably assume that you want to set your clocks before starting anything. I'm not sure how ntpdate implements time changes. I know that ntpd will slew the clock gradually for small corrections, but it is a daemon so it can easily implement something like that. A one-shot correction will probably be instant, and thus will be more of an impact on other services. You can probably adjust the dependencies to suit your tastes, but of course you'll have to keep in mind that time changes for running services might or might not be a problem. If you're fairly confident in your hardware clock accuracy (assuming you even have one) that isn't a big deal. If you're talking about some system that doesn't keep time when powered off/etc then you probably don't want your database server to spin up thinking it is 1980 or whatever its epoch is. I did a quick check of what is being done with systemd and ntpdate is needed before the time-sync target, and that is needed before starting cron or any timer units (obvious requirement), and it is also required before spinning up libvirt guests, which also makes sense so that those initialize with a clean clock, though if they update themselves maybe that isn't a hard requirement. -- Rich
