Re: lug-bg: time update
- Subject: Re: lug-bg: time update
- From: Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>
- Date: Fri, 05 Mar 2004 14:52:41 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nikkk wrote:
| Zdraveite .....
|
| koi ot dvata nachina shte mi preporachate za sveriavane na
| chasovnika. i ima li niakakva sashtestvena razlika mezdu dvata.....
|
| rdate -p -s 129.6.15.28 ntpdate -u -s 129.6.15.28
|
| Ako eventualno tozi server ne otgovori kak bih mogal da popitam drug.
| Zasega polzvam tozi skript.
|
| #!/bin/sh
|
| #set the system date to the time server rdate -p -s 129.6.15.28
|
| #set the CMOS/hardware clock hwclock --systohc
Ами можеш да използваш и rdate и ntpdate. Съществена разлика няма. И
двата инструмента използват RFC 868. rdate е създаден от RedHat, а
ntpdate е създаден по проекта NTP (сървър плюс клиент) в University of
Delaware.
Имай предвид следното (странно защо почти никъде не го пише по
ръководствата за потребители), което ще изложа по-долу.
Всъщност бях подтикнат да напиша това писмо визирайки адрса на сървър за
време, който използваш по-горе. Ти очевидно използваш интернет
свързаност през български доставчик на интернет услуги, а сървърът, по
който ще се синхронизираш се намира в САЩ (оператор е Националният
институт по стандарти и технологии) и работи с атомен часовник
(http://www.boulder.nist.gov/timefreq/cesium/fountain.htm).
Когато използваш сървър за време ти можеш да извършваш синхронизацията
по два начина:
- - чрез клиентска програма (rdate, ntpdate), която перидично извършва
сверяване на часа по един единствен сървър за време (тя се стартира
периодично от cron);
- - чрез сървърска програма (ntpd), която използва алгоритъм за натрупване
на образци от времето подавано от сървъра, който тя запитва,
преизчисляване на закъснението натрупано при предаване на пакетите и
отчитането му в последващото подавано на системата време.
Имай предвид, че клиентските програми като rdate и ntpdate не могат да
осигурят точност под 0.5 секунди. Истината е, че ако ти от българското
интернет пространство се синхронизираш по сървър за време в САЩ,
грешката в полученото от теб време спокойно може да достигне и 1 (че и
повече) секунди. Клиентската програма може да бъде използвана само, ако
тя се свързва със сървър, който е в твоята локална мрежа и пакетите
от/до който имат минимално закъснение.
Сървърската програма използва специален алгоритъм (ако има интерес мога
да го обясня), чрез който се отчита по-точно дисперсията в набора
образци от време, които са взети от сървъра. Това разбира се отнема
време (мин. 1024 секунди). Пред това време сървърската програма събира
образци от един или повече сървъри за време и избира този, за който има
най-малка дисперсия в подаваните от него образци. Сървърската програма
през цялото си време на действие събира образци и преизчислява
дисперсията и избира сървъра с най-малка дисперсия.
Лично аз ти препоръчвам следното. Ако нямаш локален сървър за време
пусни на машината си ntpd и използвай поне 3 различни по географско
разположение и съответно интернет свързаност сървъри за време.
Има и ещо друго и това друго е сигурността и недеждността на полученото
време. Имай предвид, че NTP протокола в общата си част е податлив на
измама. Това значи, че някой може да разиграе IP измама и да се
представи вместо сървъра за време и да си поиграе със системното ти
време. За да се предотврати измамата се ползват криптографски
технологии базирани на MD5 споделени пароли или на криптографията с
публичен ключ. За жалост ти няма как да вярваш на ключовете на сървърите
за време, ако нямаш удостоверител. Т.е. за да използваш криптографските
схеми за удостоверяване ти трябва някой, на когото ти да вярваш и той да
ти каже "да, това е ключа на този сървър за време". Всяко подавано от
сървъра за време измерване се изпраща до клиентите с прилежащия към него
електронен подпис.
Друг аспект, който засяга сървърската част. Сървърите за време имат
йерархия. Всяко ниво в нея се нарича stratum. Сървърите за време, който
йерархично са stratum 1 взимат времето от някакъв физически процес
(например споменатото в поместената по-горе хипервръзка радиоктивно
разпадане на изотоп на цезий). При това има два вида физически процеси
за отчитане на точно време - реалитивистични и нерелативистични. При
релативистичните процеси трябва да се очтита движението на източника
спрямо наблюдателя и да се въвежда релативистична поправка. Такива са
например GPS базираните часовници. Няма как само по един сателит да
получиш точно време:) Нерелативистичните процеси са по-удобни за
отчитане на точното време, но са по-сложни като апаратура за измерване
на интервалите м/у процесите използвани за дефиниране на валичината
"секунда". Радиоктивният разпад е нерелативистичен процес (това е
доказано чрез т.нар. "ефект на Мьосбауер"). При него никога не е
наблюдаван "парадоксът на близнаците", който е характерен за
релативистичните процеси.
Когато избираш сървъри, по които да се сверяваш, трябва да следиш те да
са възможно най-високо в stratum йерархията. Слизайки на по-долни нива,
ти вече започваш да ставаш твърде зависим от погрешността натрупвана от
мрежови закъснения (имай предвид, че алгоритъмът за корекция на
закъснението по мрежата е екстраполационен и ти никога не знаеш
абсолютната грешка на измерването и не можеш да оцениш дори нейното
натрупване при преминаване от един стратум към друг). Все пак можеш да
използваш по-долно ниво на йерархията, яко знаеш предварително, че то е
свързано с много бърза връзка към по-горно такова. Ето ти един пример.
Ти имаш бърза връзка до stratum 3. Знаеш, че това ниво в йерархията е
свързано със stratum 2, а той от своя страна е свързан със stratum 1 пак
чрез бърза връзка. Е, та ако до stratum 1 имаш много по-бавна връзка, в
сравнение с тази до stratum 3, няма да има проблеми да използваш stratum
3 като източник за точно време, т.е. в повечето случай хипотезата, че
имаш по-малко закъснение при отчитане на реалното време по stratum 3 е
по-сбъдваема от противоположната. Ако ти се занимава сравни например
средните от две съвкупности от дисперсии (едните от strtum 1, другите от
stratum 3) чрез t-критерия на Student и съм почти сигурен, че при
вероятност 0.95 те няма да принадлежат към едно и също разпределение.
Ако все пак излезе, че са от едно и също разпределение, това значи, че
просто имаш малко данни:)
М/у другото имах идеята да изградим сървър за време... целият проблем е,
че нямаше кой да спонсорира закупуването на GPS приемника и хардуера за
вкарването на сигнала в компютъра. Ако след време успея да намеря пари,
няма да има проблеми да се пусне такова чудо, при това с ключове и
всичките му там екстри и с удостоверяване на място:) срещу едно Столично
тъмно.
~ Поздрави
~ Весо
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFASHgY+48lZPXaa+MRAhi/AJ4vBAal4AO+iismWm8RsW54Jzep2ACgvArM
olYDqVRbxQCg0JoAFeNFHys=
=4C1h
-----END PGP SIGNATURE-----
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|