Кстати да.
Если вас устраивает текстовый лог, то воспользуйтесь сислогом. В программе на С есть функция записать строку в сислог, а в конфигурации сислога укажите файл куда писать эти специфические сообщения. Довольно просто и стандартно. Можно параллельно еще на удаленный компьютер посылать сообщения и там сислогом их записывать. Можно даже и не писать программу, а из скрипта посылать сообщения в сислог.

"Все уже украдено до нас" (С)

Озадачился работой таймеров в Линуксе. Погуглил, понял следующее. У компа есть микросхема таймера, при переполнении которого генерятся прерывания. Частота прерываний у линукса приблизительно 1кГц , то есть каждую миллисекунду. В промежутках между обработчиками прерываний, процессор выполняет задачи процесса, который ему подсунул в данный момент планировщик Линукса.

В обработчике прерывания, кроме всего прочего проверяются состояния созданных таймеров. Если обработчик увидит, что период того или иного таймера истек, то процессу, в котором был создан этот таймер будет послан сигнал (signal). Процесс, узнает о том что ему послан сигнал только когда дойдет очередь его выполнять. Если всё так то вопрос. Допустим, я создал таймер, который должен генерить сигнал каждые 50мс. Я могу быть уверенным, что этот сигнал будет послан процессу ровно через 50 мс (неточность системного тика и время выполнения самого обработчика опустим). Но как оценить когда мой процесс узнает что сигнал ему послан и начнется выполнение функции, привязанной к этому сигналу ?


Может я чё та не правильно понял, поправьте если что плз.


Спасибо.

Upd: Вот тут http://otvet.mail.ru/question/86575120 товарищ утверждает что квант времени выделяемый на каждый процесс в Линуксе = 1/300с Это 3.3мс! То есть если у меня в Линуксе крутятся последовательно 10 процессов то я дождусь начала выполнения функции, связанной с выставленным сигналом через 50+(10*3.3) = 83мс, вместо 50 !?

Upd2: проверил таймер с периодом 50мс. Всё четко отрабатывает. Значит я чего то не понимаю, как оно устроено. Либо товарищ ошибся с квантом времени процесса

Сообщение отредактировал berkl - Oct 17 2013, 08:53

В Линуксе столько разных концепций времени. Насколько я знаю базовой единицей являются jiffies. Оно в каждой конкретной системе калибруется на время. Есть системная константа, показывающая сколько jiffies в миллисекунде. Сдается мне что нет определенного периода вызова прерывания системного таймера. Так что может быть и 1 мС и 5мС и 10мС.

Я полагаю, что Линукс не настолько deterministic, что можно гарантировать время, через которое процесс начнет работу. Можно, например, запустить задачу с реал тайм приоритетом, что пока она активна никто не получит рессурса процессора.

Полагаю вам следует создавать процессы с реал-тайм приоритетом

http://stackoverflow.com/questions/8887531...iority-in-linux

http://www.cyberciti.biz/faq/howto-set-rea...iority-process/

http://www.linuxjournal.com/magazine/real-...ernel-scheduler

Сообщение отредактировал Tarbal - Oct 17 2013, 17:38

Прежде чем рассматривать таймеры, надо сделать несколько определений.

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

Так вот, выполнение шедулера/свитчера может происходить по многим причинам, как-то: окончание кванта времени треда, засыпание треда в ядре, возникновение некоторых событий, которое ждет тред, фаза луны (при определенной политике планирования) и пр. Тики системного таймера - один из источников таких событий, но не единственный. Более того, его вообще может не быть (tickless system, в линуксе CONFIG_NO_HZ*).

Как я понял, вы используете юзермодные POSIX таймеры (timer_create() etc) с доставкой сигнала по таймауту. При этом происходит примерно следующее: заводится ядерный таймер (не обязательно хардварный), по таймауту которого происходит прерывание. Обработчик этого прерывания посылает сигнал процессу, т.е. выбирает нужную нить и "будит" ее, после чего с ней разбирается шедулер в следующей точке решедулинга (например, при выходе из прерывания). Далее, нить в зависимости от текущего состояния, политики планирования, приоритета и пр. может пойти на выполнение - это решает планировщик. Ну и само переключение потом делает свитчер, тоже в определенный момент, не обязательно сразу.

В вашем примере 50мс выдерживались потому, что не было сильной загрузки, т.е. большинство тредов спали, вот ваш обработчик сразу и выполнился. Попробуйте запустить while (1); с высоким приоритетом (а лучше с RT-приоритетом <100) - времена поплывут.

Другие моменты, которые могут влиять на джиттер, связаны с доставкой сигналов:
1. POSIX требует, чтобы сигналы от таймеров и прочих io completion не терялись, поэтому используются так называемые realtime signals. Это означает, что сигналы складываются в хитрую приоретизированную очередь и доставляются в порядке приоритета (а внутри одного приоритета - в FIFO порядке).
2. Сигналы могут быть заблокированы.
3. Сигналы посылаются процессу, а выбор конкретной нити, которая их будет исполнять (единица планирования - нить) весьма нетривиален (хотя можно послать сигнал конкретной нити...).
4. Если выбранная нить мигрировала на другой CPU, отличный от того где выполняется прерывание от таймера, - пошлется IPI тому CPU на решедулинг, со всеми вытекающими.
И это только то, что я с ходу вспомнил.

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

И еще, при гуглении не читайте всякие ответы-мейл-ру. Википедия тоже не очень достоверна. Stack Exchange получше, но проигрывает статьям на lkml и официальной документации. А самый надежный источник - исходные коды + комментарии в них + common sense

Спасибо за ссылочки, поглядаю.




Вот тут http://rus-linux.net/MyLDP/BOOKS/Moduli-ya...-mod-06-10.html товарищ считает по другому:





Из сказанного видно, что период сработки системного прерывания (а вместе с ним и обработчика прерывания) жестко детерминирован и доступен для настройки. В контексте обработчика системного прерывания, кроме всего прочего, проверяется и не истекло ли выделенное время (квант) выполнения текущего процесса. Если время процесса истекло то прямо в обработчике прерывания запускается следующий процесс, текущий останавливается. Так что тут тоже всё детерминировано по времени. В чем же тогда недетерминированность Линукса? Я не знаю, но допускаю, что в том что не известно когда будет выполняться процесс у которого возникло какое-то событие. Взять хоть тот же сигнал от таймера в нашем процессе: таймер переполнился, ядро об этом узнает сразу, но процесс узнает об этом только когда подгрузится контекст этого процесса. А когда он подгрузится, фиг знает... В этом мне видится "нереальность времени" Линукса.

Устраню некоторую неопределенность во фразе:
"Сдается мне что нет определенного периода вызова прерывания системного таймера. Так что может быть и 1 мС и 5мС и 10мС."

Если в системе интервал 1 миллисекунда, то он всегда будет равен одной миллисекунде.
Если интервал в системе 10 миллисекунд, то он всегда будет 10 мС. Каким интервал является в каждой конкретной системе заранее сказать невозможно. Он может меняться от системы к системе.

Цитата:
"Но для большинства платформ для ядра 2.6 выбраны значения HZ=1000, что соответствует периоду следования системных тиков в 1 миллисекунду"
подтверждает мои слова.

Сообщение отредактировал Tarbal - Oct 17 2013, 18:59

Да забудьте вы про системный тик Это всего лишь дополнительный периодический источник событий. Его может вообще не быть. В линуксе такая опция появилась в 2.6.16-17 ядре, т.е. много лет назад. Не говоря про другие системы.

EDIT: вот неплохая отправная точка для гугления http://stackoverflow.com/questions/9775042...in-linux-kernel

Сообщение отредактировал vshemm - Oct 17 2013, 19:07

Спасибо за ответы, буду разбераться

Этот товарищ - Олег Цилюрик, на данном (и не только на данном) форуме известен под ником olej. ЕМНИП. Со всеми вытекающими.

Про tickless system я до конца не понял, но кажется так: допустим, планировщик решил, что ближайшие n секунд не запланировано к исполнению ни одного процесса значит надо усыпить процессор. Это не значит что системные прерывания (с частотой HZ) перестают генерится. Нет, они генерятся и проц просыпается всякий раз когда это происходит. Но почти сразу засыпает снова, определив что пока заняться нечем. Решил проверить как оно. Накидал примерчик с одним posix таймером, который истекает каждую секунду:



выполнил dim@dim-System-Product-Name:~$ top

Процессор не засыпает когда крутится эта программка, мешает уснуть while(1); наверное . Более того процесс создает нагрузку 100 и более(!) процентов! Как сделать так чтобы процессор спал, а не выполнял постоянно while(1); , впустую грея воздух ?




Отчасти не соглашусь. Хардварный таймер наверное вообще завести нельзя. Все, чем располагает ядро - это внешний сигнал прерывания который приходит он куда-то с предопределенной периодичностью (HZ). Откуда именно можно узнать набрав:

dim@dim-System-Product-Name:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
В моем случае это tsc - Time Stamp Counter.

Доступных источников периодических прерываний может быть несколько, у меня их 3:
dim@dim-System-Product-Name:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

Говорить " ...таймер (не обязательно хардварный), по таймауту которого происходит прерывание..." наверное неправильно. Прерывание (которое действительно прерывает, приостанавливает работу центрально процессора) присуще только хардварному таймеру, с его хардварным приоритетом и адресом в таблице векторов. Мне думается, когда истекает линуксовый таймер, ядро выставляет сигнал, флаг (вобщем какую та переменную) которая информирует процесс (или нить) об этом событии. Но назвать это прерыванием нельзя.
Остальное сказанное мне понятно и я согласен.

Спасибо.

Сообщение отредактировал berkl - Oct 21 2013, 13:33

Чтобы процессор заснул, надо сделать соответствующий системный вызов. Типа попросить занятый семафор. Их много. Вам подойдет sleep:
Для скриптов
http://en.wikipedia.org/wiki/Sleep_(Unix)
Для С
http://linux.die.net/man/3/sleep

Хардверный таймер завести можно. Однако таймеры ОС работают от одного и того же системного таймера, который инициализирован при старте кернела.


Сообщение отредактировал Tarbal - Oct 21 2013, 14:19

Согласен, таймеры ОС работают от одного системного таймера. Но системный таймер это ведь программный таймер, нет ?



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

Думается, хардвар заканчивается на обработчике прерывания do_timer(), железных таймеров нет. В do_timer() происходит jiffies++; ну а другие таймеры уже дальше на базе этого рабьотают

Как програмный таймер может измерять время? Кто-то должен инициировать прерывание через равные промежутки времени. Этим и занимается хардверный таймер.
Возникла путаница с терминологией. В процессоре (SOC) стоит несколько хардверных таймеров, которые можно использовать если надо. Я о них говорил. Один из них занят системой для измерения времени и все системные времена опираются на него.

Сообщение отредактировал Tarbal - Oct 21 2013, 17:26

Да, с терминологией путаница.



То есть системный таймер (он же хардверный) это микросхема. ОК. А счётчик считающий jiffies как называется ?



А если не SoC а обычный пентиум (я веду рассуждение в контексте этого случая)?

Сообщение отредактировал berkl - Oct 21 2013, 18:08

Есть один системный хардвер таймер и все временнЫе службы и системы измерения времени Linux равняются на него него. Думаю и jiffies тоже.



Раньше в PC ставили чип таймера 8053 или его производные. В SOC все внутри. Ставят штук 10 таймеров, в каждом capture/compare/PWM.