caxapa.ru :: Близко. Нужно выбирать одно из двух: минимальное время отклика или максимальную пропускную способность. Причина - накладные расходы на служебную часть пакетов и системный тик ПЭВМ.

Экспериментатор (05.04.2018 15:54, просмотров: 1) ответил Nikolay_Po на Нихрена не понял. Но из того, что понял, вопрос в том, какого размера квант времени оптимально использовать для работы с типовым последовательным портом и типовым интерфейсом Ethernet, чтобы обеспечить минимальное время отклика и максимальную

Близко. Нужно выбирать одно из двух: минимальное время отклика или максимальную пропускную способность. Причина - накладные расходы на служебную часть пакетов и системный тик ПЭВМ. Для USB в первую очередь влияет системный тик ОС, он просто виден в угле наклона ПРЯМЫХ пропускной способности от размера пакета. Для ethernet UDP наблюдал монотонный рост, но с 10Мбит/с на коротких пакетах остается мало, велики накладные расходы. Ethernet бывает разным, есть даже через USB. Хотелось бы от Вас услышать подробнее про кривые драйвера. Ethernet занимаются более серьезные люди, для него можно найти примеры расчетов пропускной способности. К сожалению, тема времни задержки между отправкой кадра и его получением раскрыта слабо. Поможете чуть раскрыть?

- Вот, только что довелось разгребать проблему. Не суть, но железки новосибирские проверил: 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)

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