On May 13, 6:34*pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

> > The two programs do the same thing by the same method.

> Yet they get very different results. *Not surprinsigly: last I looked at
> their code they used fairly different algorithms.

What I mean by "do the same thing by the same method" I mean that both
of them synchronize your local clock to a remote clocking using the
NTP protocol. They both adjust the local clock by changing its rate of
flow for small errors and by stepping it for large ones.

If you really got very different results with comparable
configurations of the two programs, that's very strange. There's no
particular reason that should happen.

However, if you do encounter a situation where one of these two is
just not working right, it makes sense to try the other. If it's due
to some odd bug or anomaly, there's a good chance the other doesn't
have the same problem.

> > There is no way to keep two clock's synchronized other than to
> > equalize their rates.

> Yes and no. *Depending on whether you care about the clock rate being
> stable or you don't mind fairly large variations in clock rate
> (oscillating around the ideal rate), the algorithms can look
> quite different.

I'm not sure I follow you. Variations in clock rate are the result of
trying to equalize the rate of the local clock to the rate of the
remote clock. There might be tradeoffs in terms of dampening and risks
of over-compensation versus under-compensation. One program might be
more or less stable than the other because of this.

But it's not because of any fundamental difference between the two
programs. They both do the same thing by the same methods with
different implementations.

DS