io-pkt повышение приоритета

[denver]

Добрый день!

Столкнулся с проблемой повышения приоритета модуля io-pkt версия QNX 6.5.0. Пробовал несколько способов:

Код:

ifconfig en0 destroy
io-pkt-v4 -ptcpip rx_pulse_prio=250 -drtl
mount -Tio-pkt /lib/dll/denv-rtl.so

Код:

ifconfig en0 destroy
on -p 50f io-pkt-v4 -ptcpip -drtl
mount -Tio-pkt /lib/dll/denv-rtl.so

Пользовательский процесс, в котором выполняются функции работы в сети запущен с приоритетом 250. При этом top отображает два потока io-pkt-v4. Один из них имеет приоритет 250, второй 21 (по умолчанию). В результате делаю вывод, что основной поток работает с приоритетом по умолчанию и данные способы не принесли ожидаемого результата. Все ли я правильно делаю? Может какая-то ошибка есть в командах. Хотя интерфейс поднимается, но приоритет по умолчанию остается.

Теперь опишу зачем мне это надо. Необходимо отправлять в сеть пакеты с частотой 250 мкс, с отклонениями не более 100 мкс. В консольном режиме, то есть без запуска Photon, все работает нормально, оклонения присутсвуют, но они минимальны. Однако, при запуске той же программы из под Photon наблюдаются значительные отклонения, вплоть до 400 мкс. Возникают они при перерисовке экрана, движениях мыши и т.д. Судя по всему причиной является то, что на тестируемой конфигурации отсутсвует драйвер на видеокарту, подключается программный vesa и он вытесняет io-pkt. Пробовал запускать Qt приложение, но результаты ожидаемо такие же. Таким образом, остается повысить приоритет io-pkt, чтобы по крайней мере io-display и устройства ввода вывода не вытесняли его.

Заранее спасибо за помощь.

[Владимир Махилёв]

Повысить приоритет основного потока io-pkt можно с помощью опции -P, однако для этого потребуется версия io-pkt из QNX 6.5 SP1.

Советую разобраться и однозначно определить кто именно вызывает задержку. Исключить из системы всё лишнее и последовательно запускать только необходимые драйверы устройств. Сильно помочь в этом может сбор системной трассы событий (Kernel Event Trace) с помощью IDE или tracelogger.

Вполне вероятно, что задержку может вызывать прерывание от периферии (USB, графика и т.п. вплоть до NMI). Ситуация будет хуже если одно прерывание делится между различными устройствами, например сетью и USB. В этом случае, стоит проверить версию образа с startup-apic и отключить в настройках BIOS всё лишнее (USB legacy и т.п.)

Если вытеснение происходит всё-таки на уровне прикладных потоков, а не обработчиков прерываний, то можно подключить адаптивный планировщик aps (Adaptive Partitioning) и выделить вашему приложению и io-pkt гарантированный бюджет процессорного времени.

[denver]

Повысить приоритет основного потока io-pkt можно с помощью опции -P, однако для этого потребуется версия io-pkt из QNX 6.5 SP1.

Спасибо, буду пробовать.

Советую разобраться и однозначно определить кто именно вызывает задержку. Исключить из системы всё лишнее и последовательно запускать только необходимые драйверы устройств. Сильно помочь в этом может сбор системной трассы событий (Kernel Event Trace) с помощью IDE или tracelogger.

Трассу собирал через IDE, правда в тестирование сети вмешивается qconn. Из трассы следовало, что на 5 прерывании висели io-pkt и io-usb, io-usb я отключил через slay. Однако, это не помогло. Также io-pkt находится на нулевом прерывании вместе с procnto-smp-inst. Устройства ввода/вывода (клавиатура и тачпад), которые вносят эти задержки находятся на отдельном прерывании.

Вполне вероятно, что задержку может вызывать прерывание от периферии (USB, графика и т.п. вплоть до NMI). Ситуация будет хуже если одно прерывание делится между различными устройствами, например сетью и USB. В этом случае, стоит проверить версию образа с startup-apic и отключить в настройках BIOS всё лишнее (USB legacy и т.п.)

Про данную утилиту ничего не знаю, да и с qnx всего 2 недели знаком, буду разбираться. USB legacy отключил. Хотя отключение io-usb наверное более эффективно.

Если вытеснение происходит всё-таки на уровне прикладных потоков, а не обработчиков прерываний, то можно подключить адаптивный планировщик aps (Adaptive Partitioning) и выделить вашему приложению и io-pkt гарантированный бюджет процессорного времени.

