Определить скорость передачи данных 1 Мбит/с

Я попробовал просто перезагрузить, но это не решило проблему надолго, поэтому пришлось заново зайти в клиентское оборудование, сделать /system reset и заново применить наш кастомный скрипт конфигурации — и это решило проблему. Возможно, когда скрипт изначально добавляли на оборудование, он применился не полностью? Моя задача — сделать так, чтобы оборудование автоматически определяло, когда используется скорость передачи данных 1 Мбит/с, и отправляло письмо. Тогда до того, как клиент пожалуется, мы уже будем в курсе проблемы.

Скрипт, судя по всему, работает корректно! (полностью проверить получится только после завершения скрипта и применения его ко всем CPE). Следующий шаг, если можно предложить, — записывать данные в новый файл, содержимое которого можно будет очищать (или удалять) после отправки уведомления по email, поскольку стандартные логи удалить нельзя (можно попробовать уменьшить размер строк лога). http://forum.mikrotik.com/t/how-to-clear-log/24416/23 Вот скрипт, который я использую для обнаружения ошибок маршрутизации в логах с последующей отправкой письма, не уверен, поможет ли он (также нужно читать из отдельного файла, а не из стандартных логов):

global lastTime;  
:local adminmail1 "XXXXXXXXX@gmail.com";  
:local adminmail2 "XXXXXXXX@hotmail.com";  
:local sub1 ([/system identity get name])
:local sub2 ([/system clock get time])
:local sub3 ([/system clock get date])
:local company ""  
:local gmailid xxxxxxx@gmail.com  
:local gmailuser xxxxxxxx@gmail.com  
:local gmailpwd  
:local gmailport 587  
:local gmailsmtp  
:set gmailsmtp [:resolve "smtp.gmail.com"]
:local currentBuf [ :toarray [ /log find message~"new master flag=false" || message~"wrong peer state" || message~"init" || message~"2-WAY" || message~"Full to Down"] ];
:local currentLineCount [ :len $currentBuf ];

if ($currentLineCount > 0) do={  
  :local currentTime "$[ /log get [ :pick $currentBuf ($currentLineCount -1) ] time ]";

  :if ([:len $currentTime] = 15 ) do={
     :set currentTime [ :pick $currentTime 7 15 ];
  }  

  :local output "$currentTime $[/log get [ :pick $currentBuf ($currentLineCount-1) ] message ]";

  :if (([:len $lastTime] < 1) || (([:len $lastTime] > 0) && ($lastTime != $currentTime))) do={
     :set lastTime $currentTime ;  
     /tool e-mail set address=$gmailsmtp port=$gmailport start-tls=yes from=$gmailid user=$gmailuser password=$gmailpwd  
 /tool e-mail send to=$adminmail1 subject="$sub3 $sub2 Router:$sub1 Routing Error "  body="$output" start-tls=yes  
 /tool e-mail send to=$adminmail2 subject="$sub3 $sub2 Router:$sub1 Routing Error "  body="$output" start-tls=yes  
  }  
}

ммм, если примешь мой совет: лучше и проще использовать Telegram-бота, это напрямую и понятно [/tool netwatch] пример Telegram-бота на YouTube https://youtu.be/6sVrUJi9_K8 если согласен, могу помочь тебе

В настоящее время скрипты, которые ищут ключевые слова в дефолтных логах, имеют недостаток — приходят повторяющиеся письма об одной и той же проблеме. Например, ниже показано, что письмо будет приходить каждые 15 минут (запуск скрипта по расписанию):

may/09/2017 23:15:00 Router:XXXX_PTP_XXXX Routing Error 16:40:42     new master flag=false  
may/09/2017 23:30:00 Router:XXXX_PTP_XXXX Routing Error 16:40:42     new master flag=false  
may/09/2017 23:45:00 Router:XXXX_PTP_XXXX Routing Error 16:40:42     new master flag=false  

Похоже, мне нужны два скрипта!

(1) Скрипт для обнаружения 1Mbps — готов, большое спасибо.  
(2) Скрипт, который ищет ключевые слова в дефолтных логах, создает новый лог-файл (назовем его "keywords") с найденными ключевыми словами и отправляет письмо,  
(2a) этот скрипт должен сравнивать временные метки в дефолтном логе и файле keywords, чтобы при обнаружении дубликата не создавать новую запись в файле "keywords" и не отправлять письмо — чтобы избежать циклов,  
(2b) неважно, что файл keywords перезаписывается новыми ключевыми словами, найденными в дефолтных логах.  

Подойдет ли такое решение?

Ребята, спасибо за отличную информацию. Часто ли эта проблема с 1Mbit повторяется? (после обновлений версии или перезагрузок?) Похоже, у меня что-то похожее:  
 

set [ find default-name=wlan1 ] band=2ghz-g/n basic-rates-a/g=9Mbps basic-rates-b="" bridge-mode=disabled default-authentication=no default-forwarding=no disabled=no disconnect-timeout=2s distance=indoors frequency=2427 guard-interval=long ht-basic-mcs="" ht-supported-mcs="mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15,mcs-16,mcs-17,mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23" hw-protection-threshold=1536 max-station-count=30 mode=ap-bridge multicast-helper=full preamble-mode=short rate-set=configured rx-chains=0,1 ssid=PROOMWLAN supported-rates-a/g=9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps supported-rates-b="" tx-chains=0,1 wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled

Некоторые клиенты, вероятно, переходят на самую низкую скорость передачи, когда им нечего отправлять, чтобы экономить энергию или повысить надежность, или что-то в этом роде. У меня в сети два устройства: одно — Raspberry Pi с USB-адаптером 802.11n, другое — одноплатный компьютер NEXT THING CHIP. Оба при простое показывают скорость передачи 1 Мбит/с (в колонке Rx на MikroTik). Когда я начинаю передавать с них данные, скорость возрастает.

edit cut

Uldis, насколько точен показатель «последнее измерение»? По моему мнению, поскольку сервис работает медленно, данные о скорости перемешаны. Должен быть либо набор 1, 2, 5.5 и 11, либо 6, 9, 12, 18, 24, 36, 48 и 54, но не 1, 6, 9, 12, 18, 24, 36, 48, 54. 5 ГГц только для N — раньше было A/N, теперь все CPe только N, на расстоянии 8–12 км. Впервые заметил это в версии V6.35 и с тех пор проверяю, когда клиенты жалуются, что при стриминге идет буферизация.