Есть сервер под debian 6 , На нем установлены ntp и ntpdate
ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for helpdriftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntpstats/ntp.log# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/#statistics loopstats peerstats clockstats
#filegen loopstats file loopstats type day enable
#filegen peerstats file peerstats type day enable
#filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.# By default, exchange time with everybody, but don't allow configuration.
#Задаем разрешения для протоколов ip4 и ip6 по умолчанию запрещаем менять что либо
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery# Local users may interrogate the ntp server more closely.
#разрешаем подключение к серверу с самого себя
restrict 127.0.0.1
restrict ::1# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#Разрешаем компам из сети получать время с сервера , но запрещаем модификацию времени на серваке и трапы
restrict 192.168.4.0 mask 255.255.255.0 nomodify notrap nopeer# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclientПроверяю работу своего сервера времени
вчера вечером было
==============================================================================
+tbgw.templebar. 62.117.76.142 2 u 295 512 377 703.175 -109.83 95.289
+218-32-169-193. 129.70.132.32 3 u 189 512 377 727.195 -165.69 161.808
+cello.corbina.n 193.79.237.14 2 u 388 512 373 795.139 -135.46 185.549
*dl120g7.naviteh 194.190.168.1 2 u 1206 512 254 335.362 -40.171 102.496
root@debtest:/var/log/ntpstats# ntpdate -q localhost
седня вечером
root@deb test:/etc# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tbgw.templebar. 62.117.76.141 2 u 462 1024 3 758.989 -92.028 139.292
+218-32-169-193. 194.149.67.129 3 u 469 1024 3 803.174 -90.314 202.449
+cello.corbina.n 193.79.237.14 2 u 335 1024 17 346.852 -199.71 140.231
+dl120g7.naviteh 194.190.168.1 2 u 1397 1024 16 871.240 -24.678 202.939
нормален ли такой offset , насколько я понял он должен быть приближен к 0. И еще один вопрос подходят ли стандартные pool из дефолтного конфига или нужно брать свои ?
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
>[оверквотинг удален]
>
пока Ваш сервер время от стронних нормально подхватывает, можете на offset забить.
не устраивают default сервера? выбирайте - www.ntppool.org. методы их тестирования (в том числе и про offset на данном сайте есть).
PS
Конфиг не смотрел, но ntpq -p все нормально у Вас ИМХО. Беспокоится не о чем.
> нормален ли такой offset , насколько я понял он должен быть приближен
> к 0.Какие-то у вас заоблачные значения и в offset и в jitter.
У меня:
debian:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+95.140.94.2 62.76.96.4 3 u 773 1024 377 70.954 4.097 1.770
*1.2.3.4 131.188.3.221 2 u 382 1024 377 0.400 -1.028 1.214
3.4.5.6 .STEP. 16 u - 1024 0 0.000 0.000 0.000
gatecluster-1.n .STEP. 16 u - 1024 0 0.000 0.000 0.000
>И еще один вопрос подходят ли стандартные pool из дефолтного конфига или нужно брать свои ?Подходят, но можно взять и свои.
Вот это меня и настораживает в чем может быть причина ?
> Вот это меня и настораживает в чем может быть причина ?1) Остановить ntp, выставить время на сервере через ntpdate "скачком" а не "плавно". Хотя наверное у вас уже выставилось плавно :-)
2) Что с каналом? Что за канал, какие пинги и т п.
>> Вот это меня и настораживает в чем может быть причина ?
> 1) Остановить ntp, выставить время на сервере через ntpdate "скачком" а не
> "плавно". Хотя наверное у вас уже выставилось плавно :-)
> 2) Что с каналом? Что за канал, какие пинги и т п.делал ntpdate pool.ntp.org
канал - 3g модемPING pool.ntp.org (62.76.96.4) 56(84) bytes of data.
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=1 ttl=245 time=222 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=2 ttl=245 time=206 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=3 ttl=245 time=209 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=4 ttl=245 time=211 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=5 ttl=245 time=218 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=6 ttl=245 time=197 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=7 ttl=245 time=200 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=8 ttl=245 time=206 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=9 ttl=245 time=193 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=10 ttl=245 time=196 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=11 ttl=245 time=232 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=12 ttl=245 time=234 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=13 ttl=245 time=237 ms
64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=14 ttl=245 time=219 ms
>[оверквотинг удален]
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=5 ttl=245 time=218 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=6 ttl=245 time=197 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=7 ttl=245 time=200 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=8 ttl=245 time=206 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=9 ttl=245 time=193 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=10 ttl=245 time=196 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=11 ttl=245 time=232 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=12 ttl=245 time=234 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=13 ttl=245 time=237 ms
> 64 bytes from ns.davydkovo.net (62.76.96.4): icmp_req=14 ttl=245 time=219 msбольшая задержка delay и не все пакеты принимаются для синхронизации судя по reach , возможно из-за задержки
> Вот это меня и настораживает в чем может быть причина ?пакет временных зон обновлен?
материнка старая?
>> Вот это меня и настораживает в чем может быть причина ?
> пакет временных зон обновлен?
> материнка старая?проблема была в медленном соединениии