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

По беспроводным каналам действительно проблема — получить уведомление, когда связь начинает ухудшаться. Дело в том, что связь иногда становится плохой задолго до полного обрыва. Она всё ещё работает, пакеты не теряются, но скорость ужасная, пинги на ptp-связи 20-50 мс. Нам нужно получать уведомление (например, по электронной почте), когда это происходит. Инструмент netwatch здесь не поможет, так как пакеты не теряются, они всё ещё передаются, просто слишком медленно, чтобы устроить клиента. Разные статистики беспроводного интерфейса слишком нестабильны, чтобы выставлять какие-то пороговые значения. Мне кажется, что единственное надёжное решение — это когда средний пинг за 2-3 минуты превышает заранее заданное значение для этой связи. Обычно проблема возникает, когда пинг на ptp-связях достигает 10-20 мс. Это делает пинг в dude бесполезным, так как разрешение по времени там около 10 мс. То есть все значения пинга в dude — 0, 10, 20 … мс, и это не годится для усреднения. Вопрос такой: есть ли способ получить реальные значения пинга (или любого другого времени кругового обхода) каким-то образом между двумя маршрутизаторами Mikrotik — через скрипт, dude или иначе (snmp?), чтобы их можно было собрать, усреднить и сравнить с порогом?

Netwatch может делать всё, что хочешь. /tool netwatch  
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=1s up-script=""  
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=500ms up-script=""  
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=50ms up-script=""  
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=5ms up-script=""  

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

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

psamsig и bburley, огромное спасибо, именно это я и собираюсь попробовать. Похоже, это как раз то, что мне нужно!

Да, netwatch — идеальный вариант. Возможно, я что-то неправильно понял. Вот как я это вижу: netwatch предназначен для другого — чтобы отслеживать события поднятия и падения канала. Мне не нужно мониторить статус канала — я уже делаю это через dude. Меня интересует другое: хочу отследить, когда среднее значение RTT по каналу за последние 10 минут становится больше, скажем, 10 мс. Меня не волнуют случайные колебания и потеря пакетов. Опять же, я вижу это в dude, и клиент мне простит, если у него на 10 секунд случаются проблемы. Но мне реально нужно видеть, что канал постоянно имеет высокую задержку в течение достаточно долгого времени. Хочу получать уведомление на почту с текстом «Ссылка между A и B, похоже, уже 30 минут работает с высокой задержкой, посмотрите, пожалуйста». Это важно, потому что в это время у клиентов медленный интернет, даже если потери пакетов нет, а они терпеть не могут тормоза. Я могу сделать это с помощью серии команд netwatch с разными таймаутами, отдельными скриптами для каждой команды, считающими, сколько раз каждый скрипт был запущен, и каким-то математическим анализом после. Но зачем мне это, если я могу иметь те же данные напрямую, измеренные с помощью серии flood ping каждые 1–2 минуты? Снова повторю, что мне не нужны абсолютные значения, меня не волнуют случайные поднятия/падения и скачки именно в этот момент. Мне нужен средний показатель за минуты. Учитывая всё вышесказанное — всё ещё лучше делать это через netwatch? Что я упустил?

Если вы хотите следить за качеством канала, почему бы не доверять значениям CCQ? (особенно если по каналу идет трафик) Думаю, через API несложно реализовать следующее:  
if($link-traffic > 1 Мбит/с) {  
 получить значения CCQ  
 если ($ccq < 80%) — вывести предупреждение  
} else {  
 провести нагрузочный ping  
 получить значения CCQ  
 если ($ccq < 80%) — вывести предупреждение  
}