[ntp:questions] Strange server behaviour

Mauro Fiacco Mauro.Fiacco at ipaccess.com
Tue Jan 10 11:19:07 UTC 2006


Danny,

thank you, I really should have looked at the configuration file more carefully.

However, I am not clear on the use of the local clock. My refclock, only
provide pps signal (no timestamp), which is used by the kernel in order
to discipline the internal clock. Do I still not need the local clock??

Without a local clock, NTP does not select any clock.
Moreover, the "ntptime" command now only shows:

...
status 0x2101 (PLL,PPSSIGNAL,NANO,MODE),
....

while, in the past I had:
...
status 0x2103 (PLL,PPSFREQ,PPSSIGNAL,NANO),
...

The kernel is not disciplining the frequency of the internal clock!!

Thank you,

Mauro


On Mon, Jan 09, 2006 at 10:19:51PM -0500, Danny Mayer wrote:
> Date: Mon, 09 Jan 2006 22:19:51 -0500
> From: Danny Mayer <mayer at ntp.isc.org>
> To: Mauro Fiacco <Mauro.Fiacco at ipaccess.com>
> CC: questions at lists.ntp.isc.org
> Subject: Re: [ntp:questions] Strange server behaviour

> Mauro Fiacco wrote:
> > I have a stand-alone NTP server (ntp-v4.2.0), it is a freeBSD PC, with
> > Rubidium PPS source. The server does not synchronize with higher stratum
> > servers (although I monitor other servers with noselect).

> > Only one client uses it for synchronisation, over a private subnet.

> > When I start NTP the server measures its stability of about 5-10ppm 
> > (as reported by ntpdc -c sysinfo), which converges to 2-5ppb within few
> > hours.

> > Once the server has converged to ppb stability, I start my client, a
> > run lasts for several days with the server maintaining good stability.

> > As I am testing with different client configurations, I need to stop and
> > start the client every so often. When I do it, the stability of the
> > server worsen instantaneously to ppm, before re-converge to lower
> > values. As shown in the loopstats below:

> > ... very much stable to ppb range before this....
> > 53744 42322.684 0.000000000 27.103912 0.000000954 0.001390 6
> > 53744 42387.686 0.000000000 27.103912 0.000000954 0.001204 6
> > 53744 42452.689 0.000000000 27.103912 0.000000954 0.001043 6
> > ... here the client was killed ...
> > 53744 42516.691 0.000000000 38.240784 0.000000954 5.568436 6
> > 53744 42579.684 0.000000000 38.240784 0.000000954 4.822407 6
> > 53744 42644.688 0.000000000 38.240784 0.000000954 4.176327 6
> > 53744 42708.691 0.000000000 38.240784 0.000000954 3.616805 6
> > 53744 42771.684 0.000000000 38.240784 0.000000954 3.132245 6
> > 53744 42837.686 0.000000000 27.094574 0.000000954 6.198203 6
> > 53744 42902.689 0.000000000 27.094574 0.000000954 5.367801 6
> > 53744 42966.691 0.000000000 27.094574 0.000000954 4.648652 6
> > 53744 43030.684 0.000000000 27.098007 0.000000954 4.025851 6
> > 53744 43094.686 0.000000000 27.098007 0.000000954 3.486489 6
> > 53744 43158.689 0.000000000 27.098007 0.000000954 3.019388 6
> > 53744 43223.691 0.000000000 27.098007 0.000000954 2.614867 6
> > 53744 43287.684 0.000000000 27.094116 0.000000954 2.264542 6
> > ... slowly converging to ppb....

> > (Note that 0 offset and 0 network jitter are due to the fact that the
> > server is not disciplined to any other server)

> > The problem is repeatable. I know it does make little sense... I am just
> > at a loss with it. Any suggestions on why this is happening?

> > Thank you.

> > Mauro

> > PS:
> > ntp.conf main parameters:

> > keys ./ntp.keys
> > requestkey 1
> > controlkey 1

> > driftfile /etc/ntp.drift

> > enable stats
> > statistics loopstats peerstats clockstats rawstats sysstats
> > filegen loopstats file loopstats type none enable
> > filegen peerstats file peerstats type none enable
> > filegen clockstats file clockstats type none enable
> > filegen rawstats file rawstats type none enable
> > filegen sysstats file sysstats type none enable

> > enable pps
> > server 127.127.22.0
> > fudge 127.127.22.0 stratum 1
> > fudge 127.127.22.0 refid RBDM
> > fudge 127.127.22.0 flag3 1

> > server zzzz.yyyy.net noselect

> > server 127.127.1.0
> > fudge 127.127.1.0 stratum 1

> > restrict default kod notrap nomodify nopeer noquery
> > restrict 127.0.0.1

> I don't understand why you would fudge the refclock to stratum 1 since
> it should be stratum 0 and that's the default for a refclock. Even worse
> you are also using a local clock and fudging it to stratum one. If you
> have a refclock you certainly don't need a local clock. Get rid of that,
> get ride of fudging the stratum of the refclock and things should become
> normal.

> Danny




-- 
Mauro Fiacco 

ip.access Ltd                      
URL: www.ipaccess.com  




More information about the questions mailing list