Беларусь (Любители астрономии из Беларуси, давайте объединяться!)

[Selestia]

  По поводу клуба: постоянный состав более или менее определен. Место встречи - я так понимаю, вокзал не пойдет, а так часто собирались у нас, по крайней мере, трое-четверо из основного состава, многие дорогу уже выучили.
Во-вторых, Вы же не забывайте про Брюханова. Хотите 50% скидку без проблем, попросите у него разрешения представить его "заочный астрокружок для взрослых" И дергаться не нужно, и членами его вы являетесь, и программу определять не нужно (хотя она у нас уже определена с большего), и статус довольно официальный.

Ребят, а что Вы строите нынче, что паяете?  Мое предположение - все и сразу! А на деле - ничего. Уточните порядок.

[Kostyan]

  Место встречи - я так понимаю, вокзал не пойдет

Чаму ?? Кафе такое - то чем плохо и кто из россиян будет знать что это на вокзале ?

Во-вторых, Вы же не забывайте про Брюханова. Хотите 50% скидку без проблем

Низачто !!  Мы независимы. Да и начинаю всю эту заварушку вопрос о скидке занимал в моем понятие далеко не первостепенную важность (будем клубом поедем в след году со скидкой).

Давай те только по активнее голосовать , не началльника же себе выбираем !


2 Deimos
Шустрый однако кодер.

[1212Lupus]

Давай те только по активнее голосовать , не началльника же себе выбираем !

Костя, угомонись! 
Если меня не посадили на прошлые президентские выборы, то это ещё не значит, что на этих выборах ГАЛа (Главного-ЛА) я тебе по черепушке не настучу! 

Теперь о приятном: ну-ка все вместе спели хвалебную песню Deimos'у! Ну, и мне парочку ноток -- надо же примазаться.  А то пока народ не попинаешь -- толку не будет. В общем, прога работает -- только что проверил осциллографом. Так что "Ура".

Первые результаты: измерил крутизну переднего фронта синхроимпульса. Он порадовал -- 0,04 мс. Ниже приведена картинка со осциллографа на базе ПК. Проверял и "классическим" осциллографом -- результат тот-же.

Тут же и первые замечания по проге:
1). При активации кнопки синхронизации загрузка процессора подскакивает ло 100% -- даже на моём Ahlon 3500+, не говоря уж о страричке-селероне... Это не есть гуд. Хотя я проследил за тем, как синхронизируютсячасы по D4 -- при активации проги разброс не превышал 0,01 с при конекте с сервером точного времени каждые 10 с...
2). Если несколько раз подряд нажать кнопку синхронизации, то после надписи LPT Syncronizer появляются точки. Они что-то значат, или это божественное откровение?
3). Так получается, что нам надо получить задержку не хуже, чем 10-15 мс. Иначе это не дело -- читайте нашу сегодняшнюю беседу с Алексеем Лосюком в ветке про наблюдения покрытий звёзд астероидами...
После этой беседы весь энтузиазм испарился.  Он тут не виноват, конечно -- наоборот, он, как специалист в этом деле, правильно всё растолковал. Но всё равно обидно...

Ребят, а что Вы строите нынче, что паяете?    Мое предположение - все и сразу! А на деле - ничего. Уточните порядок.

Сегодня вечером я "летал". А сейчас я понял, что КПД того, что мы пока реализовали по синхронизации с трудом на 10% вытягивает... Так что, Таня, ты права -- NIHIL!!!

[Pelican]

Вопрос можно?
Что за таймер и зачем программа для его эмуляции?
А также, если можно, точную ссылку

Иначе это не дело -- читайте нашу сегодняшнюю беседу с Алексеем Лосюком в ветке про наблюдения покрытий звёзд астероидами...

[xd]

Тут же и первые замечания по проге:
1). При активации кнопки синхронизации загрузка процессора подскакивает ло 100% -- даже на моём Ahlon 3500+, не говоря уж о страричке-селероне... Это не есть гуд. Хотя я проследил за тем, как синхронизируютсячасы по D4 -- при активации проги разброс не превышал 0,01 с при конекте с сервером точного времени каждые 10 с...
2). Если несколько раз подряд нажать кнопку синхронизации, то после надписи LPT Syncronizer появляются точки. Они что-то значат, или это божественное откровение?
3). Так получается, что нам надо получить задержку не хуже, чем 10-15 мс. Иначе это не дело -- читайте нашу сегодняшнюю беседу с Алексеем Лосюком в ветке про наблюдения покрытий звёзд астероидами...

И первые ответы. По порядку:
1. Всё нормально. Просто рабочий поток занимает всё свободное время процессора. Дело в том, что в винде нет событий изменения времени в том виде, как нам надо. Поэтому приходится ждать его явно. Загрузка 100% нисколько не ущемляет другие процессы (ну если только совсем-совсем чуточку  )
2. Это откровение, которое я забыл убрать . В общем это означате, что один рабочий поток уже работает и второй запущен не будет.
3. Такая максимальная задержка и получается примерно. В принципе, можно определить среднюю и работать на небольшое опережение, но тута требуется помозговать. Или выставить повыше разрешение таймера. Чем я сегодня попробую заняться.

Вопрос можно?
Что за таймер и зачем программа для его эмуляции?

Не программа-таймер. А программа для синхронного запуска рабочих секундомеров. И вдобавок синхронно с началом минуты на компутере при внешней синхронизации через инет.

А также, если можно, точную ссылку

Иначе это не дело -- читайте нашу сегодняшнюю беседу с Алексеем Лосюком в ветке про наблюдения покрытий звёзд астероидами...

https://astronomy.ru/forum/index.php/topic,10965.msg452374.html#msg452374


PS. На работе будучи полдня хотел написать ответ, да никак не доходили руки. И в ветке молчали.  А теперь пока набивал ответ, появился очередной пост 

[1212Lupus]

Алексей лосюк вбил последний гвоздь в гроб нашего мероприятия по запуску секундомера из интернета  :

Цитата: 1212Lupus от сегодня в 01:23:55
Я думал использовать программу Dimension 4 -- которая синхронизирует часы ПК по серверу точного времени... Мы сравнивали её показания с показаниями приёмника, выдающего из динамика РВМ -- задержки не заметили... Что вы думаете насчёт серверов точного времени?

Я-то ничего не думаю.  Потому что никогда этот способ синхронизации не исследовал.

Однако если Вы просматривали рассылку Дениса Денисенко "pokrytie" или достаточно давно следите за данной веткой форума, то, конечно, знаете, что есть такая Европейская ассоциация наблюдателей покрытий EAON. И что она выпускает для наблюдателей циркуляры (http://www.astrosurf.com/eaon/Circulaire.htm). И что Денис 14 июня 2003 г. опубликовал перевод циркуляра #5 "Тайминг визуальных наблюдений" Раймонда Дюссера. А также что в данном переводе есть фраза (цитирую):

"Внутренние таймеры компьютеров изначально не предназначены для достижения точности хороших наручных часов. Существуют методы для точной синхронизации часов через Интернет. Тесты, проведенные на Парижской обсерватории, выявили возможную погрешность до 1 секунды".

От себя добавлю: ...и поэтому данный способ синхронизации часов давно отвергнут сообществом наблюдателей покрытий как абсолютно непригодный для наших целей.

Мда... Гвоздик этот -- это тебе не "семётка", это "двухсотка"... Его так просто не выдернешь... 
Ладно. Мы упёртые. План дальнейших мероприятий я вижу таким:
1). Продолжаем дальше совершенствовать программу LPT Synhronize. Чтобы получать задержку не хуже 5 -10 мс.
2). Проводим исследования задержек и т.д. Для этого мне необходимо, чтобы код проги мог компилиться под M$ Visual C++, или чтобы ты, Лёха, дал мне диск с Borland'овским компиллятором. Если смогу перекомпиливать прогу -- то исследование задержек займёт не более одного вечера.
3). В связи с тем, что использовать серверы точного времени не представляется возможным (блин, я сам проведу измерения, и если Парижская осерватория неправа (мало ли к каким серверам в Уганде они коннектились!), то  я её с землёй сровняю!  ), то придётся синхронизировать часы компа от РВМ. Готовая прога для этого есть -- Radio Clock. К сожалению, линк, который предоставил Алексей Лосюк на программу -- "битый", но в своё время Pova откудо-то скачал её... К ней есть хэлп. Но тут есть неприятность -- походу, для этой проги нужен SSB/CW -- приёмник. У нас же есть FM/AM-приёмник. Так что, если не удастся заюзать готовую прогу, придётся писать самим. Над алгоритмом будем думать вместе -- и физики/химики, и программисты. 
Пока я мыслю так. Покритикуйте, плиз.

P.S. "Вихри враждебные веют над нами,
         Тёмные силы нас злобно гнетут..." (с) "Варшавянка".
 НО!
          "Врагу не здаётся наш гордый Варяг,
           Пощады никто не желает!" (с)
И вообще -- настоящие герои всегда идут в обход! А разве мы не настоящие? 

[xd]

Диск с компилятором в обмен на книгу по дровам!

[1212Lupus]

