Sarton O'Brien wrote:
Alan Barrett wrote:"timed -M -F 127.0.0.1" might work. Long ago, there used to be patches (against a version of timed that didn't have a "-F" option) to add a "-N" command line option to make timed believe that ntpd owned the clock, but I can't find them right now, and they don't seem to have made their way into NetBSD's timed. --apb (Alan Barrett)I believe you are correct ... the man page from memory states that '-F localhost' implies -M and will not attempt to alter the local clock due to the self assignment.Now I am convinced that using ntpd is the right way to go however, I am stuck with a new problem (which I've bothered Daniel with off-list) ....I set up ntpd on dom0 and attempted to synchronise with domu clients to no avail. I tested from another box with ntpclient and it succeeded.<copy and paste>I actually sniffed a few packets yesterday and determined via google that the problem is the master ntp server is not synchronising upstream and it seems ntpdate and ntpd are smart enough to know this, whereas ntpclient isn't, which is what I was testing with on another box.On the master ntp server, if I use '/etc/rc.d/ntpdate start' the time is synchronised but if I use 'ntpd -q' it errors with 'no reply'.I tried specifying the config aswell with no luck. </copy and paste>Any ideas? I find it strange that ntpdate works but ntpd -q doesn't .... though this stuff is relatively new to me and I may be missing something.
Alright, it looks like it was my fault. ntpd seems to require more than one server entry even for a 'ntpd -q'. Specifying multiple entries allows everything to function properly and my clients are now synchronising. I was hoping au.pool.ntp.org would be sufficient but I guess it requires more than one reference ... pedantic thing ... but I guess it wouldn't be the defacto standard otherwise.
My original question about broadcasts for dom0 was never resolved, at the very least, I've learned a little about how ntp functions I spose :)
Sarton