"Переполнение" millis() для чайников" (очередной пост, надеюсь последний)

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

Судя по количеству подобных тем, и стабильного вайна в камментах этих тем, данный вопрос до сих пор считается актуальной, так как ни кто до сих пор не может внятно доходчиво осветить вопрос с позиции новичка. Дабы попытаться в очередной раз закрыть тему я решил предложить свою версию.

Не буду заострять внимание на millis(), описание функции есть в разделе "Программирование", а поговорим прежде сего об использовании данной функции. И логичнее всего использовать данную функцию для измерения абстрактных промежутков времени между какими либо событиями. Например, нам требуется рассчитать время между аппаратными прерываниями. Для наглядности воспользуемся примерном с тактовой:

Только пусть это будет некая важная кнопка, нажатие на которую ни в коем случае нельзя пропускать. По этому ради этого события мы будем прерывать программу, а время между прерываниями будем выводить через последовательный порт:

unsigned long interruptTime = 0;
volatile boolean interrupt = false;

void setup()
{  
  Serial.begin( 9600 );
  //Назначаем прерывание на заземление прерывателя 0(Pin 2)  
  attachInterrupt( 0, ifInterrupt, FALLING );
}
void loop()
{
  // Если значение переменной true
  if( interrupt )
  {
    // Показываем разность между текущим временем и временем момента 
    // предыдущего прерывания
    Serial.println( millis() - interruptTime );
    // Записываем время момента прерывания
    interruptTime = millis();
    interrupt = false;
  }
}
void ifInterrupt()
{
  // Прерывание изменяет значение переменной.
  interrupt = true;
}

Теперь попробуем представить ситуацию, когда вот-вот, в ближайшие миллисекунды, наступит этот страшный для многих момент! :) Когда произойдёт обнуление таймера. На самом деле с таймером ничего не случится конечно-же, просто произойдет переполнение переменной, в которую он записывает свое текущее значение, и отсчет опять начнется с нуля, но ни коим образом не остановится. Для примера подставим почти предельное значение переменной момента времени прерывания в скетч. После запуска программы таймер пойдёт от нуля, тем самым эмитируя ситуацию переполнения при нажатии на кнопку:

unsigned long interruptTime = 4294967290;

И, о чудо, ничего не произошло, контроллер на месте, не дымится, взрывов не слышно :) а на экране вполне корректное время прерывания от момента до переполнения. А все потому что, если попробовать записать в беззнаковую переменную отрицательное значение, оно будет вычтено из максимально возможно значения данного типа переменной.

Спасибо за внимание. Надеюсь, для кого-то этот пост будет полезен.

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

Больше объяснений, хороших и разных!

Хотя, боюсь, что коллеги правы :(((

Logik
Offline
Зарегистрирован: 05.08.2014

А сколько переполнений выдерживает таймер?

Ворота
Ворота аватар
Offline
Зарегистрирован: 10.01.2016

Эт смотря чем ты его смазываешь и насколько регулярно проходишь ТО.

kasper007
Offline
Зарегистрирован: 23.05.2016

Logik пишет:

А сколько переполнений выдерживает таймер?

будет работать пока не переполнится счетчик переполнений. Вот тогда точно конец настанет.

trembo
trembo аватар
Offline
Зарегистрирован: 08.04.2011

 Я бы в сетапе вставил чтобы не возиться с привязкой:
 pinMode ( 2 , INPUT_PULLUP);

negavoid
Offline
Зарегистрирован: 09.07.2016

Logik пишет:
А сколько переполнений выдерживает таймер?

Пока затворы полевиков в триггерах регистров не протрутся :)))

wdrakula
wdrakula аватар
Offline
Зарегистрирован: 15.03.2016

negavoid пишет:

Пока затворы ... :)))

Затворы клацают. В расчерченной на клетки,

Хуарес, ведомости делает отметки.

И попугай, весьма тропической расцветки,

Сидит на ветке и вот так поёт:

"Презренье к ближнему у нюхающих розы

ничуть не лучше,но честней гражданской позы..."

(с) И.Бродский

okta
Offline
Зарегистрирован: 10.01.2015

А если кнопку, например, нажимают раз в два месяца... то всёвыврёте)))

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

okta пишет:

А если кнопку, например, нажимают раз в два месяца... то всёвыврёте)))

а, если не нажимать совсем, т.е. НИКОГДА, то у нас будет своё маленькое, домашнее Переполнение Шредингера.

qwone
qwone аватар
Offline
Зарегистрирован: 03.07.2016

У millis() есть очень важный секрет, если она переполнится, то в ней ничего нет.

