Точность цикла потока и загруженность процессора

@Oleg_IT · Регистрация: 01.09.2009

Author24 — интернет-сервис помощи студентам

Создаю поток со стабилизацией времени цикла

C++

    int64_t CycleNS = 100000;
    
    while (ExitT == false)
    {
        StartTim = std::chrono::steady_clock::now();
 
        // .....;
 
 
        boost::this_thread::sleep_for(boost::chrono::microseconds(
                                          CycleNS - Duration(std::chrono::steady_clock::now() - StartTim).count()));
//        while (CycleNS - Duration(std::chrono::steady_clock::now() - StartTim).count() > 0 ){}
    }

В данной ситуации стабилизация цикла плохая, время цикла «прыгает» 100-110, иногда и 120 мс, но при этом загруженность процессора низкая ~0%. Если стабилизацию сделать на while, то будет наоборот, стабилизация очень хорошая и загрузка процессора >30%. Есть возможность совместить хорошую стабилизацию цикла и низкую загрузку процессора?

@Aledveu · 21.02.2024, 10:09

у вас ОС реального времени? скорее всего нет. так что вы можете добиться чего-то подходящего на вашем конкретном компьютере/ОС но на других компах/ОС будет другая ситуация.
ещё неизвестно как поведёт ваш цикл когда комп будет выполнять ещё какую-нибудь программу помимо вашей.

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

@Oleg_IT · 21.02.2024, 10:33 **[ТС]**

ОС-ы обычные Windows (разработка, тестирование...), Linux встроенная, штатная работа. Поток будет работать на отдельном ядре и общаться с аппаратурой.

@Aledveu · 21.02.2024, 11:53

Вот из-за того что на обычной ОС нельзя добиться стабильных задержек приходится делать дополнительные контроллеры - которые получают от компа некоторый минимальный объём информации чтобы они могли проработать пару секунд сами без участия компьютера, поскольку комп не сможет быстро отреагировать и выдать упавляющий сигнал.

Раз уш вы не хотите рассказывать что за аппаратура, какие требования по задержкам - период, джиттер и пр. Критичность задержек, как выдаётся управляющий сигнал - есть ли промежуточный драйвер который может решить что надо подсобрать данные и попозже отправить из пакетом и куча другой инфы. То ответы тоже будут очень пространными и обобщёнными.

Не забывает также что разрабатываете вы на современном компе - с хорошим быстродействием, а работать софт будет на самом слабом железе )))

@gray_fox · 17.04.2024, 01:59

Знаю, что тема немного старая, но я бы посоветовал вместо sleep_for использовать sleep_until с расчётом времени "просыпания" от начала первой итерации.

Момент следующего срабатывания при этом можно получить примерно так: next_activation = start + ((now() - start) / period + 1) * period.

Использование sleep_until вместо sleep_for позволит не спать дольше в случае, если поток может быть вытеснен ОС и он будет вытеснен после вычисления таймаута для sleep_for, но до самого sleepа.

Расчёт следующей активации от начала первого цикла нивелирует дрифт в периоде, если это важно.

Так же, если решите использовать sleep_until, то стоит посмотреть реализацию. Не знаю на счёт boost, но реализация из libstdc++, например, может использовать системное время для steady_clock.

Если можно использовать непереносимое API, то в Linux есть clock_nanosleep c CLOCK_MONOTONIC и TIMER_ABSTIME, или таймеры timerfd.

@Oleg_IT · 17.04.2024, 08:40 **[ТС]**

Спасибо, протестирую Ваши варианты.

@Aledveu 204 / 139 / 23 Регистрация: 26.11.2022 Сообщений: 629
	21.02.2024, 10:09	2
	у вас ОС реального времени? скорее всего нет. так что вы можете добиться чего-то подходящего на вашем конкретном компьютере/ОС но на других компах/ОС будет другая ситуация. ещё неизвестно как поведёт ваш цикл когда комп будет выполнять ещё какую-нибудь программу помимо вашей. ну и неплохо былобы написать зачем такое надо - особенно на какую стабильность вы расчитываете 0

@Oleg_IT 1 / 1 / 0 Регистрация: 01.09.2009 Сообщений: 133
	21.02.2024, 10:33 [ТС]	3
	ОС-ы обычные Windows (разработка, тестирование...), Linux встроенная, штатная работа. Поток будет работать на отдельном ядре и общаться с аппаратурой. 0

@Aledveu 204 / 139 / 23 Регистрация: 26.11.2022 Сообщений: 629
	21.02.2024, 11:53	4
	Вот из-за того что на обычной ОС нельзя добиться стабильных задержек приходится делать дополнительные контроллеры - которые получают от компа некоторый минимальный объём информации чтобы они могли проработать пару секунд сами без участия компьютера, поскольку комп не сможет быстро отреагировать и выдать упавляющий сигнал. Раз уш вы не хотите рассказывать что за аппаратура, какие требования по задержкам - период, джиттер и пр. Критичность задержек, как выдаётся управляющий сигнал - есть ли промежуточный драйвер который может решить что надо подсобрать данные и попозже отправить из пакетом и куча другой инфы. То ответы тоже будут очень пространными и обобщёнными. Не забывает также что разрабатываете вы на современном компе - с хорошим быстродействием, а работать софт будет на самом слабом железе ))) 0

@gray_fox What a waste! 1608 / 1300 / 180 Регистрация: 21.04.2012 Сообщений: 2,729
	17.04.2024, 01:59	5
	Знаю, что тема немного старая, но я бы посоветовал вместо `sleep_for` использовать `sleep_until` с расчётом времени "просыпания" от начала первой итерации. Момент следующего срабатывания при этом можно получить примерно так: `next_activation = start + ((now() - start) / period + 1) * period`. Использование `sleep_until` вместо `sleep_for` позволит не спать дольше в случае, если поток может быть вытеснен ОС и он будет вытеснен после вычисления таймаута для `sleep_for`, но до самого `sleep`а. Расчёт следующей активации от начала первого цикла нивелирует дрифт в периоде, если это важно. Так же, если решите использовать `sleep_until`, то стоит посмотреть реализацию. Не знаю на счёт `boost`, но реализация из `libstdc++`, например, может использовать системное время для `steady_clock`. Если можно использовать непереносимое API, то в Linux есть `clock_nanosleep` c `CLOCK_MONOTONIC` и `TIMER_ABSTIME`, или таймеры `timerfd`. 1

@Oleg_IT 1 / 1 / 0 Регистрация: 01.09.2009 Сообщений: 133
	17.04.2024, 08:40 [ТС]	6
	Спасибо, протестирую Ваши варианты. 0