Точное определение частоты CPU

В книжке Шрайбера сказано, что 00000000h - 1FFFFFFFh отображены на 80000000h - 9FFFFFFFh - читаю 800F0000h - сигнатуры SMBIOS ("_SM_") там нет в чём трабл?

 

трабл в том, что по по этим адресам биоса нету. Ещё в том, что шрайбер делал акцент на w2k и вряд ли последнего билда. Проще набери в айсе phys помоему и глянь на какие виртуальные адреса мапится физическая память с нуля. Тебе проще пройтись самостоятельно по каталогам страниц и посмотреть что куда промаплено. Но биос в виртуальной памяти точно есть. и как минимум по 3м адресам, сколько раз сам смотрел.

 

k3internal
А как вообще каталог страниц потрошить, есть примерчик?
В cr3 вроде адрес каталога и чё с ним делать?

mov EDI, cr3, mov EAX, [EDI]

 

mr_Infern0
Почитай доки хотя бы, сам всё поймешь.

 

n0name
Да где их взять-то гугл ничего путного не выдаёт?..

 

mr_Infern0
Intel, на васме про PM.

 

n0name
Читал уже, там в примерах с каталогом страниц играются до перехода в PM, что-же мне в WinXP врубить RM, прочитать каталог затем снова PM врубить - что-то сомневаюсь что это будет работать.

 

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

 

n0name
В виндах каталог страниц должен быть промапплен где-то в виртуальной памяти (cr3 используется в RM при поготовке к врубанию PM дальше его никто не юзает), тока вот где?

 

mr_Infern0
не говори чушь, CR3 изменяется при каждом переключении задач
и первый раз устанавливается не из RM, а из PM

 

Код (Text):

1.     mov eax, cr3
2.     and eax, 0xFFFFF000
3.     call <что-то, что дает возможность получить виртуальный адрес по физическому>

 

rei3er

Кстати да, просто я имел ввиду примеры из статей "Камни Intel в PM" с васма.

<что-то, что дает возможность получить виртуальный адрес по физическому>
MmGetVirtualForPhysical штоли?!
Пасиба за помощь, с SMBIOS кажется разобрался!..

 

> Вот код, считающий такты процессора, запускать в КМ
> ....
> pushfd
> cli // застопорить прерывания
> ...

Гы-гы-гыыы... Вспоминаю от мертвого осла уши... %-)

 

Dr.Golova
Не могу понять, по какому поводу ржач?

cli поставьте перед меткой _R_, так будет точнее. Какой у тебя вариант боле мене универсально замерить частоту проца? И получить близкий к правде результат. Так, вот, другова варианта нет.

 

Мало ли кому будет актуально. Частота отлично меряется с использованием пары PIT/rdtsc. Частота PIT фиксирована, 1193182 Hz. Насколько я понимаю, есть он во всех системах, включая достаточно древние.
Читаем счетчик PIT (обычно канал 0, с другими каналами ОС не всегда дает развлекаться), читаем TSC. Далее подождали немного, например, тактов 1000 PIT (в такую задержку хорошо укладываются как 75MHz-антиквариат, так и огромные частоты, подсчитать которые у меня сейчас башка не варит, пятница все-таки). Снова замерили TSC, а далее пропорция: разницу полученных TSC умножаем на частоту PIT и делим на разницу PIT (в нашем случае это 1000). Получили частоту, причем довольно точно.
Если этого мало, то можно дополнительно проделать многократные измерения (ибо одно измерение укладывается в 1 мс), укладывая их в таблицу, чтобы затем (нужное подчеркнуть):
1) найти значение с наибольшим рейтингом - на моем опыте дает самые близкие к реальности результаты;
2) найти мат. среднее всего этого хозяйства;
3) найти среднее квадратическое;
4) применить собственное фильтрующее и/или усредняющее ноу-хау.

Данный метод работает даже из 3-го кольца, погрешность +-10kHz макс. Более того, с погрешностью +-10MHz (в течение двух-трех секунд получения и жесткого отсева результатов измерений) это дело работает из-под VirtualPC. Ибо последний, похоже, "пропускает" через себя и rdtsc, и запросы к PIT (порты 40h и 43h для канала 0), получая их от хостовой машины и никак их не обрабатывая .
Если же реализовывать это в 0-м кольце... тогда наверное и 10 мс хватит на исчерпывающую информацию о частоте процессора. Никто и не заметит.
Могу скинуть пример кода, только он великоват...

P.S. А таймер CMOS - фуфло. Не знаю почему, но погрешность там велика.

P.P.S. А уж ждать целую секунду для получения лишь одного измерения и неизвестно еще насколько точного - увольте...

 

Ykidia

Под виндой QueryPerformanceХХХ + rdtsc нормально работают и при значительно меньших задержках
PS: На многоядерных процах для надеги можно аффинити-маск установить, чтобы tsc не скакнул

 

Ykidia
Частота PIT фиксирована, 1193182 Hz. - да нет, дружок. Пляска идет от системного генератора (14.318160 МГц), делится на 12 и получаем 1.193180 МГц. Вся прелесть в том, что кварц не имеет точно то значение, что выше написал + температура среды оказывает влияние на дрейф. Вывод - частоту ЦПУ нельзя замерить в системе точно, ибо нет эталона частоты/времени. А способ, описанный Вами давно реализован в матерях БИОС - один к одному.

 

Memphis

А об абсолютной точности тут видимо никто речи и не ведет, а погрешность ~10kHz это для гиговых процев как раз и есть порядок точности установки частоты генератора

 

Memphis

Не спорю, но это влияет на результат в порядка +-10kHz, о которых я писал выше.