Диск с компилятором в обмен на книгу по дровам!

Да хоть два ящика КЦ! Только книгу сам заберёшь! 

[Pelican]

SSB приемник - это АМ - со однополосной модуляцией, если знать диапазон и способ кодирования сигнала точного времени (вроде 6 точек до конца часа, но импульсы как подаются звуковым бипом или меандром - вот вопрос?), то это не становиться проблемой. Насколько из литературы я понял - проблема  сделать фотометрические наблюдения с точной привязкой по времени, через небольшой интервал, то есть ФЭУ - в режиме счета фотонов, счетчик и таймер - это отдельный девайс получается, да еще с радиоприемником в придачу , даже фотодиода лавинного не нужно - есть же ФЭУ . Иначе в программировании можно увязнуть всерьез и на долго, а схему фотометрирования и кучу секундомеров в придачу и все может быть без особого толку, поскольку упрется в человеческий фактор

[xd]

SSB приемник - это АМ - со однополосной модуляцией, если знать диапазон и способ кодирования сигнала точного времени (вроде 6 точек до конца часа, но импульсы как подаются звуковым бипом или меандром - вот вопрос?), то это не становиться проблемой. Насколько из литературы я понял - проблема  сделать фотометрические наблюдения с точной привязкой по времени, через небольшой интервал, то есть ФЭУ - в режиме счета фотонов, счетчик и таймер - это отдельный девайс получается, да еще с радиоприемником в придачу , даже фотодиода лавинного не нужно - есть же ФЭУ . Иначе в программировании можно увязнуть всерьез и на долго, а схему фотометрирования и кучу секундомеров в придачу и все может быть без особого толку, поскольку упрется в человеческий фактор

Сигналы РВМ представляют собой амилитудно-манипулированную несущую. Поэтому принимая его, мы отстраиваем приёмник на некоторую частоту. Соответвенно, эта отстройка и будет задавать тон сигнала. Для приёмника сигнал будет восприниматься как односторонне амплитудно-манипулирумый с подавленной несущей.
Сам же звуковой сигнал будет (если не считать нелинейность тракта) тональным, то есть содержащим одну частоту.

[xd]

http://belastro.net/files/sync12.zip
Ревизия 1.2 проги. Пищит каждую секунду и каждую минуту. На LPT отправляется импульс длительностью 60мс на границе секунды и 120мс на границе минуты. Также для удобства идёт озвучка. Каждые 10 секунд звуковой сигнал двойной.

[1212Lupus]

В общем так, братья-команчи (к сёстрам тоже относится  )!
Объявляется компания борьбы протиф Парижской обсерватории!
Постараемся доказать, что в 2007 г. работа с серверами точного времени гораздо надёжнее. чем в 2002 г.
Только тут есть одна проблема: мировая общественность, не без посыла со стороны этов @#%$@% обсерватории, увериласть, что серверы точного времени -- ненадёжные. Ну, это как история с тем, что Земля плоская. Один умный сказал -- я измерил, и она плоская. И все поверили.
Времена идут, человечество развивается, а сервера так и будут считать "ненадёжными", хоть по их времени будут КА к Антаресу запускать... Ибо это консерватизм взглядов. 
Во мне тоже живёт Дон Кихот, и я готов бороться с ветряными мельницами... Но... Если мы хотим, чтобы наши наблюдения принимались IOTA и проч., то придётся играть по их правилам игры. 
Надо думать над проблемой. Мои соображения -- в ветке про покрытия.

[Kostyan]

                       Выборы
предварительныя точка отсчета...

Итак товарищи. За два дня голосавания выявлены следующий кондидаты на председателя :

- Selestia  (2)
- Deimos   (1)
- 1212Lupus (1)
- Pova     (1)

Как видно особого перевеса ни у кого нет , но зато мы имеем аж 4-рых кандидатов.

Гости нашей ветки , вы также не стесняйтесь , помогайте нам определится, голосуйте (единственно обязательно указывайте в личку от куда Вы знаете наших кандидатов).

Огромная просьба (особенно к активным участникам форума) сделать свой выбор -- наверно сами знаете о ком я говорю 

[1212Lupus]

- 1212Lupus (1)

Костя! Я те точно по голове настучу! 
Если не понял сразу, то заявляю прямо -- сними мою кандидатуру! Немедля. Я против того, чтобы за меня голосовали.
...Интересно, кто этот наивный, кто за меня проголосовал? Я ж только республику ШКИД возглавить могу. Я шут, а не король -- вы перепутали, ребята! 

Я сегодня написал пару писем в Службу Времени РФ и Казахстана насчёт серверов точного времени -- авось ответят...

