caxapa.ru :: Нихрена не понял. Но из того, что понял, вопрос в том, какого размера квант времени оптимально использовать для работы с типовым последовательным портом и типовым интерфейсом Ethernet, чтобы обеспечить минимальное время отклика и максимальную

Nikolay_Po (05.04.2018 13:58, просмотров: 386) ответил Экспериментатор на Хочу поговорить на тему: "Квантование времени в ПЭВМ при обращении к COM-port и Ethernet." Кто-нибудь тут понял, о чем я?

Нихрена не понял. Но из того, что понял, вопрос в том, какого размера квант времени оптимально использовать для работы с типовым последовательным портом и типовым интерфейсом Ethernet, чтобы обеспечить минимальное время отклика и максимальную пропускную способность. И как определить размер этого кванта времени. Так? Возьмёшь размер пакета больший, чем квант - побьётся на кванты внутри ПЭВМ с накладными расходами. Возьмёшь меньше - недоберёт пропускной способности. Очевидно, для Ethernet оптимальный квант времени равен времени отправки одного полного кадра плюс межкадровый зазор. Это если драйвера не "кривые". Про ком-порт железный ничего не знаю, про ЮСБ-шный можно ориентироваться на размер пакета данных интерфейса в режиме High Speed, а так же смотреть структуру конкретного моста USB-UART, объём его буфера обычно прямо указан. Скорее всего, квант времени для последовательного порта будет равен времени заполнения и опустошения этого буфера.

Ответить

