On Friday, 26 July 2019 16:49:25 BST Rich Freeman wrote: > On Fri, Jul 26, 2019 at 11:32 AM YUE Daian <sheepd...@gmail.com> 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.
Just a thought - is the hwclock service in the boot run level and running? I think it will restore the time stored on the hwclock to the system and then gradually update it as the ntp-client starts communicating with various time servers. At least this is how chrony does it. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
