Operating System - Linux
1752583 Members
5018 Online
108788 Solutions
New Discussion юеВ

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

 
zauer
Advisor

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

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
16 REPLIES 16
Johnson Punniyalingam
Honored Contributor

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

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
Problems are common to all, but attitude makes the difference
BUPA IS
Respected Contributor

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

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
Help is out there always!!!!!
zauer
Advisor

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

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
BUPA IS
Respected Contributor

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

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
Help is out there always!!!!!
zauer
Advisor

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

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
zauer
Advisor

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

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>

BUPA IS
Respected Contributor

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

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






Help is out there always!!!!!
zauer
Advisor

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

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
zauer
Advisor

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

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