16+
Среда
18 июля
Вход |Карта сайта | |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Кибернетика

 
   Новая тема Правила Регистрация Поиск »» Архив
Вернуться в конференциюТопик полностью
Nikolay_Po  (07.04.2018 23:48) , в ответ на Близко. Нужно выбирать одно из двух: минимальное время отклика или максимальную пропускную способность. Причина - накладные расходы на служебную часть пакетов и системный тик ПЭВМ. автор: Экспериментатор
Вот, только что довелось разгребать проблему. Не суть, но железки новосибирские проверил: 
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мс. В некоторых случаях, когда каналы с потерями, и больше. Чтобы дать железке время на перезапросы потерь.
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7526 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXVIII