NTPD howto?

Unruh wrote:
> Markus Rehbach <markus.rehbach@gmx.de> writes:
>
>> Unruh wrote:
>
>>> Why in the world would you use ntp in a virtual machine. Use it in the
>>> underlying operating system, and have the virtual machine get its time
>>> from there. As has been pointed out the virtual machine's clock is
>>> virtual, and could be stopped for arbitrarily long times, as the
>>> underlying system does other things.
>
>> Why? E.g. development of an ISO installation image in a VM with the
>> requirement to have a functional ntpd after installing the ISO.
>
> Don't expect ntp to work on the virtual machine.
>
>
>> Why in the world should it be evil to have a working ntpd in a virtual
>> machine? I have some with stability=0.000 and a very low offset and I'm
>> happy with it.
>
> Who said anything about evil. King Canute was not evil for ordering the
> tide not to come in. Stupid perhaps, or incompetent had he then relied on
> the tide not coming in in his other plans. Not evil.
>

It's totally off topic, but King Canute's ordering the tide is widely
misunderstood. He was demonstrating to his sycophantic followers that
he was *not* all powerful - he was under no illusion that he could
control the tide.

On May 10, 12:02*am, Markus Rehbach <markus.rehb...@gmx.de> wrote:

> Why? E.g. development of an ISO installation image in a VM with the
> requirement to have a functional ntpd after installing the ISO.

Him: It's stupid to shoot yourself in the foot.

You: Well, what if you have to?

If you have to, you have to. There would have to be something
amazingly important about doing it to outweigh the obvious stupidity.

> Why in the world should it be evil to have a working ntpd in a virtual
> machine? I have some with stability=0.000 and a very low offset and I'm
> happy with it.

Because you're trying to stabilize something that is inherently
unstable when there's an obvious superior choice -- synchronize the
virtual machine's clock to the real clock and synchronize the real
clock with NTP.

> You are right, the clock could be stopped for longer times but it is not
> happening here. And you can miss interrupts on real hardware which should
> have nearly the same effect for ntpd.

The problem with physical hardware is completely different from the
problem of virtual hardware. The fundamental problem is that with
virtual hardware, the OS cannot manage the use of a guaranteed rate of
CPU resources. (This is true on some physical platforms, of course,
and it's generally recognized as a serious problem on those
platforms.)

DS

> I can't figure ntpd out.

It's not that hard once you understand that it doesn't do what you
think: it doesn't really keep the clock synchronized to some external
source. Instead, it tries to adjust the *speed* of the local clock, to
account for systematic errors and minor variantions, using an external
reference in order to be able to determine when the local clock is too
fast or too slow.

I.e. it can only do its job if the local clock is already doing an OK
job on its own. If the error in the local clock is mostly coming from
systematic drift, ntpd can get your clock synchronized with
amazing precision. But otherwise, it'll work really hard and perform
very poorly.

IIUC OpenNTPd does something closer to what many people expect: just try
to keep the clock synchronized to external sources. It's simpler and
cannot give you the same accuracy, but if your clock is unreliable
(e.g. its drift varies depending on the machine's load, as seems to be
the case for my DSL home routers), it should at least be able to keep
them more-or-less synchronized (within 1s or so).


Stefan

On May 13, 8:53*am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

> IIUC OpenNTPd does something closer to what many people expect: just try
> to keep the clock synchronized to external sources. *It's simpler and
> cannot give you the same accuracy, but if your clock is unreliable
> (e.g. its drift varies depending on the machine's load, as seems to be
> the case for my DSL home routers), it should at least be able to keep
> them more-or-less synchronized (within 1s or so).

The two programs do the same thing by the same method. There is no way
to keep two clock's synchronized other than to equalize their rates.
Neither of them "synchronizes" clocks by repeatedly jumping one clock
to match another. That would be an absolute disaster on any machine
whose clock was fast.

DS

>> IIUC OpenNTPd does something closer to what many people expect: just try
>> to keep the clock synchronized to external sources. *It's simpler and
>> cannot give you the same accuracy, but if your clock is unreliable
>> (e.g. its drift varies depending on the machine's load, as seems to be
>> the case for my DSL home routers), it should at least be able to keep
>> them more-or-less synchronized (within 1s or so).
> 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.

> 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.


Stefan

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