vk007
Offline
Зарегистрирован: 16.06.2015

qwone пишет:
если она переполнится, то в ней ничего нет.

Вот оно оказывается откуда японцы подчерпнули идею.

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

okta пишет:

А если кнопку, например, нажимают раз в два месяца... то всёвыврёте)))

Если сильно нужно нажимать реже чем раз в 2 месяца, можно запустить счетчик обнулений разрядов, если это будет uint32_t, то этого должно хватить примерно на 500 - 600 миллионов лет :-)

Ну и как продвинутый вариант, сделать свой 8 байтный счетчик (uint64_t) :-)

sadman41
Offline
Зарегистрирован: 19.10.2016

Всё уже украдено до нас: https://www.faludi.com/itp/arduino/millis_rollover.pde

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

Этот дурдом никогда не закончится :(

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

ЕвгенийП пишет:

Этот дурдом никогда не закончится :(

...без разговоров - в пропасть(с)

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

Всё уже украдено до нас: https://www.faludi.com/itp/arduino/millis_rollover.pde

Один вопрос - "зачем"? :-)

Ведь millis() это эффективный инструмент микротайма, позволяющий исключить блокирующие задержки, когда нужно, например, отфильтровать "дребезг", или посчитать время между импульсами. Для остальных вещей проще и точнее использовать часы реального времени, цена вопроса не больше 50-100р на Али.

Logik
Offline
Зарегистрирован: 05.08.2014

Нужно создать на форуме раздел - "Переполнения таймера и борьба с ним". И каждый вошедший в него автоматом перекидывается на тему "вставка кода в форум". Польза будет стопудово.

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

cyber-jet пишет:

Один вопрос - "зачем"? :-)

Действительно :)

sadman41
Offline
Зарегистрирован: 19.10.2016

Примерный аптайм девайса незамысловато посчитать без RTC, например. 

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

Logik пишет:

Нужно создать на форуме раздел - "Переполнения таймера и борьба с ним". И каждый вошедший в него автоматом перекидывается на тему "вставка кода в форум". Польза будет стопудово.

Наверное в разделе "Программирование" не совсем доходчиво написано для многих, что таймер millis() НЕТОЧНЫЙ!!! :) И я не представляю, где такая погрешность устроит разработчика, если нужно будет отсчитать хотябы сутки.

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

cyber-jet пишет:

Logik пишет:

Нужно создать на форуме раздел - "Переполнения таймера и борьба с ним". И каждый вошедший в него автоматом перекидывается на тему "вставка кода в форум". Польза будет стопудово.

Наверное в разделе "Программирование" не совсем доходчиво написано для многих, что таймер millis() НЕТОЧНЫЙ!!! :) И я не представляю, где такая погрешность устроит разработчика, если нужно будет отсчитать хотябы сутки.

дык, и секундный в RTC неточный - кого такая погрешность устроит, если нужно будет сосчитать хотя бы месяц.

Logik
Offline
Зарегистрирован: 05.08.2014

cyber-jet пишет:

Наверное в разделе "Программирование" не совсем доходчиво написано для многих, что таймер millis() НЕТОЧНЫЙ!!! :) И я не представляю, где такая погрешность устроит разработчика, если нужно будет отсчитать хотябы сутки.

А шо такое? Меня устраивает. Знавал я тут людей, которые тоже не жаловались. Конечно часики на атомах цезия поточней. Но дороже. 

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

cyber-jet пишет:

таймер millis() НЕТОЧНЫЙ!!!

А что в этом мире точно? Разве что то, что все мы когда-то умрём, а вера в Катастрофическое Великое Переполнение не умрёт никогда.

sadman41
Offline
Зарегистрирован: 19.10.2016

Мне вот, к примеру, нужно поймать внешним мониторингом ребут девайса. Событие определяется по факту простого уменьшения аптайма - было 41837849, стало 3345. Т.е. нужен монотонно нарастающий счетчик. Таковой уже есть в системе - millis(). Одна проблема - каждые 49 дней фиксируется ребут, которого не было, мониторинг начинает слать тревожные письма, считая, что случился вселенский пипец. С помощью несложного фокуса и фиксации rollover я могу эту проблему устранить. Поэтому точность в пределах любого неторопливого ухода счетчика в любую сторону меня вполне устраивает. 

Зачем мне в этой задаче RTC, идущий с атомной точностью? 

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

Logik пишет:

А шо такое? Меня устраивает. Знавал я тут людей, которые тоже не жаловались. Конечно часики на атомах цезия поточней. Но дороже. 

