[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: dom0 and timed
Daniel Hagerty wrote:
> CURRENT's ntp has been less than perfect. I have another thread going
> atm where ntpd is panicing my kernel. Prior to that, ntp failed to
> service requests ... or did so intermittently .... on a domu, ntpdate on
> boot is useless.
As a wild guess, don't use the in-kernel NTP PLL. Either add
"disable kernel" to the ntp config, or remove "options NTP" from the
Forgive me but does this relate more to the actual time keeping? The
main problem I saw was that at some point, ntpd would stop servicing
clients and would require a restart. I have a feeling it related to the
addition and removal of vifs within a dom0. In the end, that may just be
a misconfiguration on my part as ntpd attempts to listen on all
interfaces and maybe doesn't handle the sudden removal (but is that
really my fault?).
In the end it may be worth my while installing from pkgsrc to avoid any
in-tree issues but I was avoiding the installation of redundant packages.
> Is there documentation stating timed is deprecated? If it is merely
> historic, why is it in current? I found the use of broadcast and no
> config quite alluring due to the issues I've had with ntp ... and the
> frequency with which I create new domus.
It's probably still there for the same reasons rsh, uucp, and a
host of other obsolescent programs are there. You might have good
reason to be using the older thing.
That I understand but the guide is still pimping timed. I don't doubt
you in anyway but it would be nice to know why timed is so useless as a
time keeper other than the fact there is now a program that can do
everything. TBH I wouldn't even know about timed if it wasnt' for the guide.
Timed's benefit is that it's simple. Timed's downside is that
it's simple. NTP is much more clever, but at a cost of complexity.
I guess my question would be, at what point is timed's simplicity
detrimental to the time keeping of a network containing 5-6 clients at a
NTP can be configured in a host of ways, including methods that
are comparable to timed; see
I was unaware of this. I'll definately have a play.
AFAIK, all options will involve a small config file, but this
shouldn't be an obstacle. If you're creating lots of domUs,
populating relatively static configuration files ought to be an
automated part of it -- how are you setting timed=YES in rc.conf?
The scenario is not so structured. The issue I have, mentioned above,
meant I ended up spending way more time trying to figure out why a
domu's time wasn't correct than need be. Although I can work around it,
having to restart ntpd every time there is a topology change is not
ideal. To mitigate the wasted time I was looking for something I could
use consistently and what I perceived from documentation as the bsd way.
All that said, my original email was to clarify the directional
broadcast issue wrt a dom0 but I do appreciate your input with time
keeping best practices, as I've never analysed it this much ... ever.
If you can convince me with information that timed is completely useless
(in any area ... accuracy etc), then I'll persist with ntp. I just
haven't been able to find any documentation (other than man pages)
giving much detail on timed at all.
Thanks for your help.
Main Index |
Thread Index |