topic Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm in Operating System - Linux

NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Sun, 02 Nov 2008 09:44:04 GMT

does anyone know how to change the treshold of 128ms in NTP.

in order to ignore these alarms:

Oct 27 14:44:15 rt1 ntpd[19830]: synchronisation lost
Oct 27 15:08:25 rt1 ntpd[19830]: time reset 0.688591 s
Oct 27 15:08:25 rt1 ntpd[19830]: synchronisation lost
Oct 27 15:28:45 rt1 ntpd[19830]: time reset 0.462257 s

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

Johnson Punniyalingam — Mon, 03 Nov 2008 05:55:31 GMT

Hi,

try this

sntp -r

"128mns should be default valune in NTP" avoid changing that" you should check why you server not able to timesync problem, changing the trshold will not server you better (its my opion)

Thanks,
Johnson

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Tue, 04 Nov 2008 10:18:08 GMT

hello,
It is bad idea to change the 128ms threshold,it degrades the ntp kernel algorithms.
This can occasionaly caused by a poor hardware bios clock or poor configuration settings. Using systohc with ntp running can also upset it.
You do not provide a lot of detail , about your environment .

Please could you let us see ntp.conf file the output of ntpq -p the release (ntpdc -c ver) the ntp kernel state (ntpdc -c kerninfo) and the release of Linux .
Is the system running under vmware ?
Mike

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Tue, 04 Nov 2008 12:24:17 GMT

Hi
no the system is not runing under VMware
from some reason some of my NTP clients gets this error.
is there any Bios parameter that might effect the CPU clock (to be more accurately).
thanks

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Tue, 04 Nov 2008 12:37:09 GMT

Hello Zauer ,
The bios clock is built in to the hardware and in most cases cannot be changed. Its accuracy is determined at manufacturing time.
If you provide the information I asked for from the systems which have the error I may be able to help further by suggesting other NTP settings to try, also please supply the make and model of the system affected.
Mike

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 08:05:25 GMT

sorry for the late response

# Prohibit general access to this service.
#restrict default ignore

# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1

# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

# --- OUR TIMESERVERS -----
# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery
# server mytrustedtimeserverip

# --- NTP MULTICASTCLIENT ---
#multicastclient # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10

#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

#
# Authentication delay. If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate yes

#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
#logfile /var/log/platform/ntp.log
keys /etc/ntp/keys
trustedkey 1
requestkey 1
server ntpd1 iburst #1'st NTP server
[root@trm8

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 08:50:31 GMT

if its help
ntpq> rv
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.1.2@1.892 Tue Feb 24 06:32:25 EST 2004 (1)",
processor="i686", system="Linux2.4.21-32.0.1.ELsmp", leap=00, stratum=5,
precision=-18, rootdelay=6.998, rootdispersion=136.435, peer=51206,
refid=ntp_1, reftime=ccbbda94.68fcf80d Wed, Nov 5 2008 9:40:52.410,
poll=10, clock=ccbbdc79.4282b628 Wed, Nov 5 2008 9:48:57.259,
state=4, offset=-5.614, frequency=132.005, jitter=56.243,
stability=0.117
ntpq>

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Wed, 05 Nov 2008 09:24:05 GMT

Zauer
your local clock is having a fight with the ntp server !
Since you have not provided the rest of the information about the kernel , and release. I will assume you are up to date,
i.e. NTP v 4.2.2 and that you are not serving time to anyone else from here.

STOP ntpd on the system with "synchronisation lost" .

edit ntp.conf

delete these two lines they are not required in v4, in v3 removing also seems to help with this kind of problem if you are not serving time elesewhere.

server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10

If you are on NTP 4.1 or above
add this line instead

tos orphan 8

Or use a stratum one more than
your usual numericaly highest level

move the line

server ntpd1 iburst #1'st NTP server

to the section
# --- OUR TIMESERVERS -----
to make the file easier to read

save the file

edit /var/lib/ntp/drift

and replace the number you find with 0
my guess is you have a large number in here
probably 512 .

with NTP still down set the system clock

ntpdate ntpd1

set the biosclock

hwclock --systohc

At this point it is a good idea to re boot if you are able.

start ntpd and check the behaviour.

Once the system is in synch with the server
using ntpq -p you will see * on one of the sever lines linux will enter what it calls 11 minute mode and it should keep the bios clock up to date for you .
(Some hardware is so poor it never keeps up the solution is to replace the mother board , or occasionaly the bios battery)
the ntp documentation is here

www.eecis.udel.edu/~mills/ntp/html/index.html
I hope this helps
Mike

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 09:33:34 GMT

is it ok ?

[root@c1 root]# ntpdc -c ver
ntpdc 4.1.2@1.892 Tue Feb 24 06:32:29 EST 2004 (1)
[root@c1 root]# ntpdc -c kerninfo
pll offset: -0.00248 s
pll frequency: 131.994 ppm
maximum error: 0.647951 s
estimated error: 0.042291 s
status: 0001 pll
pll time constant: 6
precision: 1e-06 s
frequency tolerance: 512 ppm
pps frequency: 0.000 ppm
pps stability: 512.000 ppm
pps jitter: 0.0002 s
calibration interval: 4 s
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0
[root@trm81 root]# ntpq -p

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 09:33:40 GMT

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 09:35:30 GMT

as you can see my ver is 4.1.2

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Wed, 05 Nov 2008 09:39:42 GMT

Zauer ,
Sorry your second post crossed over while I was constructing my reply and I did not see it until it was finished ,
orphan mode should work on 4.1.2
the drift file value 132.005 is not too bad but I would be inclined to clear it anyway .

mike

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 09:47:39 GMT

so basicly if i'll delete the /var/lib/ntp/drift adn restart the ntpd
the ntpd should create the drift file again ?
thanks

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Wed, 05 Nov 2008 11:47:27 GMT

Zauer,
It will not fix the problem on its own!
If you remove the drift file and NTP will recreate it for you with new values , but to fix the problem you need to do all the other things as well.

The problem, I think, is that your system is flip flopping between being in synch with itself and in synch with the NTP server.
You can see this by monitoring the ntpq -p output which will vary from being in synch with LOCAL to in synch with ntpd1. One of the side effects of this is an incorrect frequency drift value another is the messages you have seen.
The orphan mode in NTP V4 provides a cure for this but the lines
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
have to come out of the ntp.conf file and be replaced with

tos orphan 7

(7 is two more than 5 from your rv output )

The setting of the system clock with ntpdate, followed by the setting of the hardware clock, and emptying the drift file give NTP a clean starting point to work from.

Mike

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 12:59:27 GMT

so the changes need to be made are:
fudge 127.127.1.0 stratum 10
tos orphan 7

please tell me if im correct:
the orphan designed to replace the local clock driver if the local clock failed.

the fudge is the priority of the redundancy
if so what is fudge 10 for local clock ?
thanks

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

zauer — Wed, 05 Nov 2008 13:08:16 GMT

sorry i meant
is this the new configuration suppose to be like:

#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10
tos orphan 7

Re: NTP .increase the 128ms treshold to avoid "synchronisation lost" alarm

BUPA IS — Wed, 05 Nov 2008 15:23:42 GMT

Zauer ,
Your last post is correct but I would just delete the lines.
Please try all of the updates and suggetions in my 9.24 post and let me know how you get on .

to answer the other two questions.

orphan mode in fact replaces the need to use the local clock driver when you become disconnected from all other reliable time sources.

The fudge command sets the stratum layer for your local clock to 10. Briefly this means that your local time is now considered by NTP be less reliable than time from other sources.