- Близко. Нужно выбирать одно из двух: минимальное время отклика или максимальную пропускную способность. Причина - накладные расходы на служебную часть пакетов и системный тик ПЭВМ. Экспериментатор(573 знак., 05.04.2018 15:54, )
  - Вот, только что довелось разгребать проблему. Не суть, но железки новосибирские проверил: Nikolay_Po(3228 знак., 07.04.2018 23:48)
    - Я так понимаю, что такие большие задержки из-за радиоканала. На 1Гбит Экспериментатор(779 знак., 08.04.2018 22:27, )
      - В моём примере был не тест на столе, а реальная сеть. Тест ещё не созрел. Nikolay_Po(2195 знак., 09.04.2018 02:10)
  - У меня на работе есть железки, деланные новосибирцами. Они по Ethernet гоняют потоки E1, восстанавливая синхронизацию по потоку фреймов. Железки используют метки времени в каждом фрейме и измеряют как джиттер, так и петлевую задержку в канале. Там Nikolay_Po(1072 знак., 05.04.2018 17:25, ссылка)
    - "Лишь проведя большое количество измерений различных ПК можно понять, насколько актуальна проблема." - у меня есть такие данные для COM-port, для Ethernet в процессе накопления. Экспериментатор(408 знак., 05.04.2018 19:59, )
      - К слову, есть другие железки, ещё не Линукс, прошивки размером 1-3Мб, VoIP. При перезагрузке, если держать железку на ICMP ping, по ходу загрузки, IP-часть "поднимается" раньше верхнего уровня. И часть пакетов ping, пока оборудование "грузится", Nikolay_Po(460 знак., 05.04.2018 21:11)
        
        Квантование видно на коротких пакетах и больших скоростях обмена. Экспериментатор(267 знак., 05.04.2018 21:38, )
      - Попробую, если будет время. Коллега в отпуск уходит, с завтяшнего. Нагрузки будет больше, не обещаю. Железок пара как раз есть. Размер кадра 36 байт служебных данных, остальное - данные потока E1, до 1408 байт. Итого, на уровне Ethernet кадры до Nikolay_Po(64 знак., 05.04.2018 21:02)
  - >времни задержки между отправкой кадра и его получением lloyd(563 знак., 05.04.2018 16:30)
    - Возьмем для примера какой-нибудь сферический ПЛК с Ethernet и связанный с ним напрямую ПЭВМ под виндовс. ПЭВМ посылает MODBUS TCP команду ПЛК, тот выдает ответ, например, показания АЦП (пусть цикл ПЛК для простоты равен 0мкс). Через какое Экспериментатор(374 знак., 05.04.2018 16:57, )
      - 1. Происходит прерывание от MAC-модуля по принятому пакету. Записывается текущее время пакета, пакет ставится в очередь на обработку lloyd(934 знак., 05.04.2018 22:13)
        
        Спасибо за описание. Этот топик в первую очередь об уменьшении пропускной способности интерфейсных портов из-за квантования времени, а не о латентности. Очевидно, что при системном тике 1мс пропускная способность Ethernet по такому механизму будет Экспериментатор(366 знак., 05.04.2018 22:58, )
        
        Микросекундный тик - пожалей свой процессор, он так не умеет. Стандартный лялих имеет 100герцовый систик, реалтаймовый - 1кгц. lloyd(204 знак., 06.04.2018 06:38)
        
        Что-то не так. Для Ubuntu 16.04 LTS Low latency and real-time kernels пишут про тик в 1мкс, см. ниже. Для винды есть документы про 1мс. Эмбеддеров интересует не потоковая передача, а запрос-ответ, как в моем примере. Экспериментатор(144 знак., 06.04.2018 07:08, )
        
        >новые данные на запрашиваются, пока не получен ответ на предыдущий запрос lloyd(480 знак., 06.04.2018 07:47)
        
        Режим запрос-ответ обоснован промышленными протоколами обмена и принципами автоматизации процессов. Не надо путать системный тик и латентность ОС. Для очень многих применений хватает стандартного стека. В необходимых случаях у меня есть в кармане Экспериментатор(437 знак., 06.04.2018 09:05, )
        
        UbuntuStudio -> --> Evgeny_CD(52 знак., 05.04.2018 23:22, ссылка, ссылка)
        
        Ятебяумоляю. Собери своё ведро - и будет тебе щастя. Когда гонял генту, оно на доморощенном ведре работало. Tickless или tickful - сам решай. - SciFi(05.04.2018 23:11)
        
        "Не говорите мне, что делать и я не скажу, куда вам пойти." (с) Если этого не делает сам разработчик, значит есть какие-нибудь минусы. В чем там проблемы, можете написать по делу? - Экспериментатор(05.04.2018 23:22, )
        
        Послюшай, дарагой. Они ориентируются на широкую аудиторию. Нахуа мне гадать, что ими двигает? Сам у них спроси. И оправдай, наконец, свой ник. Собери ведро и погоняй. С тебя не убудет. - SciFi(05.04.2018 23:43)
        
        Мальчик с ником Научная фантастика и длинным языком требует от других соответствия нику? Нет ли здесь пропаганды гомосексуализма? - Экспериментатор(06.04.2018 07:11, )
      - Тот софт, который в таких случаях стоит со стороны ПК часто не способен работать с дискретностью времени менее 100 мс, задержка прохождения пакетов на этом фоне не заметна и не критична. Т.е. пример вы выбрали не удачный. - AlexG(05.04.2018 18:03)
        
        Не соглашусь. Пример был выбран так, чтобы были официальные данные тестов и таблицы времен для разных операций. Компьютер Pentium 400 МГц с 128 мегабайтами ОЗУ :) Полный цикл программы около 25мс. Экспериментатор(138 знак., 05.04.2018 19:42, )
        
        Дык в чем проблема? Iperf и вперед. Для разных OS, архитектур и протоколов имеется. Я тут как то приводил результаты испытаний для W7500P, LPC1768 и ENC28+мега328. Вот, например, UDP под ХP для W7500P (по-ссылке). 16000 100-байтных пак/сек Гудвин(94 знак., 05.04.2018 20:25 - 20:36, ссылка)
        
        А тут точно ping-pong? А не куча кинутых параллельно с ПК на устройство пакетов? - Evgeny_CD(05.04.2018 21:03)
        
        Так что ваш ник липовый ;) - Гудвин(05.04.2018 20:25)
        
        Напрашиваетесь на разговор о Вашем нике :) ICMP от доставки до приложения различаете? - Экспериментатор(05.04.2018 21:25, )
        
        При чем тут ICMP? Это на картинке так - для параллельного контроля "железного" стека wiznet. Приложение на дельфях посылает UDP пакеты определенного размера, ждет ответа. После приема снова посылает. Пинг-понг, короче... - Гудвин(06.04.2018 12:25)

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