Board.KolibriOS.org

GerdtR wrote:В старой сборке проблема пропала. Обычная частота в 2143. Akyltist, ваша последняя прога всегда показывала 2143. И на старой и на новой сборке. Скорость проги заметно увеличилась.

Очень хорошо. Будет замечательно, если ты сможешь протестировать выборочно несколько сборок, пока не найдёшь, в какой из них появилась проблема.

GerdtR
частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
транк-ядро до сих пор определяет частоту ЦП по тикам RTC, через жо 61-й порт.

лучше пользоваться таймером реального времени.
а еще лучше - прочитать настройки PLL напрямую из MSR (правда, где они там на селеронах - не знаю).

GerdtR wrote:Ах, да. На старой сборке вновь появилась загрузка OS/IDLE в 102%. Раньше У меня было ядро SVN 3270. Если надо, то могу и на нём посмотреть. На том ядре у меня тоже всё в норме было.

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

Попробую проверить сборки. Хотя с моим инетом это не очень быстро. Потому ждать придётся больше.

В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.

GerdtR wrote:В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.

Проверь еще раз - в этих ревизиях trunk ядро не менялось, а приложения правились совсем уж отношения не имеющие.

Полная ерунда. Сейчас и 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 не во всех поддерживаемых Колибри процессорах есть.