Теперь в продолжении темы времени... На странице http://citkit.ru/articles/154/ приведена статья, кусок из которой я привожу:

6 сентября 2005 г

...К счастью вопрос точного времени озаботил задолго до меня профессора Делаверского университета (University of Delaware) Дэвида Миллза (David Mills), который подарил миру реализацию сетевого протокола синхронизации времени (Network Time Protocol). На данный момент основной является четвертая версия (NTP v4) этого протокола.
Использование NTP позволяет обеспечить синхронизацию ваших часов с эталонными с точностью в несколько миллисекунд (существуют и наносекундные реализации, однако их использование обычно сопряжено с модификацией ядра операционной системы).
Публичных серверов точного времени в Интернете очень много. Большое количество адресов заслуживающих доверия, вместе с правилами их использования, опубликовано по адресу http://www.eecis.udel.edu/~mills/ntp/. Эти списки постоянно дополняются и обновляются.
При выборе сервера для синхронизации, следует учесть время затрачиваемое на прохождение пакетов от сервера до вашей машины воспользовавшись утилитой ping. В общем случае чем меньше это время, тем выше будет точность синхронизации часов.

Вообще-то, использование Network Time Protocol (NTP) часто характерно для *nix'овских ОС. В частности, в упомянутой статье рассказывается, как настроить такую синхронизацию. Хотя, естественно, ничто не мешает его использовать и на Windows. Но самым важным тут является именно предостережение насчёт времени прохождения пакетов по сети. Мы стремились всегода подключаться к ближайшему и "продвинотому" серверу. Для надёжности надо будет измерить время прихода пакетов с него...

http://www.citforum.ru/hardware/articles/ntp_dtss/ :

2005 г.
Исходя из соображений цены и удобства применения, нет никакого смысла использовать приемники сигналов точного времени с каждым конечным клиентским компьютером (да и вообще с любым устройством, отображающим текущее время). Тем не менее есть прямая необходимость задействовать некоторое количество компьютеров в качестве первичных серверов времени, установив на них оборудование, принимающее сигналы точного времени, и программное обеспечение, обслуживающее эту специфическую аппаратуру. Первичные серверы времени выступают в качестве носителей эталонного времени для намного большего числа серверов второго уровня, относительно которых в свою очередь корректируют время клиентские устройства.

Основные положения протокола синхронизации NTP:
...По большому счету основная задача протокола синхронизации времени - максимально точно определить разницу между показаниями часов сервера и часов клиента. Различные современные протоколы синхронизации используют разнообразные методы для определения этой разницы, но все они подчинены общей глобальной модели. По запросу сервер высылает сообщение, включающее текущие показания часов, или "отметку времени" (timestamp). Клиент записывает собственную отметку времени в момент прибытия сообщения сервера. Для достижения максимальной точности клиенту необходимо измерить задержку распространения ответа "сервер-клиент" и таким образом выяснить полную величину смещения показаний часов относительно часов сервера...

...Поскольку невозможно определить величину задержки распространения в одну сторону, если известна актуальная величина смещения, протокол измеряет общую "транспортную" задержку ("клиент - сервер" плюс "сервер - клиент") и предполагает, что время распространения в одну и другую сторону одинаково. Это разумные рамки условностей, которых, к сожалению, не избежать - в сегодняшней сети Интернет маршруты прохождения данных и, соответственно, ассоциированные с ними временные задержки могут значительно варьироваться по понятным причинам
Каждый последующий уровень сервера (первичный - вторичный - третичный) во всей иерархии носит название "уровень стратума".
В больших сетях необходимо на каждом уровне стратума вводить избыточные серверы синхронизации и запасные сетевые маршруты, для того чтобы свести к минимуму риск программных и аппаратных сбоев, нарушения сетевых связей. Кстати, существуют довольно интересные данные о достоверности времени на серверах самого высокого уровня. Более 30% серверов уровня стратум-1 имеют погрешность более чем 10 секунд, а несколько их экземпляров - даже один год. По имеющимся сведениям, реально доверять можно лишь примерно 28% серверов данного уровня.

А теперь поподробнее о том, как происходит синхронизация:
http://cs.usu.edu.ru/study/ntpsntp/

доклад Скробова А., 2004 г

NTP (Network Time Protocol)

а) NTPv0

Первая версия NTP (позже названная NTPv0) появилась в 1985 г. (RFC958). Идея состояла в «расширении» протокола TIME для передачи дополнительной информации, достаточной для любых мыслимых нужд. NTP-сервера и NTP-клиенты обмениваются однотипными UDP-пакетами следующего формата:

LI (2)
Status (6)
Type ( 8 )
Precision (16)
Error (16.16)
Drift (0.32)
RefId (32)
Reference (32.32)
Originate (32.32)
Receive (32.32)
Transmit (32.32)

Время здесь передаётся в виде 64-битного числа секунд с фиксированной точкой (посередине, т.е. между 31 и 32 битом). Такой формат позволяет передавать время с точностью до 0,2 нс, что должно превосходить реально достижимую точность измерения времени ещё много лет. С другой стороны, как и при использовании 32-битного целого числа секунд, через 136 лет происходит переполнение, и поэтому NTP, как и TIME, применим лишь до 2036 г.

Поля NTP-пакета определены следующим образом:

LI (leap indicator): указывает на необходимость введения високосной секунды в ночь с текущего дня на следующий. Это поле, когда BIPM вводит високосную секунду, задаётся вручную оператором на одном из главных NTP-серверов, и распространяется по всей NTP-сети. 4 возможных значения поля соответствуют отсутствию поправки, добавляемой или вычитаемой секунде, или неисправности сервера (соответствующей сообщению «сервер вообще работает, но сообщаемое время неверно».)

Status: указывает на «самооценку» сервера, и позволяет неисправному NTP-серверу доложить о виде своей неисправности остальным серверам. В более поздних версиях NTP это поле было заменено полями VN и Mode.

Type: указывает на тип часов, показания которых сообщает NTP-сервер. Стандартом было определено несколько стандартных значений, соответствующих атомным часам, радиочасам, наручным часам оператора и т.д. В более поздних версиях NTP это поле было заменено полем Stratum.

Precision: знаковое целое число, указывающее оценочную точность часов сервера как двоичный логарифм. Так, часам IBM PC, обновляемым каждые 55 мс, соответствовало бы значение -4 (т.е. ~16 Гц), а более точным часам, обновляемым 1000 раз в секунду – значение -10. В более поздних версиях NTP это поле было сокращено до 8 бит.

Error: «самооценка» точности показаний сервера как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом), соответствующее максимальной возможной ошибке. В более поздних версиях NTP это поле было заменено полем Root Delay.

Drift: «самооценка» точности часов сервера как число с фиксированной точкой (в начале, т.е. перед 31 битом), соответствующее накапливаемой ошибке в секундах за секунду. Это число знаковое, и отставанию на секунду каждый час соответствует значение -1/3600 ≈ -0.0002778. В более поздних версиях NTP это поле было заменено полем Root Dispersion.

RefId: идентификатор часов, показания которых сообщает NTP-сервер. Если он непосредственно связан с эталонными часами, то это – название данных эталонных часов (до 4 букв в ASCII, дополненных нулями справа до 32 бит), например – «USNO» (военно-морская обсерватория США, US Naval Observatory, http://tycho.usno.navy.mil/), «WWV » (NIST, http://www.boulder.nist.gov/timefreq/stations/wwv.html), «MSF » (NPL, http://www.npl.co.uk/time/msf.html) «PPS » (собственные атомные часы), «GPS » (GPS-приёмник). Если же данный NTP-сервер получает показания времени от другого NTP-сервера, то в этом поле указывается IP-адрес сервера-источника показаний времени. Поскольку поле ограничено 32 битами, то NTP не способен работать с 128-битными IPv6-адресами.

Остальные 4 поля – Reference, Originate, Receive и Transmit – составляют само тело NTP-пакета. В поле Reference сервер указывает показания часов, когда он последний раз их считывал; в поле Originate – копирует содержимое этого поля из запроса; в поле Receive указывает время получения запроса по своим часам; в поле Transmit – время отправки ответа по своим часам. Таким образом, разница Transmit – Receive соответствует времени обработки запроса сервером (и для сильно загруженного сервера может быть большой).

б) NTPv1 – NTPv4

Описанный здесь протокол NTPv0 сейчас считается устаревшим и не применяется. Вместо него применяются более поздние версии: NTPv1 (1988, RFC1059), NTPv2 (1989, RFC1119), NTPv3 (1992, RFC1305), NTPv4 (1996, RFC2030). Все эти версии полностью совместимы между собой; в новых RFC только уточнялись математические процедуры, которые должен выполнять NTP-сервер для фильтрации и объединения показаний других NTP-серверов. Другими словами, NTPv0-сервер не может работать с более новыми серверами, тогда как NTP-сервера версий 1–4 могут работать вместе. Формат NTP-пакета более новых версий несколько отличается от формата NTPv0-пакета:

