Таймер программно

← →
Defunct © (2004-11-09 21:15) [120]

Anatoly Podgoretsky © (09.11.04 21:07) [118]

А вот у меня эта цитата из help"a не работает. Включен D.O.T.

Да и что произойдет если мы будем отмерять короткий интервал и в этот момент произойдет аппаратное прерывание IRQ0 и какой-то другой поток получит управление? Что мы получим? Правильно - огрномную погрешность.

2 VMcL

Все же вникните в смысл написанного в [46] и [84].

← →
Ihor Osov'yak © (2004-11-09 21:18) [121]

> где именно я показал некомпетентность в тематике о приоритетах потоков?
см. [8], упорное игнорирование [9], притягивания за уши какого-то левого "аргумента" в форме процесса записи CD в [11], далее см. [21], я имею ввиду - "После чего вы приплели приоритеты потоков ядра" - отсюда видно, что вы не совсем представляете себе картину планирования потоков в комплексе (с учетом особенностей функционирования ядра) - далее мне искать лень. Но этого уже достаточно, чтобы сделать вывод, что вы не совсем точно представляете общую картину приоритетности потоков.

← →
Defunct © (2004-11-09 21:20) [122]

> The frequency cannot change while the system is running.

Чипуха все это, на практике опровегнуто. В MSDN D.O.T. не берется во внимание.

← →
Defunct © (2004-11-09 21:34) [123]

Ihor Osov"yak © (09.11.04 21:18) [121]

> см. [8],
смотрю и вижу - все в порядке (максимально возможный приоритет).

> упорное игнорирование [9]
С учетом того что [9] изначально некорректый пост, пришлось его проигнорировать (вы поправку указали только в [106])

> притягивания за уши какого-то левого "аргумента" в форме
> процесса записи CD в [11],

Вы в качестве примера программного опроса привели Host контроллер USB, что тоже не есть совсем удачный пример. Может быть и мне из-за этого построить какие-то выводы о вашей компетентности?

> см. [21], я имею ввиду - "После чего вы приплели приоритеты потоков ядра"
В [21] я вспилил, такой уж у меня характер. (но и там нет ничего неверного о приоритетах потоков) так как с моей стороны речь шла об аппаратном таймере (и приоритет потоков аппаратному таймеру абсолютно безразличен, будь-то поток режима ядра, будь-то поток пользовательского режима, а IRQ0 все равно тикает).

> что вы не совсем представляете себе картину планирования потоков в комплексе
Картину планирования я описал в [37] и [41], пост [70] был опубликов позже. Скажите вы не читали [37],[41] или проигнорировали?

За откровенность, спасибо.

← →
Ihor Osov'yak © (2004-11-09 21:59) [124]

> (вы поправку указали только в [106])

Поправка 106 абсолютно не меняет сути высказывания [9] по отношению контекста разговора. Суть высказывания - повышиние приоритетов потоков пользовательского режима даже до максимального значения проблемы непрогнозировемости задержек активации потока не решает, так как очень вероятно наличие потоков режима ядра с приоритетами либо вообще неподвласными планировщику, либо не позволяющие сделать активацию высокоприоритетного потока до своего завершения..

> Скажите вы не читали [37],[41] или проигнорировали?

37 - какой-то неудобочитаемый набор текста и псевдографики, наводящий на мысль, что вы не совсем владеете тематикой (как видно с картинки, вы почему-то рассматриваете "ядро" и остальные какие-то потоки в общей куче.. я, в общем то не телепат, чтобы угадывать что там зашифровано под понятием "ядро" - если настаиваете - я повторю свое определение - несете ахинею).
41 - в том же стиле.

← →
Ihor Osov'yak © (2004-11-09 22:11) [125]

>Вы в качестве примера программного опроса привели Host контроллер USB, что тоже не есть совсем удачный пример. Может быть и мне из-за этого построить какие-то выводы о вашей компетентности?

Снова искажение моих слов. Я говорил об обмене данными между хостом и перифирией. И не нужно проводить дискуссию в стиле "сам дурак" и спригывать с темы. Сейчас мы ведем разговор о приоритетах потоков.

> В [21] я вспилил, такой уж у меня характер.

это ваши проблемы. я вас уже раз поймал на лжи. Мне продолжать это увлекательное занятие?

> но и там нет ничего неверного о приоритетах потоков
там есть демонстрация вашего непонимания общей картины с приоритетами потоков с учетом ядра системы.

> так как с моей стороны речь шла об аппаратном таймере
в то время разговор ишел о влиянии повышения приоритета пользовательского потока на прогнозироемость задержек активации соотв. потока.

> и приоритет потоков аппаратному таймеру абсолютно безразличен, будь-то поток режима ядра, будь-то поток пользовательского режима, а IRQ0 все равно тикает).
а к чему этот пассаж? Снова попытка увести разговор в сторону?

← →
Ihor Osov'yak © (2004-11-09 22:16) [126]

кстати, вопрос на засыпку - является ли прерывание от системного таймера в нт-шных системах прерыванием с максимальным приоритетом?

← →
VMcL © (2004-11-09 23:08) [127]

>>Defunct © (09.11.04 21:15) [120]

>Все же вникните в смысл написанного в [46] и [84].

Продолжаете разводить демагогию? Ваше право. Или Вы меня действительно настолько тупым считаете? Вы прямо не ответили ни один мой вопрос, зато только то и делаете, что указываете, что мне следует читать и во что вникать, хотя сами вникать в то, что Вам говорят (точнее пишут), судя по всему, не намерены. Раз уж Вы пошли по такому пути, тогда я сделаю так же: перечитайте посты [94-96, 99, 102, 105, 112, 114-116, 118, 119, 120]. Можно несколько раз.

>Да и что произойдет если мы будем отмерять короткий интервал и в этот момент произойдет аппаратное прерывание IRQ0 и какой-то другой поток получит управление? Что мы получим? Правильно - огрномную погрешность.

Windows не является системой реального времени, так что без погрешности никак. Но вот "огромной" я бы её всё-таки не назвал.

← →
Anatoly Podgoretsky © (2004-11-09 23:13) [128]

Даже ДОС с включеной системой прерываний не является системой реального времени, все они логически отличаются отличаются только степень реакции, по другому погрешности.

← →
Defunct © (2004-11-10 02:39) [129]

Ihor Osov"yak © (09.11.04 21:59) [124]
> Поправка 106 абсолютно не меняет сути высказывания [9] по отношению контекста разговора.

Ваше мнение субъективно.
Потому что фраза:
>Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение.
Является верхом невежества по указанной вами тематике - приоритетов потоков. (я отдаю себе отчет в том что пишу, доказательство этого приведены в [90])

Фраза же:
В третих же - и это еще более существенно - все потоки пользовательского режима (даже если сделать SetPriorityClass + SetThreadPriority по максимуму) - по любому будут иметь ниже приоритет, чем потоки режима ядра, даже на самом захудалом уровне приоритетов...

противоречит иформации из DDK, кстати не вы ли ссылались на DDK позже?

Ihor Osov"yak © (09.11.04 22:16) [126]
> кстати, вопрос на засыпку - является ли прерывание от системного таймера в нт-шных системах прерыванием с максимальным приоритетом?

Из аппаратных прерываний от ВУ - ДА.
Есть еще прерывания возбуждаемые самим процессором к примеру (Devizion by zero), их приоритет выше чем IRQ0.

Anatoly Podgoretsky © (09.11.04 23:13) [128]
> Даже ДОС с включеной системой прерываний не является системой реального времени, все они логически отличаются отличаются только степень реакции, по другому погрешности.

Что я могу сказать на это, могу только улыбуться.
Прямо сегодня тестировал Real-time программу (ретранслятор телемеханики TCP -> Гранит) написанную под DOS для промышленного процессора Vortex86.

VMcL © (09.11.04 23:08) [127]
> Продолжаете разводить демагогию?
Это Вы продолжаете разводить демагогию. Я уже сказал, что я не намерен вести спор с вами непонятно о чем.

В общем я устал спорить с людьми которые в чужем глазу соринку видят, в своем не замечают и бревна.

← →
KilkennyCat © (2004-11-10 02:45) [130]

Я, не спец в таймерах... но с Анатолием соглашусь, ДОС не для реал-тайм. Однако, все зависит от требований... если погрешности допустимы, то почему бы и нет.
Сие познание из опыта работы с языком Ада.

← →
Defunct © (2004-11-10 03:03) [131]

Anatoly Podgoretsky © (09.11.04 23:13) [128]

Привожу код который превращает DOS real-time систему.

Procedure GetDivCoef; Var W : Word; R : Real; Begin HDB:=$17; LDB:=$4E; If BaudRate<>0 Then Begin R:=1193130.21/BaudRate; W:=Trunc(R); Fc:=Round((R-W)*1000); Sc:=1000-Fc; Asm Mov Ax,W Mov HDB,Ah Mov LDB,Al End; End; End; Procedure SetDplus;Assembler; Asm Mov Al,0 Out 43h,Al Mov Al,LDB Sub Al,1 Out 40h,AL Mov AL,HDB Sbb Al,0 Out 40h,AL End; Procedure SetDMinus;Assembler; Asm Mov Al,0 Out 43h,Al Mov Al,LDB Out 40h,AL Mov AL,HDB Out 40h,AL End;

Procedure IntControlHandler;Interrupt; Var I:Integer; Begin Asm PushA PushF Call Dword Ptr DS:[P08] ; Вызов старого обработчика Dec Acc Jnz @@WL1 { Коррекция времени } Cmp CurrentMode,0 Jz @@SetPlMode Mov CurrentMode,1 {} Mov Ax,Fc Mov Acc,Ax {933} Call SetDMinus Jmp @@WL1 @@SetPlMode: Mov CurrentMode,1 {} Mov Ax,Sc Mov Acc,Ax {500} Call SetDPlus
...
..

2 VMcL, Ihor Osov"yak
Попытайтесь лучше объяснить приведенный мной код, если не сможете, тогда лучше жевать (по тематике системного таймера и формирования точных отсчетов).

← →
Defunct © (2004-11-10 03:05) [132]

KilkennyCat © (10.11.04 02:45) [130]

DOS - real-time система,
сие познание из работы с телемеханикой уже много лет.

← →
Ihor Osov'yak © (2004-11-10 03:24) [133]

хм.
>Потому что фраза:
>>Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение.
>Является верхом невежества по указанной вами тематике - приоритетов потоков. (я отдаю себе отчет в том что пишу, доказательство этого приведены в [90])

Естественно, задержек на переключение потоков не уменшает. Это величина условно постоянная. Уменшается время ожидания получения кванта времени. Но эта составляящая не упоминалась, хотя бы потому, что от задержек на переключение увеличение приоритета по любому не избавиться.

кстати, что там в [90] доказывается?
ах, да -
>Что явно говорит от том, что при повышении приоритета потока будет сокращено время ожидания.

