sched_setaffinity...

https://acidborg.wordpress.com/2010/10/14/how-to-bind-a-process-to-a-specific...

во, интересная штука... надо бы для нее тесты нарисовать. благодарю))

pthread_setschedparam

pthread_setschedparam может быть с параметром SCHED_FIFO поможет. http://man7.org/linux/man-pages/man3/pthread_setschedparam.3.html

приоритет и настройки порядка выполнения - это не совсем то. Тут играет роль переключение контекста, а также то, когда это переключение будет доступно.

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

Но на данном процессоре будет не только ваш поток или нет? Т.е. кроме того что вы выделете под него отдельный процессор кроме того наверное необходимо и объяснить что его не нужно вытяснять или я что то не понял?

Для этого можно выставить affinity и остальным процессам. Проще всего отнять у всех остальных процессов любое/все ядра, кроме нулевого, через параметр ядра isolcpus=

affinity для остальных процессов звучит интересно. Т.е необходимо перечислить и отследить все fork и pthread? А если они создаются динамически? Я предлагаю использовать управление планировщиком для реализации RT. Кроме того будет возможность использовать ядро если нужная нить спит...

необходимо перечислить и отследить все fork и pthread? А если они создаются динамически

Просто прописываешь параметр ядра isolcpus=1-3, и больше ничего делать не нужно.

я выделяю не отдельный процессор, а ядро процессора. Тут лучше бы не путать терминологию. Важно то, что в определенные промежутки времени софтинушка моя, возможно, займет 100% процессорного времени, что нарушит правильность ВЧ потока. Кроме этой софтинушки на железе крутится только ядро линукса, так что при распределении потоков по ядрам процессора накладные расходы ядра линукса в теории нарушить работу ВЧ потока не должны.

Для этого я и предлагаю изменить приоритет процесса и изменить планировщик, т.к. как только Вашему более приоритетному потоку ВЧ потребуется поработать ему ядро передаст управление.Т.е. можно совместить выделение под вашу задачу отдельного ядра для балансировки и изменения подхода к планированию планировщика Linux.

Накладные расходы ядра linux это какие? Насколько тогда критично время отклика для ВЧ? Сколько выполняется ВЧ, а сколько спит? Сколько у Вас ядер, если можно отдать одно под отдельную задачу?

cgroups тоже умеет привязывать всю группу к конкретному cpu

Можно и taskset использовать https://www.opennet.ru/man.shtml?topic=taskset&category=1&russian=2.

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

возможно в будущем начнет ломать тайминги ВЧ потока

это вот говорит о том что какое-то фуфло затевается - тайминги твои без RT патча сломаться могут в любой момент из-за любого кривого драйвера

плюсую анонима, ощущение что тс подыскивает костылек под свое поделие

и да упомянутые здесь аффинити и цпусеты вылезли вовсе не из рт задач, а из нумы, и к тому же лет так несколько назад установленное аффинити «ломалось» если дернуть цпу хотплаг, думаю что и сейчас ничего не изменилось

Накладные расходы ядра linux это какие?

с ядром знаком поскольку постольку. Предположительно это прерывания процессора, планировщик потоков/процессов, менеджер памяти

Сколько выполняется ВЧ, а сколько спит?

Частота 500 Гц. Занимает примерно 30% периода.

Насколько тогда критично время отклика для ВЧ?

Не допускается потеря ни одного такта

Сколько у Вас ядер?

core i7 (1 проц, 4 физических, 8 логических)

Можно еще попробывать использовать SCHED_DEADLINE http://retis.sssup.it/~jlelli/talks/rts-like14/SCHED_DEADLINE.pdf http://elinux.org/images/b/b6/ELC2013-Kobayashi.pdf Вроде он даже в ядро вошел.

Частота 500 Гц. Занимает примерно 30% периода.
core i7 (1 проц, 4 физических, 8 логических)

если нужен Linux - ставь ядро с RT-патчем и все будет OK без всякой ерунды с выделенным процессором которую ты напридумывал

Не допускается потеря ни одного такта

это вообще нереализуемо в многозадачной многопроцессороной системе с кешами