LI (2)
VN (3)
Mode(3)
Stratum (8 )
Poll (8 )
Precision (8 )
Root Delay (16.16)
Root Dispersion (16.16)
RefId (32)
Reference (32.32)
Originate (32.32)
Receive (32.32)
Transmit (32.32)
Authenticator (до 160)

Новые поля определены следующим образом:

VN: номер версии используемого протокола (от 1 до 4, NTPv0-сервера в этом поле (верхняя часть поля Status) указывают значение 0).

Mode: режим работы отправителя пакета («чистый» сервер, широковещающий сервер, симметричный сервер (т.е. одновременно и клиент), «чистый» клиент и т.д.)

Stratum: уровень «наслоения» показаний времени. NTP-сервер, связанный с эталонными часами напрямую, имеет стратум 1; NTP-сервер, получающий показания только от NTP-серверов первого стратума, имеет стратум 2; NTP-сервер, получающий показания от серверов второго стратума, имеет стратум 3, и т.д. Номера стратумов от 16 до 255 зарезервированы, т.е. показания серверов 15 стратума уже не должны передаваться дальше.

Poll: знаковое целое число, указывающее интервал между сообщениями как двоичный логарифм числа секунд. NTP-клиент указывает здесь интервал, с которым он предполагает опрашивать сервер, а NTP-сервер – интервал, с которым он предполагает чтобы его опрашивали. Допустимыми значениями по RFC2030 являются от 4 (16 сек.) до 14 (4,5 часа).

Root Delay: «самооценка» времени, за которое показания часов доходят до NTP-сервера, как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом).

Root Dispersion: «самооценка» разброса показаний часов NTP-сервера как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом).

Для NTP зарезервирован 123-й UDP-порт.


в) Работа NTP-сети

Когда NTP-клиент отправляет запрос на сервер, он указывает в поле VN свою версию, в поле Mode – тип своей работы, а в поле Originate – время отправления этого запроса (по своим часам). Сервер, приняв запрос, заполняет в NTP-пакете все поля, скопировав в поле Originate значение, пришедшее в запросе. Таким образом, у клиента, когда к нему приходит ответ от сервера, имеются четыре значения времени: org (время отправки запроса), rec (время получения запроса сервером), xmt (время отправки ответа сервером) – из NTP-пакета и loc (время получения ответа) – по показаниям локальных часов в момент прихода ответа. При этом значения org и loc соответствуют показаниям часов локальной машины, а rec и xmt – показаниям часов сервера.

Выполняемая затем обработка этих значений аналогична действиям английского джентльмена из старой задачи Рэймонда М. Смаллиана (1978): «У одного человека не было наручных часов, но зато дома висели точные настенные часы, которые он иногда забывал заводить. Однажды, забывв очередной раз завести часы, он отправился в гости к своему другу, провел у того вечер, а вернувшись домой, сумел правильно поставить часы. Каким образом ему удалось это сделать, если время в пути заранее известно не было?» Ответ таков: «Выходя из дома, человек заводит часы и запоминает, в каком положении находятся стрелки. Придя к другу и уходя из гостей, он отмечает время своего прихода и ухода. Это позволяет ему узнать, сколько он находился в гостях. Вернувшись домой и взглянув на часы, человек определяет продолжительность своего отсутствия. Вычитая из этого времени то время, которое он провел в гостях, человек узнает время, затраченное на дорогу туда и обратно. Прибавив ко времени выхода из гостей половину времени, затраченного на дорогу, он получает возможность узнать время прихода домой и перевести соответствующим образом стрелки своих часов.» (http://ntl.narod.ru/logic/smullyan/name/p2.html#13)

Таким образом, по четырём данным мы находим время пакета в пути туда и обратно (loc – org), время его обработки (xmt – rec), а из них – чистое время пути пакета от локальной машины до сервера (loc – org – xmt + rec)/2. Значит, пакет пришёл на сервер в rec серверного времени и org + (loc – org – xmt + rec)/2 локального времени, и разница между серверным временем и локальным – (rec – org) – (loc – org – xmt + rec)/2 = (rec – org – loc + xmt)/2. Эта величина добавляется к локальному времени, и получается «истинное» время получения ответа.


Здесь мы пользуемся тремя предположениями: 1) пакет проходит путь от клиента до сервера и обратно за равное время; 2) скорость хода часов клиента и сервера равна; 3) на вычисление нового локального времени не уходит дополнительное время. На самом деле все эти предположения, строго говоря, не верны, и получить точное значение серверного времени с помощью одного NTP-запроса невозможно. Поэтому для синхронизации часов обычно используется несколько NTP-серверов, на которые постоянно шлются запросы. Накапливая статистику за длительное время, математическими методами можно определить точность показаний каждого из серверов, скорость хода часов на каждом из них, и т.п. величины, используя которые, можно добиться математически доказуемой точности синхронизации. Конкретные используемые методы описаны в RFC и чрезвычайно сложны.

