Прошарок джерела мережі NTP

Чи можна налаштувати ntpdвирівнювання рівня шару мережевого джерела?

З першого погляду я подумав, що fudgeдиректива може це досягти, проте, переглянувши ntp.conf(5)довідкові сторінки, я виявив, що ця директива застосовується лише до довідкових годин.

Кілька деталей:

У мене локальний сервер працює ntpdяк основне джерело часу для клієнтів у локальній мережі. Цей сервер вказується на пул ntp.org і зазвичай підтримує рівень 3-го шару.

Окрім свого основного сервера, у мене є мережевий пристрій сторонніх виробників, основним завданням якого є бездротова синхронізація настінних годин. Радіопередача. У специфікації пристрою говориться, що це "Сервер часу, сумісний із RFC2030", але в іншому випадку це майже чорна скринька. Я налаштував пристрій використовувати основний сервер, оскільки це лише джерело часу:

конфігурація чорного поля http://www.freeimagehosting.net/uploads/21bafb12bd.png

Моя проблема виникла, коли я налаштував ntpdна своєму персональному комп’ютері використовувати як основний сервер NTP, так і бездротовий передавач як джерело часу. Запитуючи мій локальний ntpd, я помітив, що "чорна скринька" (10.xxZ) є сприятливим джерелом часу:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x10.x.x.X        69.164.222.108   3 u   48   64  177    0.501  370.029   1.530
*10.x.x.Z        10.x.x.Z         2 u   50   64  377    1.354  -23.681  14.179

Оскільки 10.x.x.Zєдиним джерелом часу для сервера є сервер 10.x.x.X(який є прошарок 3), він повинен бути шаром 4. Я вважаю, що виробник жорстко закодував рівень свого шару.

Чи є якийсь спосіб змусити мою машину віддати перевагу серверу "хороший" (10.xxX), незважаючи на високий рівень страт Я також спробував preferдирективу у моєму локальному ntp.confфайлі, але безрезультатно, чорне поле завжди перемагає: /

Для чого це варто, моя локальна машина працює під управлінням Mac OS X 10.6.

$ ntpq -c rv | grep version
version="ntpd 4.2.4p4@1.1520-o Mon May 18 19:38:25 UTC 2009 (1)",

Після ще кількох досліджень здається, що "розтушовувати" рівень шару мережевого джерела неможливо. Тож я перейшов і спробував відповісти дюбелі . На мій подив, просто перетворення мого локального сервера часу на рівень 2-го шару (рівний сторонньому пристрою) не завжди спричиняло, що він є кращим джерелом часу. Мій місцевий ntpd все ще керував би ними як "помилковими кліщами". З якої причини я не впевнений, але я здогадуюсь, тому що вони були єдиними двома джерелами часу, а їхні часи були настільки далекими.

Найбільшою проблемою тут є той факт, що мій сторонній пристрій, здається, не дуже довго працює, адже він дуже коливається. Вирішенням моєї проблеми було додавання до моїх кількох інших точних джерел часу (pool.ntp.org) /etc/ntp.conf. Тепер мій локальний сервер завжди вибирається в якості бажаного джерела часу, часто, незважаючи на те, що рівень страту більш високий, ніж деякі сервери в пулі.

Ви можете спробувати запустити свій локальний ntpd у stratum 2. Замість того, щоб вказувати його на pool.ntp.org, просто створіть список 5-7 серверів stratum 1 та додайте їх до конфігурації безпосередньо. З довідковим сервером у шарі 1 ваш працюватиме на шарі 2. Тоді ваш preferваріант може працювати.

Однак, з мого досвіду, рівень прошарку не завжди є виграшним фактором у виборах первинного джерела. Я думаю, що затримка та тремтіння також мають значний вплив. Я неодноразово помічав, що сервер нижньої страти був обраний в якості основного джерела, хоча існувало кілька серверів вищого шару лише через те, що він мав найменшу затримку. Тому я не можу гарантувати, що запропонований підхід спрацює.

У мене в локальній мережі є апаратне джерело часу GPS (10) ", яке надає мені фальшивий статус (x) в ntpq, я виявив, що використання server [x.x.x.x] true(x = IP-адреси) в ntp.conf обійде фальшиву перевірку, що дозволяє йому бути можливим кандидатом. Виглядає, що число шару не завжди означає більший пріоритет.

Якщо вам не подобається цей сервер 10.xxZ в якості посилання, це слід зробити:

server 10.x.x.Z noselect 

Це корисно, якщо сервер слід використовувати лише з моніторингових причин. Ви також можете налаштувати:

server 10.x.x.X prefer

Тому 10.xxZ не буде використовуватися, якщо доступний 10.xxX.

Однією з причин, чому його віддають перевагу, є те, що останнім часом ваш сервер іншого часу був недоступний. Бачите стовпець охоплення?