если мне память не изменяет, никто и не пытался этот тезис опровергнуть.
в частности, в [9] говорилось о том, времени переключения потоков, а не о времени ожидания кванта времени..что Вы не находите, что это несколько разные вещи?

> Фраза же: ...
> противоречит иформации из DDK, кстати не вы ли ссылались на DDK позже?

В какой части противоречит? Повторяю еще раз - некотороя неточность этой фразы, а именно, относительно "самого захудалого приоритета в режиме ядра" я скорректировал в 106, но упомянутая неточность не имеет значения в контексте рассмариваемого вопроса - ибо суть этой фразы - существует вероятность наличия потоков режима ядра с высшим приоритетом, чем поток пользовательского режима с максимально возможным пользовательским приоритетом - и следоваетально повышение приоритета пользовательского потока не решает проблему прогнозированности и сведения к минимуму ожидания кванта времени соотв. пользовательским потоком, который был в режиме ожидания.

>> кстати, вопрос на засыпку - является ли прерывание от системного таймера в нт-шных системах прерыванием с максимальным приоритетом?

>Из аппаратных прерываний от ВУ - ДА.
>Есть еще прерывания возбуждаемые самим процессором к примеру (Devizion by zero), их приоритет выше чем IRQ0.

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

>Что я могу сказать на это, могу только улыбуться.
Вместо улыбки было бы полезнее посмотреть на определение системы реального времени.

> Прямо сегодня тестировал Real-time программу (ретранслятор телемеханики TCP -> Гранит)

я тоже знаю много страшных слов..

Кстати, я так и не дождался расшифровки крякозябликов из [37],[41]... Особенно интересует упоминаемое там загадочное "ядро"...

> В общем я устал спорить с людьми которые ...
а предмета спора пока еще и не было. Наблюдалось только подмена темы разговора, голосновные обвинения, уход от ответов на прямые вопросы..

← →
Defunct © (2004-11-10 03:49) [134]

> 37 - какой-то неудобочитаемый набор текста и псевдографики,

Ну что ж поделать, тяжело здесь нарисовать рисунок, Вы и так не нарисовали.

> это ваши проблемы. я вас уже раз поймал на лжи. Мне продолжать это увлекательное занятие?

Продолжайте, разница между нами лишь в том, что когда вы меня ловите, то я в отличие от Вас честен и признаю свою неправоту. Вы же до сих пор упроствуете и защищаете сказанную вами чушь в [9], и до сих пор не признали того, что вспыли на меня без повода.

>> и приоритет потоков аппаратному таймеру абсолютно безразличен, будь-то поток режима ядра, будь-то поток пользовательского режима, а IRQ0 все равно тикает).
> а к чему этот пассаж? Снова попытка увести разговор в сторону?

Пассаж?
Уважаемый, что Вы о себе возомнили. Я вам не "дите три лет" (С) чтобы так со мной разговаривать.

мои слова из [21]
Про что я специально переспросил в [8]. После чего вы приплели приоритеты потоков ядра в [9]. Соответственно я вам указал на неспособность аппаратных средств обеспечить точность 100нс даже для потоков ядра.

мои слова из [123]
> и приоритет потоков аппаратному таймеру абсолютно безразличен, будь-то поток режима ядра, будь-то поток пользовательского режима, а IRQ0 все равно тикает).

Где же тут пассаж? Где же перевод темы в другое русло? Вы что не можете сопоставить слова из [21] и [123]?

> но и там нет ничего неверного о приоритетах потоков
там есть демонстрация вашего непонимания общей картины с приоритетами потоков с учетом ядра системы.

Хватит уже, мне надоело выслушивать голословные утверждения. Вы что, телепат?

>> так как с моей стороны речь шла об аппаратном таймере
> в то время разговор ишел о влиянии повышения приоритета пользовательского потока на прогнозироемость задержек активации соотв. потока.

Может быть на вашей волне разговор шел о приоритетах, а я говорил об аппаратных средстах. Не надо здесь опять демонстрировать Ваши телепатические способности. Цитата из [21] приведена прямо в этом посте, ключевые слова выделены жирным, ГДЕ ТАМ ГОВОРИТСЯ О ПРИОРИТЕТАХ?

За откровенность, спасибо.

← →
Defunct © (2004-11-10 04:08) [135]

Ihor Osov"yak © (10.11.04 03:24) [133]
>>Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение.
> Естественно, задержек на переключение потоков не уменшает.

Конечно не уменьшает.

> Уменшается время ожидания получения кванта времени.

В [6] вы говорили, цитирую, о непрогнозированности задержки на переключение потоков. Что вы подразумевали под "непрогнозируемость задержек на переключение потоков". Вкладывали ли вы в эту фразу время ожидания до переключения или нет? Если да, тогда вы в посте [133] лжете, если нет тогда время задержек на переключение потоков вполне прогнозируемо и выходит - вы лжете в [6].

> В какой части противоречит? Повторяю еще раз - некотороя неточность этой фразы, а именно, относительно "самого захудалого приоритета в режиме ядра" я скорректировал в 106,

> Поправка 106 абсолютно не меняет сути высказывания [9] по отношению контекста разговора.

Наконец-то и я вас подловил, видите от частого повторения и вы проговорились. Дело в том что не бывает небольших неточностей, бывает либо корретность либо некорректность.

В общем вы можете продолжать выкручиваться, но я свою миссию считаю завершенной.

← →
Defunct © (2004-11-10 04:51) [136]

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