Если единичный промежуток, то там обычно да, не важно, +/- час на месяце, ОК.)) Но я что-то слабо себе эту ситуацию представляю, ибо синхронность таких промежутков в процессах скорее всего приязана к реальному ("астрономическому") времени, и нужна гораздо большая точность. Но это всего лишь тема для дальнейшых филосовских рассуждений... :)

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

sadman41 пишет:

Одна проблема - каждые 49 дней фиксируется ребут, которого не было

Проблема надумана и высосана из пальца.

sadman41 пишет:

С помощью несложного фокуса и фиксации rollover я могу эту проблему устранить. 

А если её (проблему) изначально не выдумывать, то и устранять бы не пришлось.

 

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

Зачем мне в этой задаче RTC, идущий с атомной точностью? 

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

sadman41
Offline
Зарегистрирован: 19.10.2016

ЕвгенийП пишет:

sadman41 пишет:

Одна проблема - каждые 49 дней фиксируется ребут, которого не было

Проблема надумана и высосана из пальца.

С чего вы так решили? 

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

Ну, с Вашего описания проблемы.

1. Вам нужно слать сообщения при ребуте? Так поставьте в функцию setup отправку "я ребутнулся" и шлите на здоровье

2. Или Вам нужно звне спросить у контроллера "ты ребутнулся?". Ну, тогда заведите флаг "Да, ребутнулся", и при первом же опросе его сбрасывайте.

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

sadman41
Offline
Зарегистрирован: 19.10.2016

ЕвгенийП пишет:

Ну, с Вашего описания проблемы.

...

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

 

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

Всё понятно. Вы полагаете, что мониторинг - это один опрашивающий сервер с заранее известным адресом...

Нормально задачу можете описать. Шлет вам хост флаг ребута, непонятно с какой сети, но знает адрес куда слать, так? И вам нужно посчитать что?

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

cyber-jet пишет:

Шлет вам хост флаг ребута, непонятно с какой сети, но знает адрес куда слать, так? И вам нужно посчитать что?

это я его спамлю ребутами его серверов. О_О

ЕвгенийП
ЕвгенийП аватар
Онлайн
Зарегистрирован: 25.05.2015

sadman41 пишет:

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

А по-Вашему мониторинг, это когда кто попало опрашивает кого попало, когда попало и сколько попало раз? Хорошая системная архитектура.

Это, как раз тот случай о котором я и говорил: если не выдумывать себе проблем, то и решать их не придётся.

sadman41
Offline
Зарегистрирован: 19.10.2016

cyber-jet пишет:

Нормально задачу можете описать. Шлет вам хост флаг ребута, непонятно с какой сети, но знает адрес куда слать, так? И вам нужно посчитать что?

Вот вам задача, если вы их любите:

Есть система мониторинга (Zabbix, если уж вам в деталях хочется знать). При работе агента в пассивном режиме сервер Zabbix опрашивает агентов, получая с них значения метрик. Опрашиваемым хостом может оказаться кто угодно - например коммутатор, сервер под управлением какой-либо ОС, дисковая полка и пр. и др. Необходимо при ребуте хоста послать сообщение администратору сети или техническому персоналу. Для этого существует механизм триггеров, которые срабатывают по изменению метрики. Сервер мониторинга может находится в одной ip-подсети, агенты - в другой. Даже на разных географических площадках они могут находится.  Устройства (агенты) получают адреса по DHCP, сервера их находят по DNS. Про сервера агенты не знают, просто отдают значение метрики по запросу. Для обеспечения надежности введены избыточные сервера мониторинга. 

Придумайте надежный способ определения факта ребута устройства, избегая ложных срабатываний при числе серверов мониторинга > 1 шт.

 

sadman41
Offline
Зарегистрирован: 19.10.2016

ЕвгенийП пишет:

А по-Вашему мониторинг, это когда кто попало опрашивает кого попало, когда попало и сколько попало раз? Хорошая системная архитектура.

Вы придумываете какую-то ерунду, ей-богу. 

Не кто попало, а несколько дублирующих серверов. Не кого попало, а агентов мониторинга. Не сколько попало, а с заданной периодичностью. Если вы считаете, что в кровавом энтерпрайзе оборудование повально имеет функцию "флаг ребута" и рассчитано на доступ исключительно с одного, жестко заданного хоста, а сервер мониторинга всегда один и заранее известен, то хочу вас разочаровать.

Да, в SNMP есть система трапов, с помощью которой можно уведомить сервер мониторинга о ребуте, но даже она поддерживается не всем брендовым оборудованием. А уж в мелкоардуину ее запихивать вместе с интерфейсом управление - занятие для безумцев.

 

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

Вот вам задача, если вы их любите:

...Необходимо при ребуте хоста послать сообщение администратору сети или техническому персоналу...

Если честно, не могу понять, причем здесь таймер вообще...

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

cyber-jet пишет:

sadman41 пишет:

Вот вам задача, если вы их любите:

...Необходимо при ребуте хоста послать сообщение администратору сети или техническому персоналу...

Если честно, не могу понять, причем здесь таймер вообще...

анекдот про Ржевского, Наташу Ростову и весло знаешь?

...отож.

sadman41
Offline
Зарегистрирован: 19.10.2016

cyber-jet пишет:

sadman41 пишет:

Вот вам задача, если вы их любите:

...Необходимо при ребуте хоста послать сообщение администратору сети или техническому персоналу...

Если честно, не могу понять, причем здесь таймер вообще...

Ну так вы задачку-то решили - как определить факт ребута агента в описанной выше конфигурации? 

qwone
qwone аватар
Offline
Зарегистрирован: 03.07.2016

cyber-jet пишет:

Если честно, не могу понять, причем здесь таймер вообще...

нормально. Это приколы старухи Шепокляк. Ставите таймер, таймер посылает сообщение кому на голову пошлет. А потом попытаюся определить кто послал, а вам там уже нет.

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

sadman41 пишет:

Ну так вы задачку-то решили - как определить факт ребута агента в описанной выше конфигурации? 

не знаю, что там у тебя за конфигурация, но если в сетапе увеличивать значение счётчика, хранящееся в EEPROM на единицу, то этот вариант должен покрыть все возможные недоконфигурации - ты будешь знать, сколько раз запускалось устройство от начала времён до настоящего момента.

и, кстати, "да" - где-то я потерял в своём варианте переполнение и миллис

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

Ну так вы задачку-то решили - как определить факт ребута агента в описанной выше конфигурации? 

а, т.е. это не агент, а пассивный узел, который отзывается на пинг? И нужно эти все узлы опрашивать, и если есть задержка между стандартной то выдавать что-то?

Мне задачи решать незачем, если хост должен послать, то должен, безо всяких millis()...

Logik
Offline
Зарегистрирован: 05.08.2014

sadman41 пишет:

Придумайте надежный способ определения факта ребута устройства, избегая ложных срабатываний при числе серверов мониторинга > 1 шт.

 

Толи я Вас не понимаю, толи проблема - не проблема. Варианты.

1. Хост опосля ребута отправляет уведомление "я ребутнулсо" на некоторый сервер, рассылающий далее кому надо. Требование - хосты должны это уметь. Зато быстро и надежно.

2. Любой из серверов мониторинга (их>1) обнаружив факт ребута хоста при опросе рассылает уведомления кому надо. Тригер ребута сбрасывается. Недостаток - каждый сервер должен знать и уметь рассылать.

3.Любой из серверов мониторинга (их>1) обнаружив факт ребута хоста при опросе уведомления серверу рассылки (возможно это один из серверов мониторинга). Тригер сбрасывается. Сервер рассылки делает свое дело. Недостаток -  не одноранговая сеть. Вариация на тему - сервер рассылки только хранит список адресатов рассылки, сервер мониторинга по нему рассылает уведомление.

4. Любой из серверов мониторинга  при опросе запоминается на хосте и получает инфу о своем предыдущем заходе. Лучше сохраняет и получает кукис. При ребуте  эта инфа сносится. Получается у каждого сервера индивидуальный тригер.

5. Гибрид варианта 4 и одного из 1-3. Тригер какбы один, но в зависимости от ID пришедшего сервера его значение разное за счет механизма из п.4

6. все сервера мониторят, но рассылает ошибки и сбрасывает тригер только один. Похоже на п.3 но без межсерверного обмена и медленее.

Как видите варианты есть, время вобще не при чем. Вопрос только что доковыривать можна: сервер, датчик или обоих.

sadman41
Offline
Зарегистрирован: 19.10.2016

cyber-jet пишет:

а, т.е. это не агент, а пассивный узел, который отзывается на пинг? И нужно эти все узлы опрашивать, и если есть задержка между стандартной то выдавать что-то?

Допустим, что отзывается, но это необязательно, конечно. ICMP может быть перекрыт в разнообразных целях. Но агегт отдает значения метрик по SNMP, через JSON, XML API или как-то иначе. И, в третий раз повторяю, - нужно определить факт ребута, а не задержки или еще там что-то.  

cyber-jet пишет:

Мне задачи решать незачем, если хост должен послать, то должен, безо всяких millis()...

