Сбои в работе ЕДЦУ

[ver]

Всем коллегам привет!
В последнее время сложилась неприятная ситуация с работой устройств ЕДЦУ на Зап-Сибе. Повсеместно наблюдаются сбои в работе устройств ЕДЦУ, которые выражаются в кратковременном пропадании информации. Замена плат ничего не дает, поскольку часто пропадает информация от нескольких плат сразу, да еще и от разных контроллеров. Анализ загружености каналов ничего не дает-примерно одинаковая загрузка. По словам технолога АСК ПС, у них аналогичные проблеммы, но там не подвязаны поездные диспетчера и не рвутся нитки графика.
Где-то внутри есть ощущение, что причина может лежать в низкой скорости передачи данных модемом TSM (по документации это 1200 бит/сек).

[Admin]

Где-то внутри есть ощущение, что причина может лежать в низкой скорости передачи данных модемом TSM (по документации это 1200 бит/сек).

а раньше норм. работало?

[ver]

Занимаюсь диспетчерским контролем с 2001 года. Раньше ни о каком пропадании и речи не было. Первые сигналы начали проявляться где-то лет 5 назад, с внедрением программы "Мониторинг состояния устройств ЖАТ". Заметили на станции пропадание контроля стрелок. Пропадали все стрелки одной горловины. На станции замена МДВ-3с ничего не дала. В ГИДе никаких проблемм не возникало. ДСП в разговоре случайно натолкнула на мигающую лампочку - порвали кабель на перегоне. Отпаяли контроль этой лампочки - пропадание стрелок исчезло. Но находились они на разных платах.
Потом начали чаще пропадать контроли в "Мониторинге". Пропадали платами, но периодичность не прослеживалась.
Теперь же планерка службы на половину занята порваными нитками и пропаданиями информации.
Пометки на графике уже не редкость. Теперь и в ГИДе пропадание повторяется с пугающей регулярностью. Грешить на модули ввода не хочется, т.к. наблюдались повторения пропадания на уже замененных платах. К тому же пропадания хаотичные и могут возникнуть сразу на нескольких станциях.
К примеру, недавно на станции порвались нитки прибывающей электричке. Стояла у маршрутного, потом он ей в ГИДе и Монитринге не открылся. Естественно, нитка порвалась и пометка на графике. До электрички и после нее сигнал контролировался нормально. Плату заменили, проверили - все оптроны целы.
Разговаривали со связистами - советуют перейти на потоки Е1 с большими скоростями. Но это значит менять вся систему ЕДЦУ с вытекающими из этого затратами. Значит - фиг!
Менять все железо (а платы и контроллеры производства 90-х годов) - не на что. Производители приказали долго жить. Да и не грешится как-то на железо, хотя на некоторых платах уже и дорожки отстают).
Больше всего мыслей на то, что с массовой компьютеризацией СЦБ и других ж/д служб, с огромным количеством сетевых программ информация ЕДЦУ проходит по сетям с запазданием.
Коллеги с других дорог - а у вас как с этой бедой?

[Кабанбай Батыр]

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

А Пинг тест не пробовали ?

[olega88]

А Пинг тест не пробовали ?

Чего пинг???

ну расскажи

[Кабанбай Батыр]

Сообщение от olega88

Чего ...

Держи!
Когда вы обращаетесь в техподдержку провайдера из-за проблем с интернет-соединением, вас могут попросить проверить пинг. Что такое пинг? Зачем нужно его проверять? На эти вопросы отвечает Страна Советов.
Пинг (ping) — это специальная утилита, которая используется для проверки работоспособности сети. Она посылает запрос (пакет информации) серверу и фиксирует время, которое требуется запросу для того, чтобы достичь сервера и вернуться обратно. В обиходе это время тоже называют пингом. Хотя это название и неверно, но оно уже прижилось в среде пользователей ПК.

Зачем у вас просят проверить пинг при проблемах с сетью? Если время возвращения пакета слишком большое или если он не возвращается вообще, то проблема либо с сервером либо на участке сети между сервером и вашим компьютером. Если вы пингуете заведомо рабочий сервер (например, вашего провайдера), то время отклика помогает увидеть, есть ли проблемы на вашем участке сети. Если время в рамках нормы — то проблема может быть не с сетью, а, к примеру, с вашим браузером.

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

Проверить пинг можно при помощи стандартных средств операционной системы Windows. Для этого нужно запустить консоль (командную строку) Windows и вызвать из нее команду ping. Запустить командную строку можно разными способами. Один из них — это нажать на кнопку Пуск, выбрать в открывшемся меню пункт Все программы, в нем — пункт Стандартные. В списке стандартных программ будет Командная строка. Другой способ — опять-таки нажать на кнопку Пуск, выбрать пункт меню Выполнить, в открывшемся окне в строчке Открыть написать cmd и нажать на кнопку OK.