Здесь я соглашусь.
Хотя моя ошибка была в том, что я поддался на уловку. Чтобы я там не ответил вы бы все равно имели возможность дополнить список.

> Вместо улыбки было бы полезнее посмотреть на определение системы реального времени.

Улыбка становится шире ;>
Я вам могу подарить книгу "Архитектура вычислительных систем реального времени" "ВЕК" 2003 с подписью автора. Хотя вы ее и не заслуживаете.

> Кстати, я так и не дождался расшифровки крякозябликов из [37],[41]... Особенно интересует упоминаемое там загадочное "ядро"...

Я не буду для вас ничего расшифровывать. Человек, для которого я старался и рисовал эти рисунки и так все понял.

← →
Defunct © (2004-11-10 05:42) [137]

VMcL © (09.11.04 21:00) [115]

;)
Вы что действительно не понимаете о чем я говорю?

>> Ну и как можно соотнести эти величины или сравнить их друг с другом? Внимательно прочитайте [46] и [84]

>С чего Вы взяли, что я собираюсь что-то соотносить?

Вы же говорите, что это частота, а не попугаи, а одинаковые величины можно соотносить, не так ли?

3 579 545 Hz <---ЦИФРА ПРИВДЕННАЯ VMcL В [94]
Athlon XP 1800+ @ 1533 MHz
2 992 560 000 <--- ЦИФРА ПРИВЕДЕННАЯ VMcL В [99]
P4 @ 3 GHz w/HT

> Вы привели, так сказать, "правильное значение", сказав, что мое, оказывается, неправильное.

LOL! Вы меня уже до коликов довели!
Где же я приводил "правильные значения" и где же LOL я говорил что Ваше, оказывается неправильным?

Шутить изволите? Я написал рядом приведенные Вами величины и даже поставил номера постов из которых я их взял. Я вам целиком и полностью доверяю.

> А я Вам показал, что на разных процессорах таймеры, как это ни странно, совершенно разные.

Я уже написал в [84], что таймера в процессорах x86 от Intel нет. Это утверждение не было никем опровегнуто. Может быть в AMD и есть таймер, я никогда не использовал процессоры AMD ни дома ни на работе, поэтому я не знаю, что туда могли встроить. Но достаточно и одного примера с Intel: раз в нем нет таймера, тогда о каком таймере говорите Вы? И о чем вы хотите со мной спорить?

Сформулируйте четко ваши вопросы ко мне (если таковые еще имеются) и я постараюсь прямо на них ответить.

← →
VMcL © (2004-11-10 08:09) [138]

>>Defunct © (10.11.04 02:39) [129]

>Это Вы продолжаете разводить демагогию. Я уже сказал, что я не намерен вести спор с вами непонятно о чем.

Приведите, пожалуйста, сообщение или его номер, где я с Вами спорил.

>>Defunct © (10.11.04 05:42) [137]

>LOL! Вы меня уже до коликов довели!
Где же я приводил "правильные значения" и где же LOL я говорил что Ваше, оказывается неправильным?

См. [95]

>Я уже написал в [84], что таймера в процессорах x86 от Intel нет. Это утверждение не было никем опровегнуто. Может быть в AMD и есть таймер, я никогда не использовал процессоры AMD ни дома ни на работе, поэтому я не знаю, что туда могли встроить. Но достаточно и одного примера с Intel: раз в нем нет таймера, тогда о каком таймере говорите Вы? И о чем вы хотите со мной спорить?

Intel, вроде, считает по-другому. Поправьте меня, если я ошибся. В документации упоминается таймер:
A high resolution timer within the processor (such as, the local APIC timer or the timestamp counter).

>Сформулируйте четко ваши вопросы ко мне (если таковые еще имеются) и я постараюсь прямо на них ответить.

Я вообще-то ленив, то всё-таки повторю, потому что хотелось бы получить ответ.

1.
D: Вызываете не ту функцию. Мне QueryPerformanceFrequency "говорит" - 2.8Ghz.
V: Не ту? Это какую? Есть несколько функций QueryPerformanceFrequency?

2.
D: величина, возвращаемая QueryPerformanceFrequency, исчисляется в каких-то ничего не значащих попугаях

V: Frequency - частота. Что всё-таки в действительности возвращает эта функция в качестве параметра lpFrequency (для разных CPU, а не только Intel - ведь на Intel свет клином не сошелся, я думаю) и в каких единицах?

← →
VMcL © (2004-11-10 08:16) [139]

>>VMcL © (10.11.04 08:09) [138]

>A high resolution timer within the processor (such as, the local APIC timer or the timestamp counter).

С TSC разобрались, что не подходит вследствие DOT. А вот что насчет local APIC timer?

P.S. Кстати, насколько я понял, DOT - это фича системных плат, а не процессоров. СП с DOT могут изменять FSB, влияя, таким образом, и на частоту CPU (поправьте меня, если я неправ). Поэтому MS (ну и Intel) могут быть как бы "не в курсе" того, что QPF возвращает некорректные, с точки зрения разработчика ПО, значения.

← →
Defunct © (2004-11-10 09:22) [140]

1.
D: Вызываете не ту функцию. Мне QueryPerformanceFrequency "говорит" - 2.8Ghz.
V: Не ту? Это какую? Есть несколько функций QueryPerformanceFrequency?

Дело в том, что функции, которая бы возвращала частоту системного таймера (IRQ0) в Delphi нет. Работать с аппаратным таймером можно только на запись, соответственно просто нет возможности прочитать текущее значение делителя.

