Port-xen archive

[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
kernel configuration.

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 time?

    NTP can be configured in a host of ways, including methods that
are comparable to timed; see
http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html

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.

Sarton



Home | Main Index | Thread Index | Old Index