Очень хорошо. Будет замечательно, если ты сможешь протестировать выборочно несколько сборок, пока не найдёшь, в какой из них появилась проблема.GerdtR wrote:В старой сборке проблема пропала. Обычная частота в 2143. Akyltist, ваша последняя прога всегда показывала 2143. И на старой и на новой сборке. Скорость проги заметно увеличилась.
Что-то с определением частоты процессора.
GerdtR
частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
транк-ядро до сих пор определяет частоту ЦП по тикам RTC, черезжо 61-й порт.
лучше пользоваться таймером реального времени.
а еще лучше - прочитать настройки PLL напрямую из MSR (правда, где они там на селеронах - не знаю).
частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
транк-ядро до сих пор определяет частоту ЦП по тикам RTC, через
лучше пользоваться таймером реального времени.
а еще лучше - прочитать настройки PLL напрямую из MSR (правда, где они там на селеронах - не знаю).
Желательно методом исключения проверить промежуточные сборки. Берем среднюю ревизию и проверяем, далее корректируем (в зависимости от получившегося результата одно из крайних значений) номер ревизии и снова берем среднее значение. Так пока не найдется ревизия, предположительно вызвавшая проблему.GerdtR wrote:Ах, да. На старой сборке вновь появилась загрузка OS/IDLE в 102%. Раньше У меня было ядро SVN 3270. Если надо, то могу и на нём посмотреть. На том ядре у меня тоже всё в норме было.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Попробую проверить сборки. Хотя с моим инетом это не очень быстро. Потому ждать придётся больше.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Проверь еще раз - в этих ревизиях trunk ядро не менялось, а приложения правились совсем уж отношения не имеющие.GerdtR wrote:В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Полная ерунда. Сейчас и 3005 неверный результат показала. Скорее всего art_zh прав. Комп почищу, может вообще проблема исчезнет.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Если это глюки RTC, тогда у тебя под виндой должно скакать системное время.
Пока надо разобраться со 101% в проге cpu. С частотой процессора и раньше были странные глюки
viewtopic.php?f=1&t=617&p=18673&hilit=CPUID#p18673
viewtopic.php?f=1&t=617&p=18673&hilit=CPUID#p18673
В чём разбираться? Что тут непонятного?
Показатели частоты процессора и использования процессора Колибри берёт из тиков TSC, часть тиков уходит в SMM на работу BIOS, из-за этого замеряемое количество тиков больше того, которое реально потрачено. Это относится и к частоте процессора, и к количеству тиков в секунду на программу, причём они замеряются в разное время и, соответственно, по-разному увеличиваются; в зависимости от коэффициента увеличения программа может получать и 101% от измеренной тактовой частоты, и 87% от неё же.
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
Показатели частоты процессора и использования процессора Колибри берёт из тиков TSC, часть тиков уходит в SMM на работу BIOS, из-за этого замеряемое количество тиков больше того, которое реально потрачено. Это относится и к частоте процессора, и к количеству тиков в секунду на программу, причём они замеряются в разное время и, соответственно, по-разному увеличиваются; в зависимости от коэффициента увеличения программа может получать и 101% от измеренной тактовой частоты, и 87% от неё же.
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
Сделаем мир лучше!
А почему на большинстве компьютеров всё ОК и без ACPI? Там BIOS не такой наглый просто?CleverMouse wrote:Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
Почистил комп. Проблема исчезла.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
И 101% тоже.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
BIOS тут нипричем - это нормальная девиация частоты.CleverMouse wrote:Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
Пикоамперный генератор очень чувствителен к любым паразитным сигналам. Села пылинка на контакт - уже емкость резонатора изменилась. А если это целый шмат пыли, да еще и обдуваемый вентилятором?
И ACPI тут ничем не поможет - все равно прерывание по времени завязано на тот же генератор, а значит нестабильность периода IRQ будет те же десятки-сотни микросекунд.
Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
Еще лучше APIC-таймер в самом процессоре.
HPET/APIC не во всех поддерживаемых Колибри процессорах есть.art_zh wrote:Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
Еще лучше APIC-таймер в самом процессоре.
Who is online
Users browsing this forum: No registered users and 2 guests