Это Вы откуда взяли? Сами говорите, что кварц, и тут же плетете макароны о том, как сильно она влияет... Говорите тогда уже "RC-генератор", и всем будет понятно. В общем-то 1) насколько я знаю, PIT уже давно не в материнке сидит, а в микропроцессоре (поэтому там должен быть нормальный кварцевый генератор); 2) отклонение частоты кварцевого генератора предполагает 0.01%, а то и 0.001%.
Отклонения в частотах есть, все так, температура влияет, эталона в системе не было, нет и похоже не будет - и это тоже так, но не надо утрировать без меры. Данные отклонения, даже если сложить их всех вместе, ничтожно малы. Гораздо хуже, когда ОС решает что необходимо срочно сделать что-то важное, в результате чего все, что работает на 3-м кольце - отдыхает. Поэтому

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

Это радует, значит, этот способ не бред сумасшедшего. Хотя какая разница . Но почему-то в этой теме озвучено такого способа не было, вот я и привел.

Хотелось бы не просто пустой критики каких-то прозвучавших фраз, а конструктив. Данный способ стабильно позволял получить мне частоту всех опробованных мной машинах, в т.ч. на субноутах в режиме экономии батарей или в режиме "быстродействие по запросу" - вот конструктив.
А что в таких режимах будет с использованием Sleep? Это где-то уже обсуждалось.
Про CMOS тоже - он меня подвел по крайней мере на одной машине, а дальше я разбираться и его пользовать не стал. Хотя вроде часы реального времени. Вроде должны быть архиточными их секунды. Вроде.

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

Вот бы кто предложил еще способ измерения частоты вертикальной развертки. А то в системах с коротким сигналом вертикального гашения луча у меня иногда определяется в 2 или даже в 3 раза меньшая частота. Работаю также на 3-м уровне, ибо в 0 лезть не хочется - не всегда есть такая возможность.

P.S. Вопрос - как с помощью вызовов int 2Eh получить частоту высокоточного системного таймера и его текущее значение счетчика?

 

Memphis
Пляска идет от системного кварцевого генератора. 14,31818 МГц Но это еще мелочи дело в том что погрешность таймера порядка 30ppt -> 30 миллионных тоесть откуда получаем 14,318180±0,0004295454Мгц
Да и еще 14,31818 МГц Мгц- это рекомендуемая частота, а допустимая 14,318 Мгц. Это как раз для того, что бы в 30милионных влезть.

Есть, разница на 5 градусов дает ошибку порядка 5ppt

Стандартные частоты задаются точностью 3 или 5 знаков. Для 1Гц проца 5Мгц или 0,05Мгц
У моего проца 2,4Гц, в генератор забита константа 2404,хххМГц

Както странно вы порядок считаете. Вообще 14,31818 дает ошибку измерений порядка 6,98e-7 те ошибку в 7 знаке точность 6 порядков.
Это значит что, имея проц. 2,4ГГц ошибка будет примерно 2400±0,005Мгц

А 14,318 6,98e-5,а 4порядка,
Это значит что, имея проц. 2,4ГГц ошибка будет примерно 2400±0,5Мгц Собственно эта погрешность более реальная, если учесть что кварц имеет погрешность 30 миллионных - 4 порядка точных.

От этого системного кварцевого генератора. 14,31818 МГц получаются все частоту путем деления умножения плюс корректировка. Насчет корректировки вопрос открытый.
Еще есть второй кварц с частотой 32,768Гц от него напитывается RTC. Но промежутки им мерить можно только секундные, что лишает его хоть каких либо полезных свойств.

Точность стандартного кварцевого генератора 30-50 ошибок на миллион. А для генератора с корректировкой 6 ошибок на миллион. Точнее уже не бывают. Но и этого достаточно в сутках 86400 секунд для таймера с 30 миллионными будем иметь ошибку порядка 2,592с (реальные данные 3,5 с) Теперь понятно почему в старые времена таймер в компьютере убег или отставал? Сейчас незаметно, есть интернет и виндовс сам обновляет время.
Кварцевый генератор применяют потому, что его легко изготовить и он позволяет делать импульсы с регулярным промежутком нужной частоты и достаточно большой точности.

Что касается измерения? То я замеренную частоту пересчитываю на наиболее близкую к M/N*14,31818 N=3 M целая переменная. Это дает эталон времени.

Не только ОС есть еще SMI. Что более хуже, так как на некоторых материках он PIT корректирует.
Используя PIT можно прочитать значение его внутреннего счетчика и измерять RDTSC. А можно посчитать сколько раз сработало прерывание.

Так как все процессы случайны. То тут либо строить систему ошибок которые не предсказуемы и их легко не выбросишь. Либо пользоваться усредненными значениями. Лучше средний вариант с выбросом не корректных измерений.
Погрешностей много так вот средняя абсолютная величина погрешности пусть 1мс (10^-3 c) Для виндоуса, так и будет, так как точнее 1мс приложению на 3 кольце не получить. Получается, чтобы определить с точностью до 4 точных знаков. Нужно 10секунд хотите 5 порядков нужно дольше 100с.

Поэтому я меряю 1 секунду усредняю величины прерываний и делаю корректировку на наиболее близкую к M*14,31818/3.
1 секунды дает точность порядка 0,001 что для 4Гц дает ошибку ±4Мгц , что не превышает 14,31818/3=4,7МГц можно тем самым скорректировать.
Измерения выдают 2405,ххМгц, а дальше уже корректируются и за эталон берется 504/3*14,31818=2405,45424

Возможно стоит измерение увелечить до 2секунд.

Время определяю через мультимидийный таймер timeBeginPeriod(1) + timeGetTime ,так как Gettickcount дает ошибку порядка 15,25мс.