Вам не понравилась моя фраза:
>Граничное значение частоты канала таймера составляет 1.193180 Mhz при делителе = 1.

которая кстати взята из Tech help, flambeaux software inc. (C) 2000.

На что я вам пытался намекнуть в [95]
Defunct © (09.11.04 08:12) [95]
VMcL © (09.11.04 07:59) [94]

> Что я делаю не так?
Вызываете не ту функцию.
Мне QueryPerformanceFrequency "говорит" - 2.8Ghz.
Из чего делаю вывод эта функция возвращает частоту процессора, а не частоту канала таймера (который дергает IRQ0).

Я ответил на ваш вопрос 1?

2.
D: величина, возвращаемая QueryPerformanceFrequency, исчисляется в каких-то ничего не значащих попугаях

V: Frequency - частота. Что всё-таки в действительности возвращает эта функция в качестве параметра lpFrequency (для разных CPU, а не только Intel - ведь на Intel свет клином не сошелся, я думаю) и в каких единицах?

Frequency - частота, согласен.

Anatoly Podgoretsky © (09.11.04 21:07) [118]
lpFrequency
Points to a variable that the function sets, in counts per second, to the current performance-counter frequency.

Для меня в данном вопросе свет сошелся на Intel как на родоначальнике семейства x86.
Intel timestamp counter не является таймеров, и считает какие-то такты, которые при включенном D.O.T. ни о чем не говорят (для меня такая величина равносильна попугаям +- 1Ghz). Если серьезно подойти к вопросу формирования задержки (точной задержки) timestamp использовать нельзя из-за очень высокой погрешности (о чем я говорил в [84]).

Я ответил на ваш вопрос 2?

> А вот что насчет local APIC timer?
Я не работал с APIC таймером, если в нем предусмотрен механизм формирования аппаратного прерывания, тогда его можно использовать для формирования точного отсчета, если нет - тогда нельзя.

P.S. Кстати, насколько я понял, DOT - это фича системных плат, а не процессоров. СП с DOT могут изменять FSB, влияя, таким образом, и на частоту CPU (поправьте меня, если я неправ). Поэтому MS (ну и Intel) могут быть как бы "не в курсе" того, что QPF возвращает некорректные, с точки зрения разработчика ПО, значения.

Абсолютно верно. Вы как программист, должны понимать, что программист не может себе позволить не учитывать новые технологие лишь потому, что в MSDN о них не говорится. Поэтому надо учитывать и DOT.

Теперь о второстепенном.

>> Где же я приводил "правильные значения" и где же LOL я говорил что Ваше, оказывается неправильным?

>См. [95]

Я что где-то сказал, что приведенное мной значение есть "правильное значение" или, что приведенное вами значение есть "неправльное значение"?
В посте [95] я ответил на ваш вопрос "Что я делаю не так?" (в контексте определения частоты аппаратного таймера) и привел, то что вернула мне функция QueryPerformanceFrequency. А она вернула отнюдь не частоту аппаратного таймера.
(честно сказать не пойму зачем вы потом начали говорить о каком-то эксперименте "аж на одном компьютере") Какая разница на скольких компьютерах был проведен эксперимент, если результаты несовпадают значит эта функция возвращает какие-то ничего не значащие попугаи. (а не совпадают-то результаты по Вышим данным аж 3 порядка)

> Intel, вроде, считает по-другому. Поправьте меня, если я ошибся. В документации упоминается таймер:
> A high resolution timer within the processor (such as, the local APIC timer or the timestamp counter).

Откуда информация? Дайте, пожалуйста, название документа, который можно скачать с сайта Intel. (MSDN, DDK) не предлагать. Должен быть документ именно от Intel.

> Приведите, пожалуйста, сообщение или его номер, где я с Вами спорил.
Я очень надеюсь, что после прочтения Вами этого поста, этот вопрос отпадет.

← →
VMcL © (2004-11-10 10:45) [141]

>>Defunct © (10.11.04 09:22) [140]

>Вам не понравилась моя фраза:
>Граничное значение частоты канала таймера составляет 1.193180 Mhz при делителе = 1.

Не то, чтобы она мне именно не понравилась. Просто, вспомнив про high-resolution таймер, я решил проверить, что возращает QPF. Она вернула большее значение, поэтому я собственно и задал несколько провокационный вопрос, намекая, что есть более точный таймер.

>Из чего делаю вывод эта функция возвращает частоту процессора, а не частоту канала таймера (который дергает IRQ0).

Судя по справке, она и не должна возвращать частоту таймера выдающего IRQ0, а как раз некоторого другого "high-resolution performance counter". + См. тж. (*)

>Для меня в данном вопросе свет сошелся на Intel как на родоначальнике семейства x86.

Вы сами себе несколько противоречите. Смотрите, далее Вы пишете:
>Абсолютно верно. Вы как программист, должны понимать, что программист не может себе позволить не учитывать новые технологие лишь потому, что в MSDN о них не говорится.

Получается, что Вы не учитываете, что есть пользователи (причем их достаточно много), которые используют другие типы процессоров. А у них QPF/QPC работают так, как им и положено.

>В посте [95] я ответил на ваш вопрос "Что я делаю не так?" (в контексте определения частоты аппаратного таймера) и привел, то что вернула мне функция QueryPerformanceFrequency. А она вернула отнюдь не частоту аппаратного таймера.
(честно сказать не пойму зачем вы потом начали говорить о каком-то эксперименте "аж на одном компьютере") Какая разница на скольких компьютерах был проведен эксперимент, если результаты несовпадают значит эта функция возвращает какие-то ничего не значащие попугаи. (а не совпадают-то результаты по Вышим данным аж 3 порядка)