г) NTP в целом

Подводя итог, NTP позволяет добиться высокоточной синхронизации времени в сети синхронизирующихся серверов, каждый из которых получает показания из нескольких источников, обрабатывает их, и передаёт дальше. Он применим только внутри небольших локальных сетей; в Интернете он практически неприменим из-за большой (и, что важно, случайной) задержки пакетов, которая на порядки превосходит разницы в показаниях часов клиента и сервера. Такая NTP-сеть характеризуется масштабируемостью и устойчивостью к сбоям – даже в случае отказа часов одного из серверов остальные немедленно это заметят и перестанут использовать его показания.

Сервера точного времени
а) Получение точного времени


NTP-сервера низких стратумов

Официальный список NTP-серверов первого стратума, т.е. непосредственно связанных с высокоточными часами, публикуется на http://ntp.isc.org/bin/view/Servers/StratumOneTimeServers. Наиболее известные из них –  tick.usno.navy.mil и tock.usno.navy.mil в USNO (http://tycho.usno.navy.mil/ntp.html) – сильно перегружены, и рассчитывать на них не стоит. В основном, как легко видеть из этих списков, NTP-сервера находятся в США в государственных и академических сайтах (домены .gov и .edu); сервера, расположенные в домене .mil, также многочисленны, но доступ к ним чаще всего ограничен (т.е. нужно писать письмо администратору NTP-сервера, объяснить ему цель своего использования его сервера, и тогда он, если захочет, откроет доступ).

В России, согласно списку, располагалось два сервера второго стратума – в Пушкино и Черноголовке, и нет серверов первого стратума. Как я проверил, эти два сервера уже не отвечают на запросы. Для своих экспериментов я использовал сервер первого стратума (с RefId = «PPS », т.е. связанного с атомными часами) в Borowiec, Польше; он удивил меня крайне малыми задержками (около 100 мс). Как выяснилось, системные часы моего компьютера спешат на 10 мс/мин.



Глобальная NTP-сеть

а) NTP-сеть в целом

В декабре 1999 г. сотрудник Google Нельсон Минар опубликовал работу, посвящённую исследованию глобальной NTP-сети: http://xenia.media.mit.edu/~nelson/research/ntp-survey99/

Он рассылал NTP-запросы по всем IP-адресам и анализировал приходящие ответы. Им сделаны следующие важные выводы о глобальной NTP-сети:

-обнаружено 175 тыс. общедоступных NTP-серверов (создатель NTP, Дэвид Л. Миллс из университета Делавэра, проводил похожие исследования и нашёл 990 серверов в 1989 г. и 39 тыс. – в 1997 г.);

-из этих серверов половина относятся к третьему стратуму, пятая часть – к четвёртому, 15% - ко второму, 4% - к пятому, и только 957 (0,5%) – первому. Минар даёт обоснование такого результата: сервера первого стратума расположены в правительственных учреждениях, второго – у входа в организацию и третьего – на каждом компьютере в организации, поэтому их и больше всего.

-средняя задержка до сервера высшего стратума – 29 мс для второго стратума, 15 мс для третьего, и убывает дальше; По сравнению с исследованием 1994 г. (42 мс для второго стратума и 36 – для третьего), Интернет стал в несколько раз быстрее.

-среднее число клиентов – 28 для серверов первого стратума, 3 – для второго, 0.5 – для третьего (у Миллса в 1997 г. – 20, 1.5 и 0.3  соответственно, т.е. NTP-сеть стала ветвиться сильнее);

Таким образом, картина глобальной NTP-сети такова: несколько перегруженных серверов первого стратума, окружённых большим облаком серверов второго стратума, и ещё большим облаком серверов третьего стратума. Вокруг них есть чуть-чуть серверов четвёртого и пятого стратумов, и остальные уже незаметны на их фоне.
Далее, Минар исследует эти несколько перегруженных серверов первого стратума. Из них две трети не имеют доступа к точным часам (!) Из оставшихся две пятых получают время от GPS-приёмника, 8% - от атомных часов, остальные - от радио-часов.

