NTP root dispersion

I can not tell for sure but I would assume that the version of ntp installed does not have that option since your start up script uses ntpdate.

Post the output of the command:
ntpd --version

The -g option was in implemented in version 4.

Look in the /etc/ directory for a file named release i.e. redhat-release or lsb_release. The contents will contain the version.

Depends on the distribution.

There should be configuration options for ntpd (ought to be in the same place as the filespecification and port options...)

ntpd - NTP daemon program - Ver. 4.2.4p4
OS Version is Debian 5.0.7

Thanks for your help guys!

Running ntpdate at start up performs the same function as the -g option. I would remove the -x from the start up script since kernel time discipline is disabled with this option.

Thanks, but my question is slightly different.

Having an unreliable NTP server - that is a windows clock not syncronised to anything - is it possible to ask the NTP deamon to sync to it no matter what? But not one off, regularly. Stepping time when needed.

Thanks.

That is what ntpd does. It uses a reference clock to cause updates to the local clock.

It works as long as the clocks are reasonably close together (about 10 minutes difference). Now if the Windows reference clock server isn't compatible with ntpd, then it won't work.

but it won't work if the source clock is not stable. I understand that for working properly ntpd needs to see a stable and reliable clock on the other side. A CMOS clock is not, hence ntpd will reject the source.

What I'm wondering is: is there a way to tell ntpd to be less fussy about the source and just sync it (stepping won't be a problem) without rejecting it?

Not necessarily. I have run ntpd using both a local CMOS clock, and synched other systems to that clock. No problem.

Ok, so let's rephrase the question: is there a way to tell NTPD to be less fussy and just sync the clock no matter what happens to the remote NTP? Cannot use a schedule instance of ntpdate. I appreciate that ntpd is designed to keep the clock synced to the millisecond, but this is not my need and for several reasons which are out of my reach I cannot change much on my systems.

The hardware clock is only used to set the system clock at boot up. ntp will also discipline the hardware clock for drift as well as keep its time synced.

It isn't impossible if your system clocks remain fairly stable that you could keep other computers synced using a free running clock.

So why is running ntpdate via cron not an option? You can change the offset limit as well as how often ntp polls a server. However, I am doubt that this will fix the problem.

it's a long story. I can amend the ntp.conf file, but nothing else.

The point is that I understand that when ntpd feels the source clock is unstable, it won't trust it anymore. I had a long conversation on this forum with a very kind forumer about the subject. It makes sense to me, but as said my server does not need to be precise down to the millisecond. I would be happy if it was down to 30 seconds. I agree that stepping time with ntpdate every x minutes would be ideal, but that's not an option. That's why I'm wondering if ntpd can be configured to follow a clock which would normally reject.