Вы хотели, цитирую, "Нормально задачу можете описать. " - я вам описал ее так, как она выглядит в реальности.

Если вам лень об этом думать или вы не представляете, какой в энтерпрайзе мониторинг и для чего он - так и напишите, тут нет ничего зазорного, это достаточно специфическая область.

И, еще раз повторю, хост никому ничего не должен. Не он следит за собой, за ним следят несколько серверов, заранее хосту неизвестных.  

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

нужно всем, кому лень думать, проголосовать дабы демократическим большинством прекратить это бесполезное для общества занятие. О_О

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

...не представляете, какой в энтерпрайзе мониторинг и для чего он - так и напишите...

"Уважаемый", если вы так пишете, то зачем вам наш форум?

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

cyber-jet пишет:

sadman41 пишет:

...не представляете, какой в энтерпрайзе мониторинг и для чего он - так и напишите...

"Уважаемый", если вы так пишете, то зачем вам наш форум?

ты анекдот про Ржевского, Наташу Ростову и весло знаешь?

...отож. О_О

cyber-jet
cyber-jet аватар
Offline
Зарегистрирован: 17.10.2017

sadman41 пишет:

И, в третий раз повторяю, - нужно определить факт ребута, а не задержки или еще там что-то.  

Если вы пишете в данной ветке, то скорее всего вы лжоте...

Клапауций 112
Клапауций 112 аватар
Offline
Зарегистрирован: 01.03.2017

sadman41 пишет:

И, еще раз повторю, хост никому ничего не должен. Не он следит за собой, за ним следят несколько серверов, заранее хосту неизвестных.  

алё! аутист, ты когда прекратишь сам с собой разговаривать? - я тебе пердоставил решение #40

угомонись.

nik182
Offline
Зарегистрирован: 04.05.2015

Казалось бы - при чём здесь ардуина? Клиенты на ней? О! Месье знает толк в извращениях! 

sadman41
Offline
Зарегистрирован: 19.10.2016

Logik пишет:

1. Хост опосля ребута отправляет уведомление "я ребутнулсо" на некоторый сервер, рассылающий далее кому надо. Требование - хосты должны это уметь. Зато быстро и надежно.

Проигрышная тактика. Сервер отпал (сам или канал до него) - никто не узнал о ребуте.

 

Logik пишет:

2. Любой из серверов мониторинга (их>1) обнаружив факт ребута хоста при опросе рассылает уведомления кому надо. Тригер ребута сбрасывается. Недостаток - каждый сервер должен знать и уметь рассылать.

Более лучший вариант, но сложный по администрированию в плане выстраивания отношений между серверами.  Как правило строят кластерную, синхронизирующуюся на уровне БД. Однако в случае географически распределенных серверов - синхронизация может превратится в беду.

Logik пишет:

3.Любой из серверов мониторинга (их>1) обнаружив факт ребута хоста при опросе уведомления серверу рассылки (возможно это один из серверов мониторинга). Тригер сбрасывается. Сервер рассылки делает свое 

Та же проблема, что и в п.1, но перенесена на сервер рассылки.

Logik пишет:
4. Любой из серверов мониторинга  при опросе запоминается на хосте и получает инфу о своем предыдущем заходе. Лучше сохраняет и получает кукис. При ребуте  эта инфа сносится. Получается у каждого сервера индивидуальный тригер.
 
Для встроенных систем проигрышное решение из-за ограниченности ресурсов. Не встречал нигде - ни в цисках, не в хп.
 

Logik пишет:
6. все сервера мониторят, но рассылает ошибки и сбрасывает тригер только один. Похоже на п.3 но без межсерверного обмена и медленее.

И с проблемой из п.1
 
Logik пишет:

Как видите варианты есть, время вобще не при чем. Вопрос только что доковыривать можна: сервер, датчик или обоих.

Я вижу, что сценарии вы умеете проигрывать разные. 

Однако, пользуясь тем, что практически каждый хост отдает uptime (даже сраный дешманский dlink имеет что-то тикающее и не обязательно точно), любая система мониторинга определит факт ребута по отрицательной разнице между текущим и предыдущим значением этой метрики. Способ более дешевый наврядли можно придумать. И вот эту бодягой с синхронизациями серверов, флагами, рассылками, записями в ЕЕПРОМ можно даже не заниматься. Любой из N серверов точно знает, что был ребут (конечно, если не раз в пятилетку запрашивает uptime). И это штатное решение систем мониторинга.

Надеюсь, что о связи uptime со счетчиком секунд/миллисекунд/чего угодно мне писать нет необходимости.  В противном случае остается только прекратить эти бессмысленные разъяснения.