Две пятых всех серверов первого стратума имели неправильны показания (разница с правильными – более 10 сек). Из этих серверов 95% не имели доступа к точным часам; другими словами, они вводили в заблуждение пользователей, объявляя себя сервером первого стратума. Почему неправильные показания у остальных 5% серверов первого стратума, можно только догадываться; скорее всего, из-за неправильной настройки, т.к. один из серверов выдавал время с ошибкой на шесть с половиной лет (!)
К счастью, успокаивает Минар, из всех NTP-серверов высоких стратумов с неправильными часами первого стратума синхронизировано только 729 (0,4%), и даже из них 572 получают время также и от правильные часов. Т.е. нельзя заключать, что все часы в Интернете сбиты из-за плохих NTP-серверов; большинство часов синхронизировано именно с точными NTP-серверами, ещё больше их перегружая (30% всех серверов первого стратумов имеют более 10 клиентов, 15% – более 100, 5% – более 500, у tick.usno.navy.mil – около 2500).
В результате исследования Минар нашёл 363 NTP-сервера с точным временем и достоверным источником. В 1997 г. Миллс нашёл 220 таких серверов. Другими словами, хотя число NTP-серверов в Интернете выросло очень значительно, точное время выставлено лишь на небольшой их части, численность которой выросла не так значительно. Сервера первого стратума с верным временем и надёжным источником по-прежнему очень редки (меньше сотни).

В общем вот вам и мёд, и дёготь...

[Kostyan]

- 1212Lupus (1)

Костя! Я те точно по голове настучу! 
Если не понял сразу, то заявляю прямо -- сними мою кандидатуру! Немедля. Я против того, чтобы за меня голосовали.

Не Виталь, так не пойдет. Это будет по крайней мере не уважение к тем участникам форума , которые за тебя галочку ставили.  Против ?? очень хорошо. Ты в самом конце отказываешься от выйгранных выборов (если победишь конечно  ) и председателем будет человек набрашвий на ступеньку ниже голосов. А так все равноправны.
 
 Еще один момент. Если у нас наконец то появится председатель , то мы должны будем как то называтся (это к вопросу о названии клуба--и окрытом голосовании у нас на страничке). Есть три варианты , оставляем старое название (принятое на первых страничках ветки небольшим числом проголосовавших), теперешнее лидируюшие (непонятно кем выбранное), либо открываем новое параллельно с выбором председателя . Ваше решение ...

[xd]

Костя, с добрым утром

[Kostyan]

Костя, с добрым утром

Упс..  Ну вы бы хоть намекнули , а то бы век бы так и продолжал и не знать . Интрересно - интересно , а почему то думал что это просто слово  ..
Ок вопрос с этим закрыт.

[1212Lupus]

Интрересно - интересно , а почему то думал что это просто слово

Ну, блин! Действительно -- мы просто решили впихнуть хоть что-нить на нашу страницу. И тут как раз удачное слово подвернулось! Так по-твоему?

Итак, для тех, кто ещё не знает или уже забыл:
наша минская группа наблюдателей называется Infinity!

[Kostyan]

На сегодняшний день расклад следующий по кандидатам :

- Selestia  (3)
- Deimos   (1)
- 1212Lupus (1)
- Pova     (2)
- Kostyan (1)

[1212Lupus]

Значит так, уважаемые товарищи электронщики! В силу того, что поручаемые вам задания по поянию харда вы игнорируете и затягиваете  , облегчаю вам задачу: я тут задумал своять одну девайсину. Покупать детали, текстолит, травить его, паять буду я сам.  От вас только требуется небольшая консультация. Суть в следующем.
Необходимо сделать генератор коротких импульсов с периодом 1 секунда с возможно большей стабильностью и точностью. И ёжику понятно, что это может обеспечить только кварц.
А теперь -- внимание. Я сейчас буду говорить, а вы вникайте -- и если я что-то не то скажу или ошибусь где, то поправьте меня.
На первой картинке я нарисовал "схему, обеспечивающую повышенную стабильность частоты при изменении окружающей температуры в широком диапазоне" (линк, откуда я взял эту схему не помню...). Как видно из схемы, это генератор на 1 МГц.
Самая топорная идея -- берём и ставим после генератора последовательно 2 делителя частоты 1:1000 каждый (пример делителя 1:1000 на второй картинке). Получаем сигнал с частотой 1 Гц. Но это слишком просто... Самое важное, что необходим не меандр с f=1 Гц, а прямоугольные импульсы длительностью до 10 мс (в крайнем случае, 50 мс) и периодом 1 Гц. Вот тут к вам вопрос -- как это сделать, используя стандартные Интеграловские логические элементы?
Почему именно они? Да потому что они дешёвые и их на Казинца или на Жданах спокойно купить можно.
В общем, посоветуйте что-нить -- а то я цифровуху порядком подзабыл, т.к. уже года три с ней не сталкивался...