yorhel@gmail.com wrote:
> I have used the NTP pool project for quite some time on several servers
> now, and I decided I wanted to help the project by donating an NTP
> server too. The problem is though, that my server has a badly drifting
> system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
> that by running ntpdate as an hourly cron-job. But to run an NTP server
> I obviously need something better than that.
>
> I have tried to play around with ntpd, but it didn't want to correct my
> system time. A few hours after running ntpdate and starting ntpd, the
> system time has drifted away again.
> 'ntpq -p' tells me all the servers I've configured are rejected, and
> the offset keeps growing from -100 (at ntpd startup) to -47000 (about
> an hour after ntp startup)
>
> Is it possible to correct the system time somehow (preferably using
> ntpd) so I can run an accurate ntp server?
>
What hardware platform and OS are you running on?
Nvidia Chipset? Linux?

uwe

Uwe Klein wrote:
> yorhel@gmail.com wrote:
> > I have used the NTP pool project for quite some time on several servers
> > now, and I decided I wanted to help the project by donating an NTP
> > server too. The problem is though, that my server has a badly drifting
> > system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
> > that by running ntpdate as an hourly cron-job. But to run an NTP server
> > I obviously need something better than that.
> >
> > I have tried to play around with ntpd, but it didn't want to correct my
> > system time. A few hours after running ntpdate and starting ntpd, the
> > system time has drifted away again.
> > 'ntpq -p' tells me all the servers I've configured are rejected, and
> > the offset keeps growing from -100 (at ntpd startup) to -47000 (about
> > an hour after ntp startup)
> >
> > Is it possible to correct the system time somehow (preferably using
> > ntpd) so I can run an accurate ntp server?
> >
> What hardware platform and OS are you running on?
> Nvidia Chipset? Linux?

Oops, forgot to mention...
SuperMicro PDSMi motherboard (Intel Chipset) running Arch Linux (2.6.18
kernel)

> uwe

yorhel@gmail.com wrote:
> I have used the NTP pool project for quite some time on several servers
> now, and I decided I wanted to help the project by donating an NTP
> server too. The problem is though, that my server has a badly drifting
> system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
> that by running ntpdate as an hourly cron-job. But to run an NTP server
> I obviously need something better than that.
>
> I have tried to play around with ntpd, but it didn't want to correct my
> system time. A few hours after running ntpdate and starting ntpd, the
> system time has drifted away again.
> 'ntpq -p' tells me all the servers I've configured are rejected, and
> the offset keeps growing from -100 (at ntpd startup) to -47000 (about
> an hour after ntp startup)
>
> Is it possible to correct the system time somehow (preferably using
> ntpd) so I can run an accurate ntp server?
>
Yes, but this requires proper configuration (using ntp.conf) to do so.
If you would post the contetnts of ntp.conf and the output of ntpq -p
that would be a start.
Tim Keck

Tim Keck wrote:
> yorhel@gmail.com wrote:
> > I have used the NTP pool project for quite some time on several servers
> > now, and I decided I wanted to help the project by donating an NTP
> > server too. The problem is though, that my server has a badly drifting
> > system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
> > that by running ntpdate as an hourly cron-job. But to run an NTP server
> > I obviously need something better than that.
> >
> > I have tried to play around with ntpd, but it didn't want to correct my
> > system time. A few hours after running ntpdate and starting ntpd, the
> > system time has drifted away again.
> > 'ntpq -p' tells me all the servers I've configured are rejected, and
> > the offset keeps growing from -100 (at ntpd startup) to -47000 (about
> > an hour after ntp startup)
> >
> > Is it possible to correct the system time somehow (preferably using
> > ntpd) so I can run an accurate ntp server?
> >
> Yes, but this requires proper configuration (using ntp.conf) to do so.
> If you would post the contetnts of ntp.conf and the output of ntpq -p
> that would be a start.
> Tim Keck

# ntp.conf
restrict default noquery notrust nomodify
restrict 127.0.0.1

# I'm using the ntp pool for now, I'll change
# to manually found servers when I join the pool
server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org

restrict 0.nl.pool.ntp.org noquery nomodify
restrict 1.nl.pool.ntp.org noquery nomodify
restrict 2.nl.pool.ntp.org noquery nomodify

driftfile /etc/ntp.drift
# -- end

And 'ntpq -p' about one hour after starting ntpd:
$ ntpq -p
remote refid st t when poll reach delay offset
jitter
================================================== ============================
www.dreamcommun 130.88.200.98 3 u 47 64 377 4.123 -48826.
1992.79
lolly.dreamcomm 194.159.73.44 3 u 44 64 377 4.044 -50219.
1708.12
mallos2.xs4all. 131.211.80.155 3 u 6 64 377 14.200 -49269.
1993.65

In article <1165146398.391563.76000@f1g2000cwa.googlegroups.co m>,
yorhel@gmail.com wrote:

> I have used the NTP pool project for quite some time on several servers
> now, and I decided I wanted to help the project by donating an NTP
> server too. The problem is though, that my server has a badly drifting
> system time (it's about 10-15 ms/s too fast). I temporarily "fixed"

Please don't even think of adding that machine to the pool! If it
is gaining, you have problems other than lost interrupts (which can
sometimes be mitigated by setting HZ to a sensible value, but always
cause the clock to run slow). It may well mean that the crystal isn't
properly disciplining the software clock.

If you are unable to fix the underlying problem, you may still be able to
compensate, but for local use only, please, by using tickadj to correct the
frequency in multiples of 100 parts per million, to get you within 50 ppm.

yorhel@gmail.com wrote:

> I have used the NTP pool project for quite some time on several servers
> now, and I decided I wanted to help the project by donating an NTP
> server too. The problem is though, that my server has a badly drifting
> system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
> that by running ntpdate as an hourly cron-job. But to run an NTP server
> I obviously need something better than that.
>
> I have tried to play around with ntpd, but it didn't want to correct my
> system time. A few hours after running ntpdate and starting ntpd, the
> system time has drifted away again.
> 'ntpq -p' tells me all the servers I've configured are rejected, and
> the offset keeps growing from -100 (at ntpd startup) to -47000 (about
> an hour after ntp startup)
>
> Is it possible to correct the system time somehow (preferably using
> ntpd) so I can run an accurate ntp server?
>

Of course it's possible! Most of us do it all day, every day.

It's not clear from your post what your problem might be! Try starting
ntpd and letting it run for at least thirty minutes. Then say "ntpq
-p"; capture the output and post it. Post your ntp.conf file as well.

yorhel@gmail.com wrote:

> Tim Keck wrote:
>
>>yorhel@gmail.com wrote:
>>
>>>I have used the NTP pool project for quite some time on several servers
>>>now, and I decided I wanted to help the project by donating an NTP
>>>server too. The problem is though, that my server has a badly drifting
>>>system time (it's about 10-15 ms/s too fast). I temporarily "fixed"
>>>that by running ntpdate as an hourly cron-job. But to run an NTP server
>>>I obviously need something better than that.

>>Yes, but this requires proper configuration (using ntp.conf) to do so.
>>If you would post the contetnts of ntp.conf and the output of ntpq -p
>>that would be a start.
>>Tim Keck
>
>
> # ntp.conf
> restrict default noquery notrust nomodify
> restrict 127.0.0.1
>
> # I'm using the ntp pool for now, I'll change
> # to manually found servers when I join the pool
> server 0.nl.pool.ntp.org
> server 1.nl.pool.ntp.org
> server 2.nl.pool.ntp.org
>
> restrict 0.nl.pool.ntp.org noquery nomodify
> restrict 1.nl.pool.ntp.org noquery nomodify
> restrict 2.nl.pool.ntp.org noquery nomodify
>
> driftfile /etc/ntp.drift
> # -- end
>
> And 'ntpq -p' about one hour after starting ntpd:
> $ ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ================================================== ============================
> www.dreamcommun 130.88.200.98 3 u 47 64 377 4.123 -48826.
> 1992.79
> lolly.dreamcomm 194.159.73.44 3 u 44 64 377 4.044 -50219.
> 1708.12
> mallos2.xs4all. 131.211.80.155 3 u 6 64 377 14.200 -49269.
> 1993.65
>

Lose the restrict statements!!!!!

You cannot use restrict with the pool servers because the code does not
support DNS lookups; you would have to specify actual numeric IP
addresses in the restrict statements in order to make it work.

I suspect that "restrict notrust" is your problem. The semantics of
notrust vary with the version of ntpd but the current meaning requires
cryptographic authentication which you have not set up.

yorhel@gmail.com writes:
> server 0.nl.pool.ntp.org
> server 1.nl.pool.ntp.org
> server 2.nl.pool.ntp.org
>
> restrict 0.nl.pool.ntp.org noquery nomodify
> restrict 1.nl.pool.ntp.org noquery nomodify
> restrict 2.nl.pool.ntp.org noquery nomodify

$ host 0.nl.pool.ntp.org
0.nl.pool.ntp.org has address 32.112.56.88
0.nl.pool.ntp.org has address 62.166.22.106
0.nl.pool.ntp.org has address 80.85.129.25
0.nl.pool.ntp.org has address 81.68.241.179
0.nl.pool.ntp.org has address 88.159.80.12
0.nl.pool.ntp.org has address 131.211.84.189
0.nl.pool.ntp.org has address 194.88.2.60
0.nl.pool.ntp.org has address 194.165.35.111
0.nl.pool.ntp.org has address 213.84.230.57

Does the above restriction now work? At one point restrict lines with
multihomed or round-robin hosts would cause the restriction to only be
applied to one of those addresses. It is always possible to have one
address selected for the "server" line and a different address to be
selected for the "restrict" line.

For pools.ntp.org and other round-robin hosts, it is probably safest
to just to use a default restriction that allows any address to tell
you the time. This is what I have used in the past:

restrict default nomodify notrap nopeer
restrict :: nomodify notrap nopeer

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/