Board.KolibriOS.org

Official KolibriOS board
It is currently Thu May 23, 2019 10:35 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 69 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
PostPosted: Thu Apr 18, 2013 2:23 am 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
GerdtR wrote:
В старой сборке проблема пропала. Обычная частота в 2143. Akyltist, ваша последняя прога всегда показывала 2143. И на старой и на новой сборке. Скорость проги заметно увеличилась.
Очень хорошо. Будет замечательно, если ты сможешь протестировать выборочно несколько сборок, пока не найдёшь, в какой из них появилась проблема.


Top
   
PostPosted: Thu Apr 18, 2013 2:24 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
GerdtR
частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
транк-ядро до сих пор определяет частоту ЦП по тикам RTC, через жо 61-й порт.

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


Top
   
PostPosted: Thu Apr 18, 2013 2:26 am 
Offline
Kernel Developer

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

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Thu Apr 18, 2013 2:32 am 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
Попробую проверить сборки. Хотя с моим инетом это не очень быстро. Потому ждать придётся больше.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Thu Apr 18, 2013 3:10 am 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Thu Apr 18, 2013 3:32 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
GerdtR wrote:
В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Thu Apr 18, 2013 3:35 am 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
Полная ерунда. Сейчас и 3005 неверный результат показала. Скорее всего art_zh прав. Комп почищу, может вообще проблема исчезнет.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Thu Apr 18, 2013 10:10 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
Если это глюки RTC, тогда у тебя под виндой должно скакать системное время.


Top
   
PostPosted: Thu Apr 18, 2013 1:00 pm 
Offline

Joined: Wed May 18, 2005 7:27 pm
Posts: 1001
Пока надо разобраться со 101% в проге cpu. С частотой процессора и раньше были странные глюки

viewtopic.php?f=1&t=617&p=18673&hilit=CPUID#p18673


Top
   
PostPosted: Thu Apr 18, 2013 3:11 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
В чём разбираться? Что тут непонятного?
Показатели частоты процессора и использования процессора Колибри берёт из тиков TSC, часть тиков уходит в SMM на работу BIOS, из-за этого замеряемое количество тиков больше того, которое реально потрачено. Это относится и к частоте процессора, и к количеству тиков в секунду на программу, причём они замеряются в разное время и, соответственно, по-разному увеличиваются; в зависимости от коэффициента увеличения программа может получать и 101% от измеренной тактовой частоты, и 87% от неё же.
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Thu Apr 18, 2013 3:20 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
CleverMouse wrote:
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.
А почему на большинстве компьютеров всё ОК и без ACPI? Там BIOS не такой наглый просто?


Top
   
PostPosted: Thu Apr 18, 2013 4:24 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
Почистил комп. Проблема исчезла.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Thu Apr 18, 2013 4:31 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
И 101% тоже.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Thu Apr 18, 2013 7:49 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
CleverMouse wrote:
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.

BIOS тут нипричем - это нормальная девиация частоты.
Пикоамперный генератор очень чувствителен к любым паразитным сигналам. Села пылинка на контакт - уже емкость резонатора изменилась. А если это целый шмат пыли, да еще и обдуваемый вентилятором?

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

Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
Еще лучше APIC-таймер в самом процессоре.


Top
   
PostPosted: Thu Apr 18, 2013 7:56 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
art_zh wrote:
Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
Еще лучше APIC-таймер в самом процессоре.
HPET/APIC не во всех поддерживаемых Колибри процессорах есть.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 69 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: dunkaist and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited