On Tue, Dec 12, 2006 at 08:41:12AM +0100, Tore Anderson wrote: > * Kurt Roeckx > > > Can I suggest you run ntpd with the -x option in that case? > > I already do. > > > Both ntpdate and ntpd will by default slew the time if it's smaller > > the < 128 ms, and step when it's bigger. > > I know. Maybe I should have been clearer though, what I'm objecting > to is primarily the suggestion to mimic the way Ubuntu does it, as > they invoke ntpdate with the "-b" parameter in the if-up.d script, > ensuring that the clock will _always_ leap.
-b means always step, -B means slew, and you asked for -B before? It now seems to be using -b if it's a static interfacce. > I also have an objection to the if-up.d script per se, though, but > this is not as strong. I simply do not expect things to happen to my > clock when I fiddle around with my network interfaces. I have always > thought the primary task of ntpdate is to quickly get time roughly > correct at bootup, so that ntpd will have a much easier job of getting > the box completely into sync. When this combo is working ntpd will > ~never step time, even without -x (barring bad hardware). If no NTP > server is available at bootup, well, then you'll just have to wait for > a network connection and possibly step the time then. And isn't that > _exactly_ what ntpd'll do when run without the -x option? Then why > throw ntpdate into the mix here? It's after all less precise than ntpd > so chances are you'll end up with a clock that's more out of sync than > before... ntpdate shouldn't be changing time when ntpd is running, and ntp doesn't get restrarted by default, so I guess I'm still not getting it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]