Возможно ли построить временную диаграмму пользуясь только шкалой времени получаемой по RDTSC? Насколько стабилен этот механизм? ЗЫ. Более подробно, зачем мне это надо и почему RDTSC, можно почитать вот здесь .
Что-то у меня от твоего вопроса мозги завязялись в трубочку... PS: Получается так что ты создал тему на другом форуме, заставляешь нас (пока меня) читать её смысл где-то в другом месте - ТАК НЕ ПОЙДЁТ.
Хорошо, постораюсь осветить здесь. Я пишу проект под QNX6 для x86. Задача стоит в получении штампа времени в прерывании. Для этого я хочу использовать инструкцию RDTSC. При старте программы я планирую получить текущее число набежавших циклов и ассоциировать его с текущим календарным временем. И далее по ходу выполнения программы не синхронизироваться с календарем, а отсчитывать временную диаграмму только по RDTSC. Использовать системный таймер не хочу, так как мне нужна дискретность отсчетов в 1 мкс. Для выше описанной ОС системный тик минимально можно поставить в 10мкс, но на Celeron 400 это губительно сказывается на производительности (большая часть времени уходит на обработку событий от таймера). Дело в том, что мое приложение не единственное и растрачивать ресурсы такими темпами я не могу. По умолчанию системный тик равен 1мс. Производительность вышеуказанного компа при таком тике меня устраивает. Почитав документации от Интел про RDTSC выудил, что они гарантируют стабильность частоты тика и настроек read time stamp counter'a в течении 10 лет после последнего reset'a. Как вы, уважаемые войны дзена, считаете возможно ли построение временной диаграммы базируясь только на RDTSC? Насколько такой механизм будет действительно стабилен?
В принципе идея неплохая, но могут быть погрешности не в rdtsc, а в приведении в секунды (или мс, почти без разницы). Ведь Вы получите не совсем точное, грубо говоря, цифровое отношение, для дальнейшего приведения. И потом чем дальше тем хуже. Будут накапливаться ошибки - сумма погрешностей, начиная с того времени, когда было получено отношение (или, по-другому, какой-то коэффициент). Вообщем, время будет точное, но до поры, до времени... Хотя лучше применить корректировку через час, чем через каждые 1000 мс читать новое значение времени. PS: "получить текущее число набежавших циклов" - лучше сказать тактов, и то, что rdtsc точное - это правда. Кстати, я не понял: "По умолчанию системный тик равен 1мс." - если такт равен 1 мс, то это не правда!!!
2 Vasil Я предпологаю сравниваться ВСЕГДА только с полученным в начале ЧИСЛОМ ТАКТОВ (не переведенным в секунды, миллисекунды, etc), а не с "последним замеренным" rdtsc. Приведу пример, как я НЕ БУДУ ДЕЛАТЬ. Раз в 1мкс (в ISR) получать значение rdtsc и сохранять его, а в следующее прерывание сравниваться со значением rdtsc, полученным в предыдущее. Вот в таком случае действительно ошибка приведения все время "капает"...Вы об этом говорили или нет? Я имел ввиду не процессор . Это я про тик, который устанавливает ОС, программируя аппаратный таймер i8253. Так, например, для WinXP системный тик ставиться по умолчанию равным 10мс. Для Linux(2.х) тоже 10мс. А в Досе по умолчанию был 55мс... А вы не в курсе как этот механизм работает на современных процах, например на которых можно процик в энерго сберегающий режим переводить? Как я понимаю частота при этом уменьшается, значить и счетчик будет тикать медленнее...
Не будет никакой погрешности. rdtsc связана с тактовой частотой процессора, и имеет ту же стабильность. Время будет не в мс, а в более мелких единицах, и надо будет рассчитать коэффициент, если нужно преобразовывать такты в традиционные единицы.
Еще по теме. 1. Мне самому нет необходимости высчитывания частоты процессора. Для этого уже есть готовая структура OS с данными. Ее состовляющая, содержит cycles per second, поэтому я и перевел как ЦИКЛЫ...возможно что более корректно сказать такты... 2. Каждый временной замер мне необходимо заносить в БД. Мне кажеться что как раз во избежании потерь нужно заносить ТАКТЫ, а ФПО на ходу будет уже брать "необходимое" округление...
2 cresta А если поставить двух процессорную машину. Счетчики процессоров будут тикать синхронно или будут расходиться? Число тактов с начала reset'a у них будет одинаковое или один из процессоров будет поперед другого? ЗЫ. Естесественно считая, что процессоры одинаковые по частоте и серии.
Если один остановился и стоит - другой естественно будет впереди Но вряд ли это тебе будет помехой: если первый запрос rdtsc получил данные от первого проца, то и последующий должен получить от того же, иначе весь смысл rdtsc теряется. Так что чисто логически должно совпадать. Экспериментально проверить не на чем.
Длительность такта - величина постоянная. Если процы одинаковые, то может один и будет поперед другого (это зависит от материнки), но разница будет одинаковой. RDTSC отлично подойдет для замеров с точностью в 1 мкс. про энергосберегающий режим не знаю, но вероятнее всего тактовая частота не уменьшается.
cresta "Не будет никакой погрешности. rdtsc связана с тактовой частотой процессора, и имеет ту же стабильность." Я вроде русским языком написал: "могут быть погрешности не в rdtsc, а в приведении в секунды". > PS: ладно, проехали...
osDrummer > "..гарантируют стабильность частоты тика и настроек read time stamp counter'a в течении 10 лет после последнего reset'a" Ничего подобного Intel не гарантирует и гарантировать не может. Фраза "Intel guarantees, architecturally, that the time-stamp counter frequency and configuration will be such that it will not wraparound within 10 years after being reset to 0" означает не более того, что 64-битный TSC гарантированно не переполнится за 10 лет непрерывной работы - с таким же успехом можно было бы и 100 лет гарантировать Частота процессора получается умножением частоты системной шины на подстраиваемом генераторе. Поэтому ес-но стабильность TSC определяется стабильностью частоты системной шины и в итоге стабильностью задающего кварца. Для обычных ширпотребных (непрецизионных) кварцев кратковременная нестабильность составляет порядка 20-50 ppm = (2-5)*10^-5, а долговременная ~1-10 ppm. Это означает что при измерении интервалов в 1 сек за счет нестабильности частоты показания RDTSC могут различаться на ±20-50 мкс, а на 100 сек интервалах соответсвенно до 100 раз больше (±2-5 мс). Причем это СКО и реальные отклонения м.б. и меньше и больше. Разумеется эта нестабильность относится и к системному таймеру. А уж годится или не годится такая нестабильность для поставленной задачи - решать автору. Разумеется к нестабильности частоты генератора в принципе могут плюсоваться какие-то "внешние" нестабильности, обусловленные задержками генерации и обработки прерываний. В qnx-ах я не силен и ничего конкретного по этому поводу сказать не могу.
