| Re: AW: [chrony-users] chronyd: Can' Synchronize WHY ? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
First the diagnosis, then the cure.
There are two separate problems in your system that have been noticed. The
first is that your system hops from one server to other, and sometimes refuses
to use either, because of the discrepancy in the times delivered by the
servers. The second is that large variance in the calculation of the slopeof
the system and computed by chrony.
The second may be due to the computer itself-- the hardware, the software you
are running, or a bug in chrony. The first is a problem with your time
servers it would seem.
The second it would seem a problem with your system.
IS it the large number of realtime threads? To find out run without that
pprogram for a while. Is it hardware or chrony?
Yes, you need that program, but right now you need to find out what is causing
the problem.
Make sure you are saving the measurements log file (in fact save all of them--
measurements, statistics, tracking ) and post them somewhere or plot the offsets from
the various servers. .
My concern is that your system in jumping between the various servers is also
messing up the rate calculations in chrony leading to large variance in the
slope-- which would be a potential
problem with the chrony algorithm if it is happening.
On Sat, 10 Sep 2011, thomas.schmid@xxxxxxxxx wrote:
If the cpu frequency is constant, switching to tsc might be worth a
shot (echo "tsc" to the current_clocksource file).
Ok, I might give that one a try: Any known problems with that ?
The only (relatively) special thing: We have a multi-threaded user space application running
with a lot of threads (~70): About 6...10 of them are running using the (almost) realtime
scheduler the standard Linux kernel provides (no RT-patches applied), and 4..6 are using
very high priorities 80..99.
Might this interfere with chrony ?
Perhaps, can you try it without that application?
I might, but this would be only a theoretical example, as we *need* this application.
This application is one of the core application, and is very sensitive to changes in the timing.
It is also an application which is provided by another company, so we don't have the tools to
debug if something went wrong, ie experimenting with the time keeping.
An experiment to rule out the possibility that the clock discipline is
broken would be to add the noselect option to all servers so chrony
doesn't touch the clock and see if the skew values get better.
OK, can try this as well
In the meantime I have set up a test with a number of my machines running a different
sets of NTP source configurations: Only WAN, WAN+LAN, Only LAN, with1,2,3, or 4 sources.
Thomas
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.