Спасибо за наводку, буду пробовать.
Еще отмечу, что системный тик установлен в 10 мкс, при его увеличении до 50 мкс ситуация немного улучшилась, задежки в среднем стали меньше, по крайней мере при работе в Photon. В Qt почти тоже самое осталось.

[Владимир Махилёв]

Попробуйте запустить образ, работающий с APIC контроллером прерываний (образ включает в себя системные модули startup-apic и PCI сервер pci-bios-v2).
Проще всего это сделать с помощью уже готового загрузочного образа от QNX
http://www.qnx.com/download/feature.html?programid=21181

Однако в дальнейшем вам наверняка придётся переключиться на подготовку своего образа, что в целом правильнее для встраиваемой системы чем использовать штатного универсального образа. (Глава документации по сборке загрузочного образа в справке называется Making an OS Image).
В своем образе вы сможете изначально регулировать какие драйверы запускать и с какими опциями, т.е. будет гораздо проще определить причину, вызывающую задержки.
Более того, вы сможете подключить адаптивный планировщик (Глава документации Setting Up and Using the Adaptive Partitioning Thread Scheduler).


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

[Андрей Докучаев]

Более того, вы сможете подключить адаптивный планировщик (Глава документации Setting Up and Using the Adaptive Partitioning Thread Scheduler).

Квотирование процессорного времени при единственном процессоре может иметь катастрофические последствия в задачах минимизирования времени отклика системы.

Теперь опишу зачем мне это надо. Необходимо отправлять в сеть пакеты с частотой 250 мкс, с отклонениями не более 100 мкс. В консольном режиме, то есть без запуска Photon

Чтобы исключить влияние устройств ввода/вывода достаточно при отключенных Photon и io-usb запустить в консоли egl-gears. При программной отрисовке эта утилита генерирует исключительно вычислительную нагрузку и обращение к видео-памяти. Таким образом, при наличии существенных задержек можно будет с весьма высокой вероятностью говорить о том, что влияние прерываний отсутствует, так как только лишь наличие подобной нагрузки будет достаточным для появления эффекта.

[denver]

Благодарю за предоставленную инфомацию, обязательно разберусь со всем!  Проблема вроде решилась даже без повышения приоритета io-pkt. Хотя этот параметр -P все равно мне не помог(( Установил патч SP1, поставил системный тик в 50 мкс, пробовал различные значения, но этот в моем случае оказался оптимальным. В photon проблем нет, при запуске одного Qt приложения ситуация хуже, хотя для меня это странно немного. В Qt в целом все хорошо, но бывают провалы аж в несколько мс, около 3 мс, причем потом пакеты с оч высокой частотой идут, как будто буферизация. Возможно проблема связана с тем, что я ставлю приоритет 254 для всего запускаемого процесса, а надо бы только для потока, который отправку осуществляет и для таймера. Но все покажет теперь тестирование на большом промежутке времени.

Со своим образом вряд ли получится работать, так как если сейчас все будет удачно, придется использовать вашу сертифицированную МОРФ систему, а там насколько я понимаю различные правки параметров запуска и так далее недопустимы. Но это следующий этап)

[Андрей Докучаев]

а там насколько я понимаю различные правки параметров запуска и так далее недопустимы

Не буду утверждать, что являюсь специалистом в этом вопросе, но мне это видится более чем странным.

[Владимир Махилёв]

В Qt в целом все хорошо, но бывают провалы аж в несколько мс, около 3 мс, причем потом пакеты с оч высокой частотой идут, как будто буферизация. Возможно проблема связана с тем, что я ставлю приоритет 254 для всего запускаемого процесса, а надо бы только для потока, который отправку осуществляет и для таймера. Но все покажет теперь тестирование на большом промежутке времени.

3 мс это много. Но слишком много неизвестных, чтобы однозначно сказать кто вносит такие задержки. Нужно отсекать всё лишнее, например, запустить только графику без устройств ввода и т.д. Отрисовку графики и работу пользовательского приложения нужно максимально разнести с процессом/потоком отправляющим данные в сеть и крайне внимательно проверять все места где может быть взаимная блокировка. Приоритет безусловно нужно выставлять выше для того потока/процесса, которому критично время отправки.

Со своим образом вряд ли получится работать, так как если сейчас все будет удачно, придется использовать вашу сертифицированную МОРФ систему, а там насколько я понимаю различные правки параметров запуска и так далее недопустимы. Но это следующий этап)

Возможность собирать свой образ и менять набор запускаемых драйверов и программ остаётся.