(*) Не забывайте, что у нас несколько разные платформы. Вполне возможно, что у новых процессоров Intel есть высокоточный таймер, работающий на (около)процессорной частоте.

>Откуда информация? Дайте, пожалуйста, название документа, который можно скачать с сайта Intel. (MSDN, DDK) не предлагать. Должен быть документ именно от Intel.

Да, естественно, это из документации от Intel. Я искал по слову "timer", но, к сожалению, утром не было времени, и я не успел почитать более детально.

http://developer.intel.com/design/pentium4/manuals/index_new.htm
Смотрите "IA-32 Intel® Architecture Software Developer"s Manual, Volumes 1-3"

Фраза про таймер, если мне не изменяет склероз, выдрана из
"IA-32 Intel® Architecture Software Developer"s Manual, Volume 3: System Programming Guide"

>Я очень надеюсь, что после прочтения Вами этого поста, этот вопрос отпадет.

Нет уж, нет уж. Я требую сатисфакции :-)
За [99] "Может хватит чушь нести, а?" приношу извинения - меня раздраконила фраза о "неправильной функции".

>Я ответил на ваш вопрос 1?
>Я ответил на ваш вопрос 2?

In progress...

P.S.
Кстати, насчет DOT. Вы проверяли, что возращает QPF, при изменении частоты? Интересно, всё-таки.

P.P.S.
Если окажется, что QPF с включенным DOT работает некорректно, было бы интересно упомянуть об этом на каком-нибудь форуме MS или чём-то таком и посмотреть, что ответят спецы из MS.

← →
Ihor Osov'yak © (2004-11-10 11:50) [142]

ок, снова время и..
продолжим бессполезный разговор.

2 [131] Defunct © (10.11.04 03:03)
> Попытайтесь лучше объяснить приведенный мной код,

Это что, подтверждение моих слов о вашей способности уводить разговор в сторону?

По существу поставленного вопроса -
с первого взгляда далено не комплектный фрагмент обработчика прерываний. Судя по номеров портов - имеет отношение к системному таймеру. Судя по названиям процедур и тп - пытающийся подстраивать частоту системного таймера согласно каких-то условий. Более конкретный вывод сделатьнелься ввиду малого размера кода. Да, это замечание не следует расценивать как мое желание лицезреть более полный фрагмент.
Еще. Что бросается в глаза. Человек, кодирующий соотв. фрагмент по всей видимости не знает, что директива Interrupt; заставляет компилятор генерировать серию комманд по сохранению регистров в стеке при входе в процедуры и соотв. команды извлечения этиз же регистров со стека - то есть
те несколько push в начале и pop в конце - совершенно излишние. Что позволяет сделать определенные выводы об уровне квалификации сотв. кодера.
2 [132] Defunct
повторяю раз пятый - посмотрите определение систем реального времени. И может повезет понять, что все в мире относительно.

2 134
> , Вы и так не нарисовали.

я не брал на себя таких обязательств. ВАм уже указывали на некоторую демагогичность вашего стиля ведения разговора.

> то я в отличие от Вас честен
я это уже видел. как минимуи раз прямая ложь.

> сказанную вами чушь в [9],
в контексте расматриваемого разговора - коректное высказывание. Некоректность сделанная там же, и не искажающая сути сказаноного, исправлена мною же несколько позже.

> и до сих пор не признали того, что вспыли на меня без повода.
где? Или это я lmd разбрасывал, или это я занимался прямой ложью?

>Уважаемый, что Вы о себе возомнили.
это наверное илюстрация способа вести разговор?

>обеспечить точность
мне сколько раз повторять, что разгоавор в контексте 100 нс я вел исключительно о дискретности? Спрашиваю раз десятый наверно - вы разность между дискретностью и точностью улавливаете? Я хотел бы услышать конкретный ответ на конкретный вопрос. Можно однословно - в стиле да/нет.

>приплели приоритеты потоков ядра

я раза три уже обьяснял какое сюда имет отношение потоки, выполняемые в режима ядра.. Знаете, как говорил один уважаемый человек - бесполезно спорить с магнитофоном. у меня впечатление, что разговор ведется с магнитофоном.

>Может быть на вашей волне разговор шел о приоритетах, а я говорил об аппаратных средстах.

есть такой прием - вбросить стороннюю тему и тотом доказывать что-то в разрезе этой темы....

2 [135] Defunct © (10.11.04 04:08)
> тогда вы в посте [133] лжете,
пост 133 довольно большой. Где по вашему мнению там ложь?
Даже если там и есть заблуждения (а я бы попросил указать на них конкретно), то не находите ли вы несколько наглым называть это ложью? Особенно на том фоне, что вы на лжи (повторяю, не заблуждениях, а на обычной, в прямом смысле лжи) уже были пойманы?

>Дело в том что не бывает небольших неточностей, бывает либо корретность либо некорректность.

вам уже указывали на демагогию.

> В общем вы можете продолжать выкручиваться
c чего такой вывод?

> но я свою миссию считаю завершенной.
на здоровье.

[136]

> Я вам могу подарить книгу..

я Била Гейтса и Папу Римского тоже по телевизору видел. B что из этого следует?

>Человек, для которого я старался и рисовал эти рисунки и так все понял.