Откроется командная строка. В ней нужно ввести команду ping и через пробел — адрес сервера (можно вводить IP адрес или URL сайта). Если вам нужно проверить пинг до игрового сервера, введите адрес этого сервера. Если требуется проверить пинг интернета (качество интернет-соединения), введите адрес заведомо рабочего сервера — например, yandex.ru или google.com. Адрес можно вводить без http:// и/или www. Например, так:

ping google.com

Нажимаем на клавишу Enter и следим за результатами. При пинге сервера в результатах указывается:

размер отправляемого пакета в байтах (по умолчанию — 32 байта)
время отклика в миллисекундах
TTL (время жизни пакета) — время, которое компьютер будет ждать ответа от сервера
По умолчанию на сервер отправляется четыре пакета, после чего выводятся результаты проверки пинга: общее количество отправленных пакетов, количество полученных пакетов, количество потерянных пакетов, процент потерь, максимальное, минимальное и среднее время приема-передачи пакета.

Если пришли не все пакеты или если разброс между максимальным и минимальным временем приема-передачи слишком большой, то это может быть признаком проблем с сетью. Иногда проблемы с прохождением пакетов (особенно больших) вызывает включенный антивирус или файервол, поэтому перед проверкой пинга его лучше отключить.

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

-n задает число отправляемых пакетов, например ping google.com -n 10 означает, что на сервер будет отправлено 10 пакетов; между n и числом пакетов нужно поставить пробел
-t задает бесконечное число отправляемых пакетов: они будут отправляться до тех пор, пока вы не прекратите пинг вручную
-l задает размер пакета, например ping google.com -l 64 означает, что на сервер будут отправлены пакеты размером 64 байта; между l и размером пакета нужно поставить пробел
Можно одновременно использовать несколько ключей. Если вы хотите прервать пинг, нажмите сочетание клавиш Ctrl+C. Также можно проверить пинг при помощи сервисов для определения скорости интернета: многие из них проверяют не только скорость, но и пинг.


Ping — утилита для проверки соединений в сетях на основе TCP/IP, а также обиходное наименование самого запроса.
Первоначально словом «ping» (по созвучию) именовали направленный акустический сигнал противолодочных гидролокаторов или «асдиков» (англ. ASDIC, аббревиатура от Allied Submarine Detection Investigation Committee) времён Второй мировой войны.
Утилита отправляет запросы (ICMP Echo-Request) протокола ICMP указанному узлу сети и фиксирует поступающие ответы (ICMP Echo-Reply). Время между отправкой запроса и получением ответа (RTT, от англ. Round Trip Time) позволяет определять двусторонние задержки (RTT) по маршруту и частоту потери пакетов, то есть косвенно определять загруженность на каналах передачи данных и промежуточных устройствах.
Обычный эхо-запрос имеет длину 64 байта (плюс 20 байт IP-заголовка). По стандарту RFC 791 IPv4 суммарный объем пакета не может превышать 65 535 байт.
В разговорной речи пингом называют также время, затраченное на передачу пакета игровой информации в компьютерных сетях от клиента к серверу и обратно от сервера к клиенту.
Полное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из промежуточных маршрутизаторов) блокирует ICMP Echo-Reply или игнорирует ICMP Echo-Request.
Программа ping является одним из основных диагностических средств в сетях TCP/IP и входит в поставку всех современных сетевых операционных систем. Функциональность ping также реализована в некоторых встроенных ОС маршрутизаторах, доступ к результатам выполнения ping для таких устройств по протоколу SNMP определяется RFC 2925 (Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations).
Так как для отправки ICMP-пакетов требуется создавать raw-сокеты, для выполнения программы ping в UNIX-системах необходимы права суперпользователя. Чтобы обычные пользователи могли использовать ping, в правах доступа файла /bin/ping устанавливают SUID-бит.


Заголовочный пинг – ето один из наиболее популярных и наиболее полезных инструментов, служащих к диагнозу соединений-онлайн, основанных на TCP/IP протоколе. Его имплементацию можно встретить практически в каждой оперативной системе, которая обслуживает выше приведённый протокол. Функциональность пинга основывается на очень простом правиле работы. Она состоит в отправлении пакета ICMP ECHO_REQUEST из локального компьютера к днстанционной машине, а потом в ожидании ответа в форме пакета ICMP ECHO_REPLY.
Пример употребления инструмента пинг на практнке (вызывается из линии команд, представляя как параметр адрес IP или символическое наименование целевого устройства – это может быть компьютер, но также рутер, а то и сетевой принтер):

OpenBSD:


-bash-3.2$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=128 time=0.347 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=128 time=0.170 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=128 time=0.167 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=128 time=0.169 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=128 time=0.166 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.166/0.203/0.347/0.073 ms

Виндоуз:

C:>ping 10.0.0.2
Тест 10.0.0.2 с 32 байтами данных
64 байтов из 10.0.0.2: байтов=32 время< 1 мс TTL=128
64 байтов из 10.0.0.2: байтов=32 время< 1 мс TTL=128
64 байтов из 10.0.0.2: байтов=32 время< 1 мс TTL=128
64 байтов из 10.0.0.2: байтов=32 время< 1 мс TTL=128
Статистика теста пинг для 10.0.0.2:
Пакеты: Отправленные=4, Полученные=4, Потраченные=0 (0% утраты),
Оценочное время блуждания пакетов в миллисекундах:
Минимум = 0 мс, Максимум = 0 мс, Средневолновое время = 0 мс

При помощи инструмента пинг можно получить основные информации, касающиеся к состоянии сетевого соединения между локальным компьютером и дистанционным устройством:

• Есть ли устройство подключённое к сети и отвечает ли оно на требование ECHO_REQUEST при помощи правильно сконструированного пакета ECHO_REPLY?
• Какая средняя задержка в получении ответа (разговорно называемая «лагом»), выражаемая в миллисекундах.
• Какая часть общего числа пакетов добирается к адресату, а какая подвергается утерии? Этот параметр выражается в процентах, его стоимость выше нуля указывает технические проблемы ретранслятора сообщения.


Следует здесь чётко отметить, что результаты, полученные при помощи пинга, представляют достоверное изображение состоянии сетевого соединения. В преобладающим большинстве популярных операционных систем существует возможность выключения реакции на надвигающиеся пакеты ECHO_REQUEST (напр. при помощи программного обеспечения типа межсетевой экран). Это станет причиной недостатка в пакетах ECHO_REPLY в ответе, и тем самым может являться причиной подозрения в аварии ретранслятора, несмотря на его правильное функционирование. По этой причине пинг употребляется обычно во вступительной диагностике, известных пользователю/администратору, локальных компьютерных сетей. Зато в профессиональных употреблениях пинг – это только один из многих использоваемых инструментов. Второй важный аспект пинга – это факт, что он достовляет информации только насчёт состоянии сетевого соединения – получение ответа от дистанционной машины означает только, что она подкючённая к сети и отвечает на требование пинг. Однако не можно на основании этого делать выводы насчёт вида и состоянии услуг, запущенных на тестированном устройстве. Кроме того, не можно предполагать, что его операционная система работает правильно (относительно часто встречается случаи, когда компьютер отвечает на пинга, несмотря на зависание операционной системы).
Инструмент пинг, в зависимости от имрлементации в данной операционной системе, может содержать ряд дополнительных направлений (в системах Юникс можно узнать о них с помощью команды man ping, зато в системах Виндоуз этой командой является ping -?):

• Пинг непрерывный до самого прекращения со стороны пользователя (догадливое поведение в системах Юникс, параметр –t в Виндоуз, напр.: „ping –t 10.0.0.2”).
• Определяемый размер пакетов в байтах, с 1 до около 65500 байтов (параметр –s в системах Юникс, -l в Виндоуз, напр. ping –s 128 10.0.0.2 станет причиной отправления пакета в размере 128 байтов вместо догадливых 32). Это направление является полезным особенно в случае беспроволочных сетей, в которых спорадически может появиться явление утери больших пакетов, при полностью беспроблемной пересылке маленьких.
• Десятка полтора других, реже использоваемых параметров, таких, как напр. определённое число пакетов для высылки (-c в системах Юникс, -n в Виндоуз), т. н. ping flood, то есть максимальное возможное число пакетов для одновременной высылки, определение параметра TTL, то есть

максимального числа узлов, проходимых по дороге до целевого устройства, и т. п.

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

[olega88]

Хотя это название и неверно, но оно уже прижилось в среде пользователей ПК.

спасибо, аликсандр Михалыч, а уровнем посложнее не подкинете? тут темка не простая, wireshark поможете осилить?

[Михаил Лупинос]

могу сказать как свидетель сбоев в едцу. Мне кажется что проблема в канале. А точнее в пакете который теряется и получается пока повторный не придет.

[olega88]

могу сказать как свидетель сбоев в едцу. Мне кажется что проблема в канале. А точнее в пакете который теряется и получается пока повторный не придет.

вот может ЧЕЛОВЕК поможет, ты Миша вроде как по этой теме, как извлечь данные из электронного письма, задание такое

[Михаил Лупинос]

а там как вложение должно быть. И сохранить нажать. Или правым кликом на обьект.

[Просто инженер АиТ]

Конечно, различные разработчики распределённых систем по разному подходят к обмену данными в распределённой сети. Когда мы создавали свою систему АСДК, были низкоскоростные сети и достаточно слабые компьютеры (286, 386), поэтому приходилось очень внимательно подходить к вопросу трафика обмена. Как правило сообщения систем АСДК, ДЦ, СТДМ, КТСМ и т.д. достаточно короткие, но их очень много, если каждое такое сообщение передавать отдельным TCP сообщением, то трафик будет очень большим, поэтому мы просто передавали пакеты сообщений систем в одном TCP сообщении, что значительно снижало трафик и увеличивало производительность программного обеспечения.