тайминги твои без RT патча сломаться могут в любой момент из-за любого кривого драйвера

снова почитал про принцип работы RT ядра. Все-таки стоит с ним познакомиться, выглядит действительно наиболее подходящим решением.

Частота 500 Гц. Занимает примерно 30% периода. Не допускается потеря ни одного такта. core i7 (1 проц, 4 физических, 8 логических)

Вообще не проблема. Даже не надо привязывать к ядру процессора. Достаточно просто выставить приоритет реального времени.

Привязка к ядру процессора применяется тогда, когда нужна быстрая реакция - в пределах миллисекунды.

А вообще использовать комп общего назначения для системы реального времени - плохая затея. Какой-то левый обработчик прерывания, драйвер или сетевой протокол займет процессор прямо перед вами, и будет ненужная задержка.

Рассмотрите лучше использование микроконтроллера, например, STM32.

Вообще не проблема. Даже не надо привязывать к ядру процессора. Достаточно просто выставить приоритет реального времени.

Почему-то я не доверяю моментам, когда проц может просесть в 100% загрузку.

А вообще использовать комп общего назначения для системы реального времени - плохая затея
Рассмотрите лучше использование микроконтроллера

Безусловно Вы правы, однако есть некие сложности, в основном связанные со сроками и не совсем правильным взаимодействием. Поэтому приходится тыкать дерьмо палкой

Вот я очередной раз попробовал изменить приоритет и параметр потока (50/SCHED_FIFO) и в очередной раз эта фича меня огорчила.

Параллельно встала более интересная задача - есть два потока, в каждом из них висит udp.receive(), который принимает пакеты с частотой 25 000 Гц.

Для того, чтобы не было потерь, выставлены опции буфера сокета на 4МБ - вполне хватает за глаза, но!

нарисовал cpu_loader с регулировкой нагрузки ядер проца, чтобы смотреть на потери. Тело нагрузки примитивное

void load_function()
{
    std::cout << "Thread started\n";
    volatile double k = 10;
    volatile double j = 0.33;
    volatile double R = 1.0;
    while (isRun)
    {
        for(int i = 0; i <  1*1000*1000; ++i)
        {
            R = k / j;
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(load_delay_msec));
    }
    std::cout << "Thread finished\n";
}

нагрузку смотрю с помощью htop. В результате получил, что в промежутке с 50% до 70% загрузки ядер идут потери udp пакетов (большими пачками, возможно как раз этими 4МБ). Причем выставление приоритетов никак не повлияло на работу. Я тут как бы не понимаю, почему при 60% начинаются пропуски, а при 100% загрузке все ок? Какая-то хрень честно говоря

Можно еще попробывать использовать SCHED_DEADLINE

Можно. Довольно полноценная интересная презентация. Как-нибудь нужно будет разобрать по полкам все что в ней написано)) Благодарю!

Посмотрите pthread_getschedparam в этих патоках. М.б. set не отработал?

cat /boot/config-3.13.0-24-generic | grep IOSCHED или dmesg | grep scheduler что выдает?

М.б. set не отработал?

Это в первую очередь проверил. Все отработало

cat /boot/config-3.13.0-24-generic | grep IOSCHED или dmesg | grep scheduler что выдает?

На работе дефолтная ubuntu 14.04.1 стоит. Должно быть все в стоке. Единственное что - пришлось настроить сокеты в системе, чтобы можно было буферы для сокетов большие выставлять по данной статье. Все, более ничего не менялось

Как реализован опрос каждые 40 микросекунд? Если через nanosleep, то как мне кажется он не дает такого разрешения кажется 1 или 10 миллисекунд.

Внешняя ПЛИС тактирует

Я бы предложил вам открыть новую ветку, возможно будет больше участников т.к. данная ветка закрыта. Вопрос в том как вы делаете опрос 25 КГц насколько я понял в пространстве пользователя, т.е. вы в бесконечном цикле опрашиваете флаг или спите на дескрипторе(например ждете GPIO) или еще как? Опишите алгоритм работы. Используете ли неблокирующую работу с сокетами? Непонятно как связано чтение из сокетов в разных потоках и частота 25 КГц?