Вы не ответили на конкретный вопрос - что на этом рисунке обозначает понятие "ядро"? Судя по тому, что это понятие фигурирует в картинке, изображающую распределение квантов времени и приоритетов потоков - это что то сродни потока в режиме ядра по вашему пониманию. Я конечно могу ошибится в реставрации ваших умозаключений, поэтому и переспрашиваю.
Так вот, на всякий случай - если эта моя гипотеза верна - то смею вас заверить, что в потоков, работающих в режиме ядра исключительно - есть несколько больше, чем один. Значительно больше. И с разными приоритетами.

.. в общем -то вы мне немного надоели. если будет время и подходящее настроение - может и продолжу разговор. а может и нет.

← →
Defunct © (2004-11-10 11:57) [143]

VMcL © (10.11.04 10:45) [141]

Эх.. я уже написал ответ на пост [141].. там такая поэма была, вам бы понравилось... нажал "Добавить" и приплыли.. Ветка удалена, пост потерян...

Абыдно....

Необессудьте, что отвечу кратко и только по существу (т.к. у меня нет 40 минут на написание ответа заново)

Да, естественно, это из документации от Intel. Я искал по слову "timer", но, к сожалению, утром не было времени, и я не успел почитать более детально.

http://developer.intel.com/design/pentium4/manuals/index_new.htm
Смотрите "IA-32 Intel® Architecture Software Developer"s Manual, Volumes 1-3"

Volume 3:
System Programming Guide

CHAPTER 8
ADVANCED PROGRAMMABLE
INTERRUPT CONTROLLER (APIC)

The Advanced Programmable Interrupt Controller (APIC), referred to in the following sections
as the local APIC, was introduced into the IA-32 processors with the Pentium processor (see
Section 18.24., “Advanced Programmable Interrupt Controller (APIC)”) and is included in the
Pentium 4, Intel Xeon, and P6 family processors (see Section 8.4.2., “Presence of the Local
APIC”).

8.5.4. APIC Timer
The local APIC unit contains a 32-bit programmable timer that is available to software to time
events or operations. This timer is set up by programming four registers: the divide configuration
register (see Figure 8-10), the initial-count and current-count registers (see Figure 8-11),
and the LVT timer register (see Figure 8-8).

The time base for the timer is derived from the processor’s bus clock, divided by the value specified in the divide configuration register.

Соответственно, та же проблема с DOT, что и при TSC.

> Кстати, насчет DOT. Вы проверяли, что возращает QPF, при изменении частоты? Интересно, всё-таки.

Да проверил.
Изменяется.
с 2 800 017 000 до 3 380 034 000
причем плавно в течение 10 сек.

> Если окажется, что QPF с включенным DOT работает некорректно, было бы интересно упомянуть об этом на каком-нибудь форуме MS или чём-то таком и посмотреть, что ответят спецы из MS.

Одно из двух или добавят в MSDN в следующем выпуске, или по рекомендуют никогда не использовать.

> За [99] "Может хватит чушь нести, а?" приношу извинения - меня раздраконила фраза о "неправильной функции".

принимется, я знал что вы не всерьез это сказали. ;)

← →
Defunct © (2004-11-10 12:17) [144]

Народ, объясните кто-нибудь Ihor Osov"yak, где он не прав.
Или объясните мне где неправ я.

Вот аргумент:

Ihor Osov"yak © (10.11.04 03:24) [133]
>> [9] Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение.
> [133] Естественно, задержек на переключение потоков не уменшает.

Конечно не уменьшает.

> [133] Уменшается время ожидания получения кванта времени.

В [6] вы говорили, цитирую, о непрогнозированности задержки на переключение потоков. Что вы подразумевали под "непрогнозируемость задержки на переключение потоков"? Вкладывали ли вы в смысл этой фразы время ожидания до переключения или нет? Если да, тогда вы в посте [133] лжете, если нет тогда время задержек на переключение потоков вполне прогнозируемо и выходит - вы лжете в [6].

Ihor Osov"yak © (10.11.04 11:50) [142]
Неужели вы считаете, что я буду метать биссер перед с... (C)
особенно после проявления такого неуважения к затраченному времени:
> Кстати, я так и не дождался расшифровки крякозябликов из

> Даже если там и есть заблуждения (а я бы попросил указать на них конкретно), то не находите ли вы несколько наглым называть это ложью?

Нет уважаемый, после всего что вы тут мне наговорили, я считаю ЛОЖЬ это именно то слово, которое должно быть.

Вы позволили себе на ложном утверждении судить о моей компетенции.

>>Defunct © (10.11.04 11:57) [143]

>Соответственно, та же проблема с DOT, что и при TSC.

М-да. Нехорошо, конечно.

>Одно из двух или добавят в MSDN в следующем выпуске, или по рекомендуют никогда не использовать.

Хм. Но выход-то должен быть? Что же делать, если для некоторого приложения нужен действительно high-resolution timer? Покупаешь тут, понимаете ли, компьютер за несколько сотен енотов и точного таймера нет? Безобразие :-)

P.S.
Кстати, интересно. Есть же утилиты, которые определяют CPU Speed. Для этого, если не ошибаюсь, они используют RDTSC совместно с high-resolution timer"ом. Интересно, что такая утилита покажет на Вашем PC с включенным DOT. Например, эта:
http://www.cpuid.com/download/cpu-z-124.zip
Если покажет всё-таки правильное значение, то тогда встает вопрос: как?

VMcL © (10.11.04 12:19) [145]

Я обязательно проверю, к вечеру выложу результат.

