Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
Подобные обращения мы получали и раньше, но причиной всегда были сетевые ограничения на стороне пользователя (например, работодатель мог ограничивать запросы со стороны колонки в корпоративной сети)
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Для этого достаточно синхронизации между собой, нет необходимости долбить внешние сервера.
Самые хреновые кварцевые резонаторы, которые индустрия считает за кварц, а не за брак, плавают по частоте на 200 ppm в диапазоне температур -40+85 °C. Сомневаюсь, что станция испытывает столь резкие перепады температур, чтобы так часто синхронизоваться.
Кроме того, чем больше интервал между измерениями, тем точнее можно рассчитать ошибку частоты.
Как-то, когда у Андроида NITZ был более приорететным источником времени, чем NTP, мобильный оператор выдал мне время с отставанием на 15 минут. Было очень обидно.
Изучали сегодня с товарищем относительно свежую Yandex-станцию с относительно свежей прошивкой. Лезет нагло к pool.ntp.org. Работет в burst режиме. Эксперимента ради порезали ей исходящий ntp-трафик - ответила всплеском ntp-трафика, который потом сошёл на нет (видимо, перебирала всё, что могла найти в пуле). Экспериментов с частичной потерей пакетов не делали, но, возможно, частичная потеря пакетов будет её всегда держать в таком режиме
Сильно сомневаюсь, что на каком-нибудь 213.183.109.3, который плюется от 1000 до 3000 запросов в секунду, есть что-то с аналогичной Spamhaus ценностью, чтобы организовывать такую атаку. Скорее всего, там что-то взбесилось, но пристрелить это не удаётся, так-как провайдер игнорирует репорты.
Меньше чем за минуту ещё не все абюзеры успевают прийти, а потом ещё их запросам надо протолкаться в перегруженном канале. В общем, в текущей ситуации выявление аномалий весьма сложная задача.
Выглядело это так: аномально высокая частота запросов с 3-5 IP, достаточная, чтобы исчерпать лимит соединений механизма conntrack типично настроенного фаервола на Linux и т.п. statefull фаерволах, сагрить фаервол провайдера и т.д.
После чего система мониторинга пула исключает такой сервер из работы и перенаправляет весь его трафик на новых жертв. Ситуация повторяется.
Тогда не удивительно. SAR ADC весьма чувствительны к сопротивлению источника. В довесок ещё и коммутатор. Если сопротивление источника велико, то требуется весьма приличный буфер.
Тем не менее, у англоязычных есть такая единица измерения, как Words Per Minute. Размер слова принимается равным 5. У нас применяется термин группа, размер группы тоже 5 символов.
Ну, более доступным, чем FPGA решением являются сетевые карты, с аппаратной поддержкой PTP и распаянным пином для PPS. Особенно, карты с поддержкой PCIe PTM. Там вполне достижима ошибка меньше 10 нс. Теоретически, даже дешманские Intel i225 на это способны, однако в линуксовом драйвере это место то ломают, то чинят от патча к патчу.
Но основное веселье начинается при вводе PPS в компьютер. Например, типичный способ ввода PPS через CD-pin COM-порта может подарить несколько микросекунд задержки.
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Для этого достаточно синхронизации между собой, нет необходимости долбить внешние сервера.
Самые хреновые кварцевые резонаторы, которые индустрия считает за кварц, а не за брак, плавают по частоте на 200 ppm в диапазоне температур -40+85 °C. Сомневаюсь, что станция испытывает столь резкие перепады температур, чтобы так часто синхронизоваться.
Кроме того, чем больше интервал между измерениями, тем точнее можно рассчитать ошибку частоты.
А не подскажите, что конкретно сломается и какая точность времени требуется, чтобы не сломалось?
Как-то, когда у Андроида NITZ был более приорететным источником времени, чем NTP, мобильный оператор выдал мне время с отставанием на 15 минут. Было очень обидно.
Да, ещё она зачем-то регулярно шлёт запрос SOA для pool.ntp.org
Изучали сегодня с товарищем относительно свежую Yandex-станцию с относительно свежей прошивкой. Лезет нагло к pool.ntp.org. Работет в burst режиме. Эксперимента ради порезали ей исходящий ntp-трафик - ответила всплеском ntp-трафика, который потом сошёл на нет (видимо, перебирала всё, что могла найти в пуле). Экспериментов с частичной потерей пакетов не делали, но, возможно, частичная потеря пакетов будет её всегда держать в таком режиме
Так сейчас в пуле всего четыре активных сервера: https://www.ntppool.org/zone/ru
Сильно сомневаюсь, что на каком-нибудь 213.183.109.3, который плюется от 1000 до 3000 запросов в секунду, есть что-то с аналогичной Spamhaus ценностью, чтобы организовывать такую атаку. Скорее всего, там что-то взбесилось, но пристрелить это не удаётся, так-как провайдер игнорирует репорты.
Вполне вероятно. Получается, что каждая Yandex-станция ведёт себя как 1000 типичных, нормально сконфигурированных клиентов.
Меньше чем за минуту ещё не все абюзеры успевают прийти, а потом ещё их запросам надо протолкаться в перегруженном канале. В общем, в текущей ситуации выявление аномалий весьма сложная задача.
Для хронологии, меня это затронуло 26 октября.
Выглядело это так: аномально высокая частота запросов с 3-5 IP, достаточная, чтобы исчерпать лимит соединений механизма conntrack типично настроенного фаервола на Linux и т.п. statefull фаерволах, сагрить фаервол провайдера и т.д.
После чего система мониторинга пула исключает такой сервер из работы и перенаправляет весь его трафик на новых жертв. Ситуация повторяется.
Тогда не удивительно. SAR ADC весьма чувствительны к сопротивлению источника. В довесок ещё и коммутатор. Если сопротивление источника велико, то требуется весьма приличный буфер.
Тем не менее, у англоязычных есть такая единица измерения, как Words Per Minute. Размер слова принимается равным 5. У нас применяется термин группа, размер группы тоже 5 символов.
Ну, более доступным, чем FPGA решением являются сетевые карты, с аппаратной поддержкой PTP и распаянным пином для PPS. Особенно, карты с поддержкой PCIe PTM. Там вполне достижима ошибка меньше 10 нс. Теоретически, даже дешманские Intel i225 на это способны, однако в линуксовом драйвере это место то ломают, то чинят от патча к патчу.
Но основное веселье начинается при вводе PPS в компьютер. Например, типичный способ ввода PPS через CD-pin COM-порта может подарить несколько микросекунд задержки.
Все смешалось, кони, люди... Напоминает реферат школьника, которому необходимо набрать заданный объём, а связных текстов нужного размера не нашлось.
Отнюдь нет, смотрите EGA. Ну, а на рынке рабочих станций каких только извратов не было.
Вот-вот. За монтаж, изображенный на Рисунке 7 расстреливать надо, особенно в случае односторонней платы без металлизации отверстий.