Re: Аппаратные таймеры в unix
linux-2.6/Documentation/hpet.txt
http://www.google.ru/search?q=hpet
http://www.google.ru/search?q=hpet
Если нужен просто секундомер, а будильник не нужен, то под IA32/AMD64
После этого в ticks — количество тактов процессора, прошедших с момента последнего RST (mod 2^64).
Обычно используется разница в количестве тиков, которые выдаёт rdtsc в разных местах программы.
Перевести эту разницу в секунды (с долями) можно поделив её на частоту процессора (grep Hz /proc/cpuinfo если она не менялась в промежутке между вызовами rdtsc.
Кроме того, обычно достаточно только младшей части:
Если разница между двумя событиями > 2^32 тактов (~1 сек при частоте 4GHz то в промежутке наверняка было переключение задач и точность измерения уже никакая. Количество тактов на вызов самой инструкции может быть на данном процессоре довольно велико (порядка ста оно разное для разных процессоров. (Я обычно прогоняю два rdtsc подряд и вычитаю разность их показаний из всех остальных замеров.)
uint32_t h;
uint32_t l;
uint64_t ticks;
asm volatile ("rdtsc" : "=d" (h "=a" (l;
ticks = l;
ticks <<= 32;
ticks |= h;
После этого в ticks — количество тактов процессора, прошедших с момента последнего RST (mod 2^64).
Обычно используется разница в количестве тиков, которые выдаёт rdtsc в разных местах программы.
Перевести эту разницу в секунды (с долями) можно поделив её на частоту процессора (grep Hz /proc/cpuinfo если она не менялась в промежутке между вызовами rdtsc.
Кроме того, обычно достаточно только младшей части:
uint32_t ticks;
asm volatile ("rdtsc" : "=a" (ticks) : : "edx");
Если разница между двумя событиями > 2^32 тактов (~1 сек при частоте 4GHz то в промежутке наверняка было переключение задач и точность измерения уже никакая. Количество тактов на вызов самой инструкции может быть на данном процессоре довольно велико (порядка ста оно разное для разных процессоров. (Я обычно прогоняю два rdtsc подряд и вычитаю разность их показаний из всех остальных замеров.)
насколько я помню, переключение задач происходит не реже, чем раз в 10 нс
эт я так понимаю используется таймер cmos,правельно?А насчет других таймеров?
10 нсЭто ты загнул.
Кроме того, если больше нет желающих, то чего переключать-то?
Покупай плату времени, будут и другие.
это у кого как
linux:
* Minimum timeslice is 5 msecs (or 1 jiffy, whichever is larger
* default timeslice is 100 msecs, maximum timeslice is 800 msecs.
это максимальное время которое может работать процесс без переключения
у винды, по слухам, оно 20мс
linux:
* Minimum timeslice is 5 msecs (or 1 jiffy, whichever is larger
* default timeslice is 100 msecs, maximum timeslice is 800 msecs.
это максимальное время которое может работать процесс без переключения
у винды, по слухам, оно 20мс
очепятался 
Прерывание по таймеру всё равно запускается каждые 20 мс. Просто если переключать не на что, ничто и не переключается.
Прерывание по таймеру всё равно запускается каждые 20 мс. Просто если переключать не на что, ничто и не переключается.
> linux:
> винды
причём тут сабж?
> винды
причём тут сабж?
насколько я помню, переключение задач происходит не реже, чем раз в 10 нснс ?
Частоту переключениz задач определяет переменная HZ
а тебе какая точность времени нужна?
эт я так понимаю используется таймер cmos,правельно?А насчет других таймеров?
Нет, не правильно.
Писал же:
После этого в ticks — количество тактов процессора, прошедших с момента последнего RST (mod 2^64).
Другими словами — в процессоре есть счётчик, который увеличивается на единицу каждый такт. Этот счётчик и возвращается в паре регистров EDX:EAX инструкцией процессора rdtsc (ReaD Time Stamp Counter).
То есть измерение проводится с точностью частоты процессора, в обычной системе (без специальных плат таймеров) это максимальная точность измерения интервалов времени.
Максимальная теоретическая точность таймера CMOS — 1/65535 секунды, точность rdtsc ~10^(-7) секунды на современных процах (определяется частотой процессора, не порядка 10^(-9) потому что сама инструкция rdtsc жрёт около ста тактов).
Большинство hr-таймеров основывается на инструкции rdtsc (или аналогичной для конкретной процессорной архитектуры) и знании частоты процессора.
насколько я помню, переключение задач происходит не реже, чем раз в 10 нс
И я том, что чаще чем раз в секунду.
Перевести эту разницу в секунды (с долями) можно поделив её на частоту процессораКак насчёт процессоров, частота которых может изменяться в несколько раз?
Как насчёт процессоров, частота которых может изменяться в несколько раз?если речь идет не об x86 архитектуре, то вопрос не в тему
у тебя есть пример процессора, у которого частота меняется чаще чем переключаются задачи?
Можно придумать случаи, когда твоя задача будет достаточно редко включаться (ожидание ввода-вывода, например). А при этом частота процессора может меняться. В ноутбуках особенно, это не такое уж и редкое явление.
Как насчёт процессоров, частота которых может изменяться в несколько раз?
Мои посты внимательно читал?
Перевести эту разницу в секунды (с долями) можно поделив её на частоту процессора (grep Hz /proc/cpuinfo если она не менялась в промежутке между вызовами rdtsc.
Можно придумать случаи, когда твоя задача будет достаточно редко включаться (ожидание ввода-вывода, например). А при этом частота процессора может меняться. В ноутбуках особенно, это не такое уж и редкое явление.
Если у тебя были переключения между задачами в промежутке между двумя rdtsc, то разница в их показаниях связана с погодой на Марсе гораздо больше, чем с характеристиками кода твоей задачи.
Так что менялась в этом промежутке частота процессора или нет — будет уже не важно.
Кстати, если стоит задача замера времени, а не количества тиков процессора, то куда проще использовать gettimeofday (цена деления — 1 микросекунда). Тем более, что это ещё и переносимо.
Это сейчас оно так редко переключается, но ты же не можешь гарантировать, что завтра будет то же самое. Потом замеры времени могут быть растянуты достаточно сильно - зависит от задачи. По-любому, завязываться на частоту процессора - плохая идея.
Это сейчас оно так редко переключается, но ты же не можешь гарантировать, что завтра будет то же самое. Потом замеры времени могут быть растянуты достаточно сильно - зависит от задачи. По-любому, завязываться на частоту процессора - плохая идея.
Ты видимо не совсем понял. Я не использую rdtsc для измерения времени и никому не совету, так как для этого есть более удобные и переносимые способы. Я использую его для того, чтобы измерить количество тактов процессора, которое исполнялся определённый участок кода программы.
То есть я использую её вроде секундомера в гонках. А не вроде настенных часов или будильника.
Для меня, если произошло переключение задач между запуском такого "секундомера" и его остановом — то мне уже плевать на его показания. Они испорчены и уже ни о чём не говорят. Поэтому я использую его на относительно небольших участках программы, делаю серию измерений и откидываю слишком большие показания. Так что, лично меня смена частоты процессора при использовании rdtsc вообще никогда не волновала. Для измерения достаточно долгих промежутков времени и снятия показания wall clock я использую gettimeofday.
Я лишь сказал, что оценить в понимании wall clock промежуток измеренный с помощью rdtsc можно поделив их разность на частоту процессора, если она не менялась между вызовами rdtsc.
Кроме того, я отметил, что в современных ОС high-resolution таймеры часто основываются на подобных инструкциях (в других архитектурах, например Sparc, тоже есть программно доступные счётчики тактов процессора). А у ОС проблем с изменением частоты процессора не возникает — они меняют её сами и учитывают это в реализации hr таймеров.
Дело не в этом - ты говоришь, что так делать не советуешь, но при этом это как раз советом и было. На что я сказал, что так делать не советую. В общем мы об одном и том же, фактически. 
Оставить комментарий
Demech_D3
какие есть и как с ними работать.Или хотя юы помогите расшифровать" Например tsc на Intel,AMD доступ: rdtsc инструкция hpet доступ по /dev/hpet (mmap'иш файл парсишь соотв. структуру) и дальше по списку PIC/RTC APIC CMOS ACPI/PM Clock ""