Только что прочел в LXF116:
Анонсированный в октябре 2008 года коммуникатор Edelweiss на платформе ACCESS Linux так и не будет выпущен - вместо него компания Emblaze Mobile сфокусируется на новой модели под кодовым именем Monolith.
Честно говоря, вся эта шумиха вокруг Edelweiss с самого начала казалась мне подозрительной. И отсутствие комментариев по некоторым техническим вопросам на пресс-конференции, и слишком навернутая аппаратная начинка, и укзания на Россию, как стартовый рынок...
2009-03-14
2009-03-12
NTP для Arduino
Недавно наткнулся на упоминание о протоколе SNTP в контексте его использования для Arduino - проект аналоговых часов 3MeterClock.
В описании говорится, что часы используют для получения времени Simple NTP. Сначала я прочел это как SNMP, затем SMTP. Потом прочел по буквам и понял, что требуется man, а именно: как поднять сервер SNTP, потому что ну очень хочется написать скетч для Arduino для синхронизации по сети.
Из RFC2030 выяснилось, что никакого отдельного сервера SNTP не надо. Для NTP или SNTP сервера клиенты NTP и SNTP неразличимы, также как и для NTP или SNTP клиента неразличимы NTP и SNTP сервера. Алилуйя!
Все отличия заключаются в том, что значительно упрощены вычисления, с целью максимально упростить жизнь клиенту и добиться точности не хуже микросекунд.
Каково же было мое удивление, когда в исходниках все того же 3MeterClock-а я обнаружил... обращение к порту 13! Опять внимательно покопавшись в RFC, пришел к выводу, что у Arduino есть как минимум ТРИ разных варианта получения информации о времени по сети:
Получается, реально в 3MeterClock используется вовсе не SNTP, а DayTime. Логично, ведь не нужно корпеть над переводом мегачисла секунд, натикавших с 01.01.1900, в текстовую дату и время. Одна беда: стандарт протокола не заставляет строго форматировать возвращаемую строку. Неудивительно, поскольку протокол предназначен в основном для дебаговых целей, в отличие от NTP/SNTP.
То есть, можно увидеть как Tuesday, February 22, 1982 17:37:43-PST, так и 02 FEB 82 07:59:01 PST. Ясно дело, что если "заточиться" под определенный сервер, то будет вам счастье (однозначный парсинг текстовой строки). Вот авторы и "прибили гвоздем" свой sketch к серверу time.nist.gov, который отвечает 54901 09-03-11 10:44:51 50 0 0 831.6 UTC(NIST).
Следовательно, авторы проекта немного схалявили, что вполне простительно :) Однако, можно было бы не путать DayTime и SNTP, вводя читателей в заблуждение. Впрочем, пытливый читатель все равно разберется :)
Мысль про SNTP изначально правильная, потому что шансов получить время по NTP гораздо больше, чем через Time или DayTime. И даже если заранее неизвестен сервер времени, то можно попробовать спросить спросить время в режиме anycast (если не страшно, что вас обманут). Однако, как же быть с вычислениями?
Для начала, надо преобразовать время NTP в эпоху UNIX, т.е. получить число секунд, натикавших не с 01.01.1900, а с 01.01.1970. По счастью, эта разница уже подсчитана: надо вычесть из NTP 2208988800UL. Во многих случаях, одного этого уже достаточно, чтобы Arduino мог правильно общаться с внешним миром. Но что, если хочется немного больше - например, поддерживать время в МК или индицировать его на дисплее?...
Была бы под руками <time.h>, можно было бы ей воспользоваться. Но, увы, её нет среди библиотек avr, и придется обратиться к GNUтым исходникам glibc. Выдирается с мясом процедура __offtime, выносится пара структур и... готово:
В описании говорится, что часы используют для получения времени Simple NTP. Сначала я прочел это как SNMP, затем SMTP. Потом прочел по буквам и понял, что требуется man, а именно: как поднять сервер SNTP, потому что ну очень хочется написать скетч для Arduino для синхронизации по сети.
Из RFC2030 выяснилось, что никакого отдельного сервера SNTP не надо. Для NTP или SNTP сервера клиенты NTP и SNTP неразличимы, также как и для NTP или SNTP клиента неразличимы NTP и SNTP сервера. Алилуйя!
Все отличия заключаются в том, что значительно упрощены вычисления, с целью максимально упростить жизнь клиенту и добиться точности не хуже микросекунд.
Каково же было мое удивление, когда в исходниках все того же 3MeterClock-а я обнаружил... обращение к порту 13! Опять внимательно покопавшись в RFC, пришел к выводу, что у Arduino есть как минимум ТРИ разных варианта получения информации о времени по сети:
- SNTP/NTP - при помощи UDP по порту 123. Клиенту надо послать пакет запроса, в ответ сервер его заполнит различными временными метками, и, если клиент озаботился засечь время отсылки запроса, можно относительно просто получить время с учетом RTT (RFC2030, RFC1305). Время в метке NTP отсчитывается в секундах с 01.01.1900 (еще есть fraction part в 1/65535-х долях секунды, но такая точность лично мне пока не нужна).
- Time protocol - при помощи TCP или UDP на порт 37. Клиенту надо послать пустой пакет, в ответ вернется 32-битное время, формат тот же (RFC868).
- DayTime protocol - при помощи TCP или UDP на порт 13. Клиенту надо послать также пустой пакет, но в ответ вернется дата и время в виде ASCII-строки (RFC867).
Получается, реально в 3MeterClock используется вовсе не SNTP, а DayTime. Логично, ведь не нужно корпеть над переводом мегачисла секунд, натикавших с 01.01.1900, в текстовую дату и время. Одна беда: стандарт протокола не заставляет строго форматировать возвращаемую строку. Неудивительно, поскольку протокол предназначен в основном для дебаговых целей, в отличие от NTP/SNTP.
То есть, можно увидеть как Tuesday, February 22, 1982 17:37:43-PST, так и 02 FEB 82 07:59:01 PST. Ясно дело, что если "заточиться" под определенный сервер, то будет вам счастье (однозначный парсинг текстовой строки). Вот авторы и "прибили гвоздем" свой sketch к серверу time.nist.gov, который отвечает 54901 09-03-11 10:44:51 50 0 0 831.6 UTC(NIST).
Следовательно, авторы проекта немного схалявили, что вполне простительно :) Однако, можно было бы не путать DayTime и SNTP, вводя читателей в заблуждение. Впрочем, пытливый читатель все равно разберется :)
Мысль про SNTP изначально правильная, потому что шансов получить время по NTP гораздо больше, чем через Time или DayTime. И даже если заранее неизвестен сервер времени, то можно попробовать спросить спросить время в режиме anycast (если не страшно, что вас обманут). Однако, как же быть с вычислениями?
Для начала, надо преобразовать время NTP в эпоху UNIX, т.е. получить число секунд, натикавших не с 01.01.1900, а с 01.01.1970. По счастью, эта разница уже подсчитана: надо вычесть из NTP 2208988800UL. Во многих случаях, одного этого уже достаточно, чтобы Arduino мог правильно общаться с внешним миром. Но что, если хочется немного больше - например, поддерживать время в МК или индицировать его на дисплее?...
Была бы под руками <time.h>, можно было бы ей воспользоваться. Но, увы, её нет среди библиотек avr, и придется обратиться к GNUтым исходникам glibc. Выдирается с мясом процедура __offtime, выносится пара структур и... готово:
2009-03-06
Linux Format в PDF
Сегодня мне прислали уведомление, что вышел мартовский номер журнала Linux Format, и вместе с ним - ссылку для скачивания.
Ради интереса скачал, подтверждаю: да, это работает! Правда, на каждой странице этого PDF мелким красным шрифтом ненавязчиво указывается, что это подписка такого-то (ФИО), адрес, телефон, мыло ;)
Ну да ничего: я никому и не собираюсь раздавать, я - законопослушный ;)
Кстати, вроде как предложение на халявный выпуск в электронном формате при подписке на бумажный еще действует (специально посмотрел - до 31.03.2009), так что не упустите свой шанс! ;)
Ради интереса скачал, подтверждаю: да, это работает! Правда, на каждой странице этого PDF мелким красным шрифтом ненавязчиво указывается, что это подписка такого-то (ФИО), адрес, телефон, мыло ;)
Ну да ничего: я никому и не собираюсь раздавать, я - законопослушный ;)
Кстати, вроде как предложение на халявный выпуск в электронном формате при подписке на бумажный еще действует (специально посмотрел - до 31.03.2009), так что не упустите свой шанс! ;)
Подписаться на:
Сообщения (Atom)