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