All I can offer is my direct personal experience... as soon as I switched, the problem went away (and others have echoed that experience).
Chronyd, in a default configuration, was definitely running on all these systems. These are virtual machines, I'd point out, and thus potentially subject to rapid clock drift (although my understanding is that chronyd is supposed to be *better* than ntpd at correcting this). Thomas -----Original Message----- From: John Pilkington [mailto:[email protected]] Sent: Friday, March 11, 2016 2:11 PM To: Thomas Leavitt; [email protected] Subject: Re: [SCIENTIFIC-LINUX-USERS] *RESOLVED* "Not using downloaded repomd.xml because it is older than what we have:" On 11/03/16 19:25, Thomas Leavitt wrote: > I'm suspecting that the repomd.xml problem was a product of chronyd using a > different algorithm than ntpd, and the result of that being a minor > divergence in timestamps between server and client (seven seconds, as > documented, on my case). Flipping the machines in question that were > complaining from chronyd to ntpd seems to have resolved the problem. > > I suspect that this particular issue is going to be near universal (any SL7 > system running chronyd is going to have it), and manifest itself both locally > on internal networks where servers run both 6 (and earlier) and 7, as well as > externally, and that RedHat probably didn't think about the implications of > this for overly time sensitive network applications when they switched the > defaults. I'm guessing applications that actually need tighter links handle > these issues differently, so basically, anything that complains as a result > of this is either mis-configured or overly sensitive. Really, a 7 second time > slew between servers literally thousands of miles away, even in this day and > age, shouldn't produce error messages, especially for something that is as > non-critical as the application in question. > > Regards, > Thomas Leavitt I confess that I have no real evidence on performance differences between NTPD and chronyd, but I would be astonished if properly configured always-on systems were out-of-sync by anything approaching this amount. Far more likely is that some system is running with no access to an external time server. IIRC one of the earlier Fedora releases was set to chase its own tail. John P ________________________________ This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). EAG, Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
