Что-то с определением частоты процессора.

Internal structure and you change requests/suggestions
  • GerdtR
    частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
    транк-ядро до сих пор определяет частоту ЦП по тикам RTC, через жо 61-й порт.

    лучше пользоваться таймером реального времени.
    а еще лучше - прочитать настройки PLL напрямую из MSR (правда, где они там на селеронах - не знаю).
  • GerdtR wrote:Ах, да. На старой сборке вновь появилась загрузка OS/IDLE в 102%. Раньше У меня было ядро SVN 3270. Если надо, то могу и на нём посмотреть. На том ядре у меня тоже всё в норме было.
    Желательно методом исключения проверить промежуточные сборки. Берем среднюю ревизию и проверяем, далее корректируем (в зависимости от получившегося результата одно из крайних значений) номер ревизии и снова берем среднее значение. Так пока не найдется ревизия, предположительно вызвавшая проблему.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Попробую проверить сборки. Хотя с моим инетом это не очень быстро. Потому ждать придётся больше.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.
    Проверь еще раз - в этих ревизиях trunk ядро не менялось, а приложения правились совсем уж отношения не имеющие.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Полная ерунда. Сейчас и 3005 неверный результат показала. Скорее всего art_zh прав. Комп почищу, может вообще проблема исчезнет.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • Если это глюки RTC, тогда у тебя под виндой должно скакать системное время.
  • Пока надо разобраться со 101% в проге cpu. С частотой процессора и раньше были странные глюки

    viewtopic.php?f=1&t=617&p=18673&hilit=CPUID#p18673
  • В чём разбираться? Что тут непонятного?
    Показатели частоты процессора и использования процессора Колибри берёт из тиков TSC, часть тиков уходит в SMM на работу BIOS, из-за этого замеряемое количество тиков больше того, которое реально потрачено. Это относится и к частоте процессора, и к количеству тиков в секунду на программу, причём они замеряются в разное время и, соответственно, по-разному увеличиваются; в зависимости от коэффициента увеличения программа может получать и 101% от измеренной тактовой частоты, и 87% от неё же.
    Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
    Сделаем мир лучше!
  • CleverMouse wrote:Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
    А почему на большинстве компьютеров всё ОК и без ACPI? Там BIOS не такой наглый просто?
  • Почистил комп. Проблема исчезла.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • И 101% тоже.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • CleverMouse wrote:Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
    BIOS тут нипричем - это нормальная девиация частоты.
    Пикоамперный генератор очень чувствителен к любым паразитным сигналам. Села пылинка на контакт - уже емкость резонатора изменилась. А если это целый шмат пыли, да еще и обдуваемый вентилятором?

    И ACPI тут ничем не поможет - все равно прерывание по времени завязано на тот же генератор, а значит нестабильность периода IRQ будет те же десятки-сотни микросекунд.

    Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
    Еще лучше APIC-таймер в самом процессоре.
  • art_zh wrote:Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
    Еще лучше APIC-таймер в самом процессоре.
    HPET/APIC не во всех поддерживаемых Колибри процессорах есть.
  • Who is online

    Users browsing this forum: No registered users and 5 guests