Кибернетика, автоматика, протоколы

Вот, только что довелось разгребать проблему. Не суть, но железки новосибирские проверил: Time statistics Eth delay, ms income delay, ms # TS period min max min max -- ----- ----------- ----------------------------------------- 12 0-31 23:18-23:20 1.077 5.591 -0.938 1.051 Работа канала за две минуты. В обе стороны идут пакеты, по 1000 в секунду с каждой. Размер пакета, в данном случае, 8*32+36=292 байта всего. Больше не нужно. Цифры delay показывают петлевую задержку на реальной сети. Между устройствами три или 4 Ethernet-коммутатора с гигабитными интерфейсами. Инакм дилэй - это отклонение времени прихода пакета от корреспондента относительно ожидаемого алгоритмом регулировки скорости последовательного инетрфейса. То есть, как бы джиттер относительно средней, но не фиксированной скорости. Вот тот же канал несколько минут позднее: Time statistics Eth delay, ms income delay, ms # TS period min max min max -- ----- ----------- ----------------------------------------- 12 0-31 23:18-23:27 0.729 8.170 -0.962 1.077 Видно, что предельные значения раздвинулись. Ситуация усложняется тем, что в канале есть небольшая вероятность потерь из-за дефекта преобразователя среды передачи. И крайнее время петлевой задержки не согласуется с джиттером. Пакет, не пришедший в ожидаемое время, перезапрашивается и повторяется сразу, как только корреспондент получил запрос. Отсюда и 8.2мс вместо 1.8мс. Железки железные. Даже зависание CPU на работу каналов не влияет. FPGA продолжают молотить как положено. Пока писал, вот следующий период статистики пошёл: Eth delay, ms income delay, ms # TS period min max min max -- ----- ----------- ----------------------------------------- 12 0-31 23:18-23:30 0.729 8.170 -0.962 1.077 23:29-23:35 1.058 7.349 -0.949 1.062 Вот так и работает. Если приоритеты 802.1p расставлены, очереди настроены и оборудование исправно, то при большей нагрузке лишь немного растёт джиттер. Но, несмотря на самые тщательные настройки, по совершенно разным причинам, канал не работает вечно. Падает от нескольких раз в день до раза в пару месяцев, как ни старайся, если сеть разветвлённая. То ошибётся в настройке кто, то перегрузка трафиком, то работы на кабелях. Так или иначе, канал падает. Единственный случай припоминаю, на момент разборки временного канала на радиорелейной линии через ~5км морской поверхности, время бесперебойной работы канала было 146 дней. То есть, FPGA вне подозрений. Всё внешние факторы. Про пропускную способность не скажу. В этом оборудовании максимум 5Мбит/с на 100М интерфейсе используем или 35Мюбит/с на гигабитном. Можно и больше, но практически нужды не было. Кстати, отмечу, что практически использовать каналы реального времени на Ethernet сети типа как у провайдера Интернет с джиттер-буферами менее 10мс мне не удалось. Ну, 4-5мс ещё можно запустить в работу. Но и месяца не пройдёт, начнутся перебои и придётся увеличивать буфер до 10..22мс. В некоторых случаях, когда каналы с потерями, и больше. Чтобы дать железке время на перезапросы потерь.