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

← →
Defunct © (2004-11-08 20:26) [80]

2 moderator

просьба восстановить пост [24]. В нем была приведена ссылка на источник, где можно прочитать об организации системного таймера в чипсетах под P4.

Если там и были грубости, то это возможно была просто опечатка.

← →
app © (2004-11-08 20:32) [81]

Ссылку можешь сделать в 81, а восстанавиливать пост с грубостями не допустимо. Более того если оппоненты не умерять свой пыл, то удалены будут не только посты, но и вся ветка.

← →
Defunct © (2004-11-08 20:32) [82]

Удалено модератором

← →
Defunct © (2004-11-08 20:42) [83]

Ihor Osov"yak © (08.11.04 15:25) [70]

Порошу четко обосновать ваши слова.

> "который всего один и неспособен выдавать синхроимпульсы с частотой 10Mhz для всех потоков.."

И пожалуйста перечитайте эту фразу до полного просветления.

← →
Defunct © (2004-11-08 21:07) [84]

Anatoly Podgoretsky © (08.11.04 20:22) [79]

ну про переполнение было сказано к тому, что таймеры обычно работают так, задается стартовое слово скажем ничинать с
$FF FF FF FF 00 00 00 00 00
и прибавлять до переполнения. При переполнении - прерывание.
Во всяком случае во многих DSP процессорах именно так и реализован внутренний/ие таймер/ы. Я просто хотел сказать, что Intel не встраивал таймер в свои процессоры серии x86, а сделал просто счетчик тактов. Соответственно для отсчета времени этот механизм лучше не использовать. Там где опрос в любой форме - там высокая погрешность или неоправданная трата процессорного времени.

← →
Piter © (2004-11-08 21:29) [85]

Хотя в этом, наверное, ошибка:

Ihor Osov"yak © (07.11.04 19:34) [6]
ну, еще бы на уровень 0 прыгнуть, там отсчет доступен с дискретностью 100 наносекунд :-).
Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков

а это не так. Никакой особой точности достигнуто не будет из-за неточности аппаратного таймера, у которого точность 1 мс (по словам Defunct"а).

← →
Defunct © (2004-11-08 21:49) [86]

Piter © (08.11.04 21:29) [85]

граничная точность 1 mks

1/1.xMhz

← →
Defunct © (2004-11-08 22:17) [87]

Перейдем к теории.

Граничное значение частоты канала таймера составляет 1.193180 Mhz при делителе = 1.
что соответствует способности отсчета временного интервала
0.8380965 mks

Разумеется в системе никогда не используется граничное значение таймера, поскольку частый вызов IRQ0 способствовал бы неоправданной трате процессорного времени на обработку этого прерывания. Да и некоторые процессоры например SX25 просто не успевали бы выполнить обработчик IRQ0 до повторной генерации прерывания. Поэтому в качестве делителя взято число 11932, которое обеспечивает доволно точный отсчет интервала в 10 ms (миллисекунд). Но и здесь присутствует погрешность последнего знака делитя. т.к
11932/1.19318Mhz = 10.00017
Как видно погрешность проявляется в разрядах наносекунд. Следовательно MS для компенсации накапливающейся погрешности ввели дискретность до сотен наносекунд.

Разумеется получить отсчет времени с точностью 100 нс и даже 100 msk в виндовсе не возможно. Накапливаемая погрешность говорит о том, что даже точный отсчет равный 10 ms в виндовсе тоже получить невозможно.

Исп. материалы:
Tech help, flambeaux software inc. (C) 2000
MSDN
MS Calculator
Intel ® 865G/865GV/865PE/865P Chipset Platform Design Guide For Use with the Intel
® Pentium ® 4 Processor

← →
KilkennyCat © (2004-11-09 00:34) [88]

гм... а я правильно понял, что частота этого злосчастного таймера не увеличивается уже давненько? Почему? нет необходимости?

← →
Defunct © (2004-11-09 01:11) [89]

именно: нет необходимости

хотя жаль что именно такой стандарт стал массовым, было бы намного удобнее если бы граничная частота таймера была бы кратна 1.0Mhz тогда б можно было бы получать очень точные времмные интерывалы без всяких дополнительных устройств.

← →
Defunct © (2004-11-09 04:28) [90]

Я хотел бы кое-что прояснить:

Цитата из Windows DDK

Thread Priorities
Some drivers create their own driver- or device-dedicated system threads and set their thread"s base priority to the lowest real-time priority value. Other highest-level drivers, particularly file system drivers, use system worker threads with a base priority that is usually set to the highest variable priority value. The kernel schedules a thread with the lowest real-time priority to run ahead of every thread with a variable priority, which includes almost every user-mode thread in the system.

Цитата и MSDN:
Threads are scheduled for execution based on their priority. The scheduling algorithm used to determine the order of thread execution varies with each operating system. The operating system can also adjust the thread priority dynamically as the user interface"s focus is moved between the foreground and the background.

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

2 Ihor Osov"yak
Тепер пожалуйста объясните вашу фразу:

Ihor Osov"yak © (07.11.04 21:23) [9]
нет, не решает. Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение.

и пожалуйста эту тоже:

Ihor Osov"yak ©
Зы. я уже молчу о продемонстрированном незнании тематики о приоритетах потоков..

Покажите мне пожалуйста где я продемонстрировал незнание тематики о приоритетах потоков? Ведь кроме вопроса [8] я о приоритетах нигде не упомянул.

Я настоятельно прошу обосновать все, что вы сказали про меня в посте [70], или принести извинения. В противном случае я буду расценивать пост [70] как проявление какого-то комплекса неполноценностей

С уважением,
Def

← →
Defunct © (2004-11-09 05:55) [91]

> Ihor Osov"yak
Кстати, обратите внимание на это (ключевое слово подчеркнуто):

The kernel schedules a thread with the lowest real-time priority to run ahead of every thread with a variable priority, which includes almost every user-mode thread in the system.

таким образом допускается для потоков пользовательского режима получать Real-time приоритет.

иначе бы таки нельзя было записать CD-диск на стареньких приводах без burn-proof.

Что-то здается мне, что некто сам плохо разбирающийся в вопросах функционирования многозадачных ОС и временного планирования взялся судить о моем знании тематики о приоритетах потоков.

> Синхронизация общения между хост-контролером и устройствами, подключенными к USB шине идет как раз способом опроса, а не прерываний...

IMHO пример не совсем удачный.
Разве можно как-то иначе со стороны Host контроллера по последовательной шине-то (по 3-х проводке!)?

PS: сами USB устройства работают в режиме прерываний (стоит селектор адреса, когда по трех проводке пробегает адрес хранящийся в селекторе генерируется прерывание - проц USB устройства "просыпается" и начинает работу).
PPS: и сам Host контроллер, кстати, тоже работает в режиме прерываний.

С уважением,
Def

← →
Defunct © (2004-11-09 06:34) [92]

InfMag © (07.11.04 19:06)
> Как мне создать таймер программно? Без формы и не теряя приемуществ обычного таймера.

По сабжу, Вы можете создать обычный таймер без формы и не теряя его преимуществ:

program ConsoleT; {$APPTYPE CONSOLE} uses SysUtils, Windows, ExtCtrls, Classes; procedure TimerHandler(self, Sender: TObject); begin with TTimer(Sender) do begin Tag := Tag - 1; WriteLn("terminating in ",Tag, " seconds"); end end; var Msg : TMsg; M : TMethod; begin with TTimer.Create( nil ) do begin Enabled := True; Tag := 100; M.Code := @TimerHandler; OnTimer := TNotifyEvent(M); while Tag > 0 do if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then DispatchMessage( Msg ); free end; end.

← →
Defunct © (2004-11-09 06:50) [93]

Удалено модератором

← →
VMcL © (2004-11-09 07:59) [94]

>>Defunct © (08.11.04 22:17) [87]

>Граничное значение частоты канала таймера составляет 1.193180 Mhz при делителе = 1.
что соответствует способности отсчета временного интервала
0.8380965 mks

Хм. А QueryPerformanceFrequency мне "говорит", что может "померять" по таймеру с частотой 3 579 545 Hz. Что я делаю не так?

← →
Defunct © (2004-11-09 08:12) [95]

VMcL © (09.11.04 07:59) [94]

> Что я делаю не так?

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

← →
Defunct © (2004-11-09 08:32) [96]

> VMcL

PS: системный таймер понес изменения - увеличено число каналов. но канал 0, который генерирует IRQ0 соответствует тому, что написано в [87].

читаю help по QueryPerformanceFrequence:

If the installed hardware supports a high-resolution performance counter, the return value is nonzero.

Возможно для определения производительности используется другой "high-resolution" канал таймера, я этим вопросом ранее не задавался.

← →
Anatoly Podgoretsky © (2004-11-09 09:03) [97]

Defunct © (09.11.04 08:12) [95]
QueryPerformance... используе TSC

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

2 [93] Defunct © (09.11.04 06:50)

>посты [6] и [9] из разряда LMD

уверен?

2 90, 91..

>Тепер пожалуйста объясните вашу фразу:
...
>
Я настоятельно прошу обосновать все, что вы сказали про меня в посте [70], или принести извинения. В противном случае я буду расценивать пост [70] как проявление какого-то комплекса неполноценностей

Читать еще раз, медлено, и вдумчиво. Также позволю напомнить себе, что DDK состоит немного больше, чем из одного абзаца. Это во первых. Во вторых - я не нанимался устрянять пробелы в знаниях некого особо упрямого индивида.
В третьих, я уже говорил - мне все равно, что думает этот индивид.

Удачи.

← →
VMcL © (2004-11-09 10:52) [99]

>>Defunct © (09.11.04 08:12) [95]

>Вызываете не ту функцию.
Мне QueryPerformanceFrequency "говорит" - 2.8Ghz.

Не ту? Это какую? Есть несколько функций QueryPerformanceFrequency? Может хватит чушь нести, а? Дома на Athlon XP 1800+ @ 1533 MHz выдает ровно столько, сколько я написал в [94]. На работе на P4 @ 3 GHz w/HT выдает 2 992 560 000.

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

Глубокомысленно. Не ожидал, честное слово. После "множества" экспериментов аж на одном компьютере такой фундаментальный вывод. Браво.

P.S. С учетом [95] до сих пор считаете, что
>Разумеется получить отсчет времени с точностью 100 нс и даже 100 msk в виндовсе не возможно. Накапливаемая погрешность говорит о том, что даже точный отсчет равный 10 ms в виндовсе тоже получить невозможно.
?

P.P.S.
1 / 2.8E9 ~= 0.357E-9 ~= 0.4 нс

← →
panov © (2004-11-09 11:25) [100]

>Defunct © (09.11.04 5:55) [91]
The kernel schedules a thread with the lowest real-time priority to run ahead of every thread with a variable priority, which includes almost every user-mode thread in the system.

таким образом допускается для потоков пользовательского режима получать Real-time приоритет.

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

Теперь несколько вопросов:
1. Что есть режим ядра для потока?
2. Тратится ли время на переключение потоков и каково это время?
3. Позволяет ли повышение приоритета потока гарантированно уменьшить время переключения потока до некоторой величины дельта?

← →
Игорь Шевченко © (2004-11-09 13:29) [101]

http://www.sysinternals.com/ntw2k/source/misc.shtml#clockres

← →
Defunct © (2004-11-09 17:37) [102]

> Anatoly Podgoretsky © (09.11.04 09:03) [97]
> QueryPerformance... используе TSC

Спасибо Анатолий

> VMcL © (09.11.04 10:52) [99]
> P.S. С учетом [95] до сих пор считаете, что

Я не считаю, я знаю.

> 1 / 2.8E9 ~= 0.357E-9 ~= 0.4 нс
Уже говорил про целесообразность использования TSC. см [46] и [84].

> panov © (09.11.04 11:25) [100]
1. вопрос некорректен. (для потока вообще все равно в каком он режиме)
2. Разумеется тратится. Все активные потоки выстроены в очередь к процессору. Процессор один, потоков много. Теперь уточните ваш вопрос какое время Вас интересует:
- паузы между выполнением конкретного потока
- на переключение между любыми двумя случайными потоками
3. Гарантировано не позволяет в сл. случаях:
- если после повышения приоритета потока количество потоков с более низким приоритетом остается таким же как было до изменения приоритета.
- если потоки с более высоки приоритетом используют все процессорное время.

> Ihor Osov"yak © (09.11.04 09:59) [98]
> уверен?
Абсолютно.

> Ihor Osov"yak © (09.11.04 09:59) [98]
> Читать еще раз, медлено, и вдумчиво.
Вы говорите читать медленно и вдумчиво, но не говорите, что читать.

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

> В третьих, я уже говорил - мне все равно, что думает этот индивид.
Иногда лучше жевать.

← →
Игорь Шевченко © (2004-11-09 17:43) [103]

Defunct © (09.11.04 17:37) [102]

> 1. вопрос некорректен. (для потока вообще все равно в каком
> он режиме)

GetThreadTimes. Читать наизусть.

← →
Defunct © (2004-11-09 18:27) [104]

> Игорь Шевченко

Прочитал наизусть,
что не понравилось в ответе на [1]?

what is kernel mode for threads? (корректен ли?)
what does thread in kernel mode means?

← →
Defunct © (2004-11-09 19:09) [105]

VMcL © (09.11.04 10:52) [99]

> Не ту? Это какую? Есть несколько функций QueryPerformanceFrequency? Может хватит чушь нести, а? Дома на Athlon XP 1800+ @ 1533 MHz выдает ровно столько, сколько я написал в [94]. На работе на P4 @ 3 GHz w/HT выдает 2 992 560 000.

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

[94]
3 579 545 Hz
Athlon XP 1800+ @ 1533 MHz
[99]
2 992 560 000
P4 @ 3 GHz w/HT

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

← →
Ihor Osov'yak © (2004-11-09 19:13) [106]

ок, есть время и воодушевление.

Во первых, вы, Defunct в упор не желаете видеть, что я речь в контексте 100 нс я вел исключительно о дискретности, а не о точности. Вы почему-то
этого в упор не замечаете, следлвательно, у вас наблюдается либо неумение читать, либо вы не отличаете понятий дискретность и точность, либо у вас присутствует то, что принято называть LMD. Выбор за вами.

относительно [9].
Да, там у меня есть маленькая неточносить, впорочем, не искажающая сути рассматриваемого вопроса. Я говорил, что "даже если сделать SetPriorityClass + SetThreadPriority по максимуму) - по любому будут иметь ниже приоритет, чем потоки режима ядра, даже на самом захудалом уровне приоритетов...". Более корректно будет следующоя формулировка -
"даже если сделать SetPriorityClass + SetThreadPriority по максимуму) - по любому будут иметь приоритет, не выше, чем потоки режима ядра на уровне PASSIVE_LEVEL, и ниже потоков, имеющих уровни APC_LEVEL и выше. "
Далее. Потоки имеющие уровень выше PASSIVE_LEVEL, а это могут быть только потоки, выполняющие код в режиме ядра, не подпадают под планировщик, и их выполнение прекращается либо тогда, когда они завершают свою работу, либо когда понижают свой уровень, либо когда появляется поток с более высоким уровнем.. То есть поток, имеющий уровень выше, чем PASSIVE_LEVEL никогда не будет прерван потоком пользовательского режима, какой бы высокий он приоритет не имел.. То есть повышая приоритет потока пользоательского режима до максимального знаачения мы не можем гарантирровать то, что его выполнение не будет прерываться, либо его активация будет выполнятся с максимально возможной скоростью - так как вероятнее всего в системе будут присутствовать потоки режима ядра с уровнями выше PASSIVE_LEVEL..
Все это коротко было сказано фразой "нет, не решает" в начале [9]. собственно и [9], и вішесказанное илюстрирует то, что причем здесь режим ядра, или как там было сказано - "приплел" - влом уже смотреть за точной цитатой.

..Кстати, меня очень умиляет ваша способность делать выводы об обустройстве операционной системы в процессе наблюдения за записью СD...

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

← →
Defunct © (2004-11-09 19:24) [107]

> Игорь Шевченко

Я бы хотел услышать ваше мнение, насчет [6] и [9] и соответственно выдержек [87], [90],[91]. Вы как незаинтересованный в исходе спора хорошо знающий данную тему человек рассудите пожалуйста наш спор. (разумеется если у вас есть время и желание).

Корректен ли пост [6]?
Верно ли то, о чем говорится в [9]?

← →
Defunct © (2004-11-09 19:43) [108]

Ihor Osov"yak © (09.11.04 19:13) [106]

> Во первых, вы, Defunct в упор не желаете видеть, что я речь в контексте 100 нс я вел исключительно о дискретности, а не о точности.

Я понял это сразу, еще до того как запостил [8].

Игорь понимаете, Вы меня отправили пожевать непонятно почему и совсем не обоснованно в посте [13]. Посмотрите ветку, я ведь даже не говорил нигде до поста [13], что Вы говорили о точности.

> относительно [9].
> Да, там у меня есть маленькая неточносить,
Поправки принимаются.

Я понимаю, что [9] вы написали в порыве гнева, но извините, зачем обзывать меня ламером в [70] лишь за один только пост [8] в котором кроме константы обозначающей приоритет ничего более о потоках либо приоритетах потоков сказано не было.

> или как там было сказано - "приплел" - влом уже смотреть за точной цитатой.

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

> Нет желания по причине вашей неспособности внимательно читать (
Давайте вы здесь поставите IMHO, а то звучит слишком категорично.
Для чего вы вспылили в [9] после того как была упомянута лишь одна константа в [8]?

Я бы давно уже прекратил этот спор, да и прекратил его собственно, но вы же опять заставили меня вернуться к нему после [70]. Согласитесь если бы я написал о Вас то же самое, вы бы тоже полезли в DDK, MSDN и т.п. и поставили бы меня на место.

Ничего личного.

2 Defunct ©

>Вы меня отправили пожевать непонятно почему и совсем не обоснованно в посте [13].

Вы приписали мне слова, которые я не говорил. В ответ последовал совет пожевать (с приведенной ниже по тексту аргументацией). Я считаю вполне адекватный для данного случая ответ.

> зачем обзывать меня ламером в [70]

Пожалуйста, цитату, где это я сделал в посте [70]. То, что там были сделаны выводы о вашей компетентности в некоторых вопросах - то были основания для этого.

> Для чего вы вспылили в [9] после того как была упомянута лишь одна константа в

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

> Согласитесь если бы я написал о Вас то же самое, вы бы тоже полезли в DDK, MSDN и т.п. и поставили бы меня на место.

Я уже раз просил не делать за меня выводы.

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

Я ничего вам не приписывал.
Я просто сам сказал, помимаете сам, не искажая и не трогая вашего поста [6]. А сказал вот что [11]:

> ох и да, прошу прощения не заметил явное несоовтветствие сразу -100 наносекунд прочитал как 100 ms. Уверяю вас, точности в 100 нс в виндовсе нет даже на уровне ядра (10 ms по рихтеру) а если открыть старенького Джордейна то увидим что макс. частота системного таймера (~1.3Mhz что соответствуею ~1 mks но никак не 100 нс).

(несоответствие относилось лишь только ко мне, как вы понимаете, если бы я осознал сразу, что речь идет о 100 нс, а не о 100 ms, я бы даже не постил [8]), понимаете о чем я?

Скажите где Вы здесь заметили, что я искажаю вашу фразу? Ведь нет ни ссылки, ни вашей цитаты.

Может там что-то было написано неверно, дык уже вроде бы доказал каждое слово.

> Пожалуйста, цитату, где это я сделал в посте [70]. То, что там были сделаны выводы о вашей компетентности в некоторых вопросах - то были основания для этого.

>"который всего один и неспособен выдавать синхроимпульсы с частотой 10Mhz для всех потоков.." Интересно, что это за ноу-хау в архитектуре, способное передвать "синхроимпульсы" потокам? И какова физика этого ноу-хау.
Зы. я уже молчу о продемонстрированном незнании тематики о приоритетах потоков..

Вы взяли мою цитату исказили в ней смысл так, что получилось эдакое ламерское ноу-хау.
Вы сделали вывод о компетентности основываясь на упонимание об одной только константе tpTimeCritical, вы проигнорировали пост [11] в котором я говорил о не соответствии поста [8] для 100 нс. Для выдержки в 100 ms - tpTimeCritical подходит более чем.

> Я уже раз просил не делать за меня выводы.
Насколько мне не изменяет память вы просили не трактовать ваши слова. (и я вашу просьбу удовлетворяю).

>>Defunct © (09.11.04 19:09) [105]

>Вы что так и не поняли

Я по Вашему читать не умею? Привожу еще раз:
Defunct © (09.11.04 08:12) [95]
VMcL © (09.11.04 07:59) [94]
> Что я делаю не так?
Вызываете не ту функцию.

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

Я не знаю, что Вам рассказывал Ваш учитель/преподаватель физики, но меня учили, что частота (frequency) измеряется в герцах, а не в "ничего незначащих попугаях", которыми удава измеряли в известном мультфильме.

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

> Может там что-то было написано неверно
я, кстати, не комментировал, что там верно, а что нет. я пытался обратить внимание на то, что вы сделали отход от темы. ТО есть начали вести речь о платформе, которая неприемлимая в контексте разговора о режиме ядра NT ряда. Я уже устал повторять это.

> Насколько мне не изменяет память вы просили не трактовать ваши слова. (и я вашу просьбу удовлетворяю).

Вы это сделали, как минимум, два раза. И оба раза некоректно.

Также позволю себе заметить, что за вами наблюдается способность уходить от прямых и конкретных вопросов, напоминаю еще раз - где конкретно в [70] я назвал вас ламером, о чем вы утверждаете в [108]. Вас в школе не учили, что лгать - плохо?

VMcL © (09.11.04 20:43) [112]

Уважаемый VMcL, читайте [46] и [84] до полного просветления.
Я не намерен вести спор с вами непонятно о чем.
3 579 545
2 992 560 000
тут разница на 3 порядка.
О режиме программного опроса в этой ветке говорилось неоднократно. А также о D.O.T. Поэтому я не хочу тратить свое время на переливание из пустого в порожнее.

> что Вам рассказывал Ваш учитель/преподаватель физики, но меня учили, что частота (frequency) измеряется в герцах, а не в "ничего незначащих попугаях", которыми удава измеряли в известном мультфильме
Я очень уважаю своего бывшего учителя физики и прекрасно помню в чем меряется частота и что 1/Hz = сек.

>>Defunct © (09.11.04 19:09) [105]

>[94]
3 579 545 Hz
Athlon XP 1800+ @ 1533 MHz
[99]
2 992 560 000
P4 @ 3 GHz w/HT

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

С чего Вы взяли, что я собираюсь что-то соотносить? Вы привели, так сказать, "правильное значение", сказав, что мое, оказывается, неправильное. А я Вам показал, что на разных процессорах таймеры, как это ни странно, совершенно разные.

Кстати, на [46] Вам частично ответили в [49]. Насчет DOT не знаю. Но вполне может оказаться, что таймер, используемый ф-циями QPF/QPC, "имел в виду" изменение частоты CPU. В конце концов, на то он и таймер. Просто в неком нормальном режиме частота таймера и частота ядра CPU совпадают.

>>Defunct © (09.11.04 20:55) [114]

>Я очень уважаю своего бывшего учителя физики и прекрасно помню в чем меряется частота и что 1/Hz = сек.

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

Так какое из этих 2-х мне выбрать, не менее уважаемый Defunct?

> Также позволю себе заметить, что за вами наблюдается способность уходить от прямых и конкретных вопросов, напоминаю еще раз - где конкретно в [70] я назвал вас ламером

Признаю - нигде.

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

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

lpFrequency

Points to a variable that the function sets, in counts per second, to the current performance-counter frequency.

>>VMcL © (09.11.04 21:00) [115]

>Но вполне может оказаться, что таймер, используемый ф-циями QPF/QPC, "имел в виду" изменение частоты CPU. В конце концов, на то он и таймер.

Кстати, MSDN подтверждает мою "догадку":
The QueryPerformanceFrequency function retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running.

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

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

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

2 VMcL

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

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