> Если покажет всё-таки правильное значение
хотя это сомнительно.
Проверял на двух тестах MSI-Core Center и Norton System Information. показания обеих разные. Core Center возвращает действительную частоту (ту что и QPF) Norton почему-то занижает?! причем странно, реальная частота 3.0 Norton говорит 2.6 (процессор 2.8). MS вообще похоже не меряет частоту, что было при старте виндовс ту и показывает.

about 144 и не только.

Вместо ответа на конкретные вопросы идет серия оскорблений.
Идет постоянный увод темы разговора.
Вполне возможные не совсем коректное употребление одного-двух слов в течении нескольких десятков постингов называются ложью. В то же время как сам опоннент допускает вольную интерпритацию моих высказываний, делает подмену понятий, несклько раз цепляет ярлыки, а в конце концов таки лжет обычной базарной ложью - (см. 108, фразу "зачем обзывать меня ламером в [70]" - и для справки просьба взглянуть 93 - и авторство этого постинга (ключевая цитата этого постинга - см [98], так как 93, кажется, удален) ).

Только факт присутствия в публичном месте не позволяет мне сказать, кто вы есть на самом деле.

На этом пересонаж с ником Defunct переходит в режим глубокого игнора. Мне жаль потраченого времени.

Ihor Osov"yak © (10.11.04 12:35) [147]
> Вместо ответа на конкретные вопросы идет серия оскорблений.

Уважаемый, хочешь чтобы к тебе уважительно относились - относись уважительно к другим. Как аукнется, так и откликнется (C)

> Defunct переходит в режим глубокого игнора
О боже, что же мне теперь делать!
Он добавил меня в игнор!
Теперь никто меня не будет необоснованно обвинять в некомпетенции, называть лжецом. И самое главное, я не услышу кто я есть на самом деле!

Как я много потерял. Хахаха.

Да глаза открой товарисч.
Единственное о чем я возможно буду жалеть, так это то, что ты не видел пост [75]

> Мне жаль потраченого времени.
А мне нет.

Defunct © (10.11.04 4:51) [136]
Хотя моя ошибка была в том, что я поддался на уловку. Чтобы я там не ответил вы бы все равно имели возможность дополнить список.

вот именно. Есть такая технология спора - задать вопрос человеку на который ты лучше знаешь ответ (например, данный вопрос активно обсудился в ФИДО). Человек ответит "неправильно" и типа на волне этого и все другие его высказывания - неправда. А если он ответит совсем плохо, можно сказать - "да ты такой простой вещи не знаешь? Я даже разговаривать не хочу...".

Иначе непонятно - какой смысл задавать такие дополнительные вопросы? Как на экзамене...

Defunct © (10.11.04 12:47) [148]

да забей, честное слово. Ihor Osov"yak действительно очень хороший спец. Очень хороший, пролапативший кучу литературы. Но беда только в том, что он сам считает себя классным специалистом, лучше чем многие другие. Вполне понятно, что программисты, которые ему встречались - в 99% случае ниже его классом, для него и стало аксиомой, что он всегда прав, он просто не может терпеть, не может понять, что кто-то лучше (или на уровне) него разбирается в некоторых вещах. Ну привык он, что приводя аргументы может переспорить любого. Поэтому когда у него не получается - сильно раздражается. А на этот раз ему достался очень хороший соперник, которого не смутишь цитатами из DDK MS или документации Intel.

Я честно говоря не разбираюсь в вещах, о которых вы говорите, и завидую твоим знаниям и знаниям Ihor Osov"yak.

Но я читал все посты, и по линии развертывающегося спора твое отношение мне ближе. Мне кажется ты человек, который хочет докопаться до истины. Если тебе объективно укажут на ошибку - то ее признаешь и даже не расстроишься, потому как будешь даже благодарен, так как тебе указали на твой пробел в знаниях. А опускания никому не понравятся - это понятно.

Ihor Osov"yak же спорит по другой причине - просто дает понять, КТО на самом деле разбирается в вопросе. Грубо говоря - сверкает гранями. И очень не любит, когда сверкать ему мешают.

Очень жаль, что такой знающий человек так относится к собеседникам. Говорит, что придираются к неточностям в его словах, хотя самм придирается к тому же самому, на мой взгляд... в общем, ладно...

> Таймер программно
> Ответов: 150 ...

VMcL © (11.11.04 09:59) [149]

Хороший тест. Спасибо за ссылку!

> Ку?

Просто забыл об этой ветке.

Вот что получилось:

При вкл. DOT, программа (1 раз в секунду) очень точно отображала изменения значений:
FSB от 200 до 240
Bus Clock от 800 до 960
и Core Speed соответственно от 2.8 до 3.36

Думаю это неудивительно, если программа использует IRQ0 в качестве эталона временной задержки, а TSC используется для подстчета тактов.

VMcL © (11.11.04 09:59) [149]

Обнаружил баг в программе.

При включенном DOT - иногда неправильно определяется кол-во каналов памяти (постоянно пишет Channel# = single) и неверно определяется тип памяти (из SPD), точнее сказать вообще никак не определяется.

С выкл. DOT, кол-во каналов и тип памяти распознаются и отображаются без ошибок.

PS: Больше всего меня удивила ошибка чтения SPD.
А в целом тест хорош.

>>Defunct © (13.11.04 07:40) [153]

Напишите разработчикам. Думаю, исправят.

>>Defunct © (13.11.04 07:30) [152]

>Думаю это неудивительно, если программа использует IRQ0 в качестве эталона временной задержки, а TSC используется для подстчета тактов.

Может быть, может быть. Но вот мне всё-таки хотелось бы глянуть исходники.
:-)

Таймер программно Найти похожие ветки