Форум: "Потрепаться";
Текущий архив: 2004.11.28;
Скачать: [xml.tar.bz2];
Вниз
Таймер программно Найти похожие ветки
← →
InfMag © (2004-11-07 19:06) [0]Как мне создать таймер программно? Без формы и не теряя приемуществ обычного таймера.
← →
KilkennyCat © (2004-11-07 19:08) [1]работа с потоками. Создаешь поток, в нем счетчик, основанный на gettickcount
← →
InfMag © (2004-11-07 19:19) [2]Ну а пример программы? Или ссылочку на уже тут прописавшуюся тему?
← →
snake1977 (2004-11-07 19:20) [3]http://delphimaster.net/view/1-1099292775/
← →
Ihor Osov'yak © (2004-11-07 19:28) [4]2 [1] KilkennyCat © (07.11.04 19:08)
И рискуем нарваться на конкретный подгруз системы. В случае неакуратной реализации.
По сабжу. Не совсем понятен смысл вопроса. Если имеется ввиду "создание" не в дизайн-тайме компонентокиданием - то так-же, как и создание любого другого компонента в рантайме.
Если имеется ввиду без услуг vcl - то SetTimer (не забывая про KillTimer), либо самозапирание потока на каком-то обьекте синхронизации с таймаутом с помощью WaitForSingleObject.. Иногда можно обычный sleep (тогда "самозапирание" c таймаутом делает система)..
Следует иметь ввиду, что варианты с "запиранием" плохо выглядять в случае вызова из главного потока - тогда "замораживается" интерфейс.. В таком случае можно сделать что-то типа нижеследующегоprocedure _Pause01;
var
t: tdatetime;
const
delta = 1.0 / 24.0 / 60 / 60 / 10;
begin
t := now;
repeat
if GetQueueStatus(QS_ALLEVENTS) <> 0 then
Application.ProcessMessages
else
sleep(10);
if abs(t - now) > delta then
break;
until false;
end;
да, пожалуй, здесь лучше вместо now ориентироваться все же на GetTickCount..
еще для избежания "заморозки" вместо WaitFor.. можно использовать
MsgWaitForMultipleObjects ..
← →
KilkennyCat © (2004-11-07 19:30) [5]
> Ihor Osov"yak © (07.11.04 19:28) [4]
согласен, но если требуется точный таймер, без нити не обойтись.
← →
Ihor Osov'yak © (2004-11-07 19:34) [6]> согласен, но если требуется точный таймер, без нити не обойтись.
ну, еще бы на уровень 0 прыгнуть, там отсчет доступен с дискретностью 100 наносекунд :-).
Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков..
← →
KilkennyCat © (2004-11-07 19:38) [7]
> Ihor Osov"yak © (07.11.04 19:34) [6]
да... 100 наносекунд - тут уже почти и к железным проблемам подбираемся... но наверное, можно приблизительно подсчитать золотую середину, когда необходимо работать с потоком, а когда уже бесполезно, или излишне.
← →
Defunct © (2004-11-07 20:34) [8]> непрогнозированности задержки на переключение потоков..
разве tpTimeCritical не решает этот вопрос?
← →
Ihor Osov'yak © (2004-11-07 21:23) [9]нет, не решает. Во превых, это поднимает только приоритет потока, но не уменшает задержек на переключение. Во вторых - и это более важно - всякие там tpTimeCritical - вещь не абсолютная, а относительна касательно к базовому приоритету процесса. В третих же - и это еще более существенно - все потоки пользовательского режима (даже если сделать SetPriorityClass + SetThreadPriority по максимуму) - по любому будут иметь ниже приоритет, чем потоки режима ядра, даже на самом захудалом уровне приоритетов... Не гороря уже за приоритеты кода, выполняющего обработку прерываний..
← →
KilkennyCat © (2004-11-07 21:28) [10]из чего и сделаем вывод: реалтайм - вещь специфичная и решается специальными методами.
← →
Defunct © (2004-11-07 21:55) [11]Ihor Osov"yak © (07.11.04 21:23) [9]
Вы так все описали, что можно подумать записать компакт диск на старых приводах с маленьким буфером записи и без burn proof является невыполнимой задачей.
> по любому будут иметь ниже приоритет, чем потоки режима ядра
чем поток планироващика - да.
ох и да, прошу прощения не заметил явное несоовтветствие сразу -100 наносекунд прочитал как 100 ms. Уверяю вас, точности в 100 нс в виндовсе нет даже на уровне ядра (10 ms по рихтеру) а если открыть старенького Джордейна то увидим что макс. частота системного таймера (~1.3Mhz что соответствуею ~1 mks но никак не 100 нс).
← →
GuAV © (2004-11-07 22:09) [12]InfMag © (07.11.04 19:06)
Как мне создать таймер программно? Без формы и не теряя приемуществ обычного таймера.
SetTimer(0, 0, N, @MyTimerProc);
← →
Ihor Osov'yak © (2004-11-07 22:16) [13]2 [11] Defunct © (07.11.04 21:55)
> что можно подумать записать компакт диск на старых приводах с маленьким буфером записи и без burn proof является невыполнимой задачей.
Свой первый диск я записывал еще в 97 году. На момент записи снимались все лишние процессы и отключалась сеть. Если этого не сделать - выход был менее 50 процентов..
> точности в 100 нс в виндовсе нет даже на уровне ядра
Точность - понятие очень относительное, а вот если говорить об дискретности программирования временных интервалов, то иногда лучше жевать, чем говорить (см. ниже).
> а если открыть старенького Джордейна
я не говорил, что речь идет о системе на базе 8086/8088. Что это не так, можно было бы догадаться хотя бы по упоминанию режима ядра. То есть, что речь идет как минимум о 386.
да, еще. Посмотрите на описание KeWaitForSingleObject, KeSetTimer и иже с ними - обратите внимание на дискретность задания временных интервалов. Подсказка - смотреть нужно не в msdn, а в ddk от систем nt-шного ряда.
← →
Ihor Osov'yak © (2004-11-07 22:24) [14]ладно, привожу выдержку из ддк-овской докуентации:
KeSetTimer
KeSetTimer sets the absolute or relative interval at ....
BOOLEAN
KeSetTimer(
IN PKTIMER Timer,
IN LARGE_INTEGER DueTime,
IN PKDPC Dpc OPTIONAL
);
...
DueTime
Specifies the absolute or relative time at which the timer is to expire. If the value of the DueTime parameter is negative, the expiration time is relative to the current system time. Otherwise, the expiration time is absolute. The expiration time is expressed in system time units (100-nanosecond intervals). Absolute expiration times track any changes in the system time; relative expiration times are not affected by system time changes.
Понятно, что чудес не бывает, и
The expiration of the timer ultimately depends on the granularity of the system clock. The value specified for DueTime guarantees that the timer object is set to a signaled state on or after the given DueTime. However, KeSetTimer cannot override the granularity of the system clock, whatever the value specified for DueTime.
Но тот факт, что в современных системах тактовая частота значительно выше, чем частота в стареньком оригинальном PC, надеюсь, есть известным.. И что в качестве системного таймера используется уже не i8053 с его ~1.3Mhz тактовой частотой.
← →
Piter © (2004-11-07 22:25) [15]ИЗ БУДУЩЕГО FAQ:
Вопрос: как создать таймер средствами Win32Api
Ответ: нужно воспользоваться функцией SetTimer, описанной в Windows.pas следующим образом:
function SetTimer(hWnd: HWND; nIDEvent, uElapse: UINT;
lpTimerFunc: TFNTimerProc): UINT; stdcall;
hWnd - указатель на окно, куда будут посылаться сообщения WM_TIMER при очередной итерации таймера
nIDEvent - задает идентификатор таймера, не должен быть ноль. Игнорируется системой, если hWnd равно нулю
uElapse - время в миллисекундах между итерациями таймера
lpTimerFunc - указатель на процедеру TimepProc, которая должна являться callback функией и которая будет вызываться системой при каждой итерации таймера
Видно, что существую два пути задания таймера - или задать окно hWnd, куда будут посылаться сообщения WM_TIMER каждые uElapse миллисекунд, или задать указатель на процедуру lpTimerFunc, которая будет вызываться системой каждые uElapse миллисекунд.
Какой из способов будет использоваться, система выбирает по значению lpTimerFunc. Если оно задано, то будет вызывать TimerProc функцию, если передается nil - то будет посылаться сообщение заданному окну.
1) Рассмотрим первый вариант:
procedure TForm1.Button1Click(Sender: TObject);
begin
SetTimer(Handle, 1, 1000, nil);
end;
После нажатия на Button1 экземпляру TForm1 каждые 1000 миллисекунд (1 секунду) будет посылться сообщения WM_TIMER. Естественно, нужно это сообщение обрабатывать. У TForm1 объявить метод:
TForm1 = class(TForm)
...
procedure WMTImer(var Msg: TMessage); message WM_TIMER;
...
И реализовать:
procedure TForm1.WMTImer(var Msg: TMessage);
begin
beep;
end;
Каждую секунду будем издавать звуковой сигнал.
2) теперь рассмотрим второй варинт, на основе процедуры TimerProc. Вызов будет такой:
idTimer := SetTimer(0, 0, 1000, @TimerProc);
В качестве указателя на окно пишем ноль, во второй параметр пишем что хотим (все равно игнорируется), третий - время итераций, четвертый - указатель на процедуру TimerProc, которая будет вызываться системой каждые 1000 миллисекунд. Где-то должна быть объявлена:
procedure TimerProc(wnd: HWND; Msg: UINT; idEvent: UINT; Time: DWORD); stdcall;
begin
beep;
end;
Где wnd - указатель на окно, которое передали функции SetTimer (в нашем случае ноль); Msg - номер сообщения (оно будет равно WM_TIMER); idEvent - идентификатор таймера; Time - время в миллисекундах, которое прошло с момента загрузки windows на момент генерации этого события таймера (данное значение эквивалентно тому, что возвращает функция GetTickCount).
Делает этот код тоже самое, что и первый пример - издает сигнал каждую секунду. При этом никакие передаваемые аргументы я не анализирую. Хотя, например, можно создать два таймера и назначить им одинаковую TimerProc. А различать вызовы от одного и другого таймеров по значению idEvent.
Значение, возвращаемое функцией SetTimer сохраняется в какую-нибудь переменную idTimer. Это нужно, чтобы потом можно было удалить таймер, так как во втором примере id таймера назначется системой.
Также имеет смысл проверять значение, возвращаемой функцией SetTimer, в любом случае. Если она вернет ноль - то таймер создать не удалось, иначе она вернет идентификатор таймера. В первом примере SetTimer вернет тот идентификатор, которйы мы ему сами и назначили. Во втором примере назначение идентификатора система игнорирует (так как hWnd равно нулю), поэтому сама выбирает значение идентификатора - поэтому его и надо запомнить.
Чтобы удалить таймер надо просто вызвать функию KillTimer, передав ей Handle окна (который указывали при создании таймера) и идентификатор таймера.
1) для первого случая:
KillTimer(Handle, 1);
2) ддя второго случая:
KillTimer(0, idTimer);
Файл проекта с данным примером можно загрузить ЗДЕСЬ
Отвечал: Piter
← →
Defunct © (2004-11-07 22:35) [16]> Свой первый диск я записывал еще в 97 году. На момент записи снимались все лишние процессы и отключалась сеть. Если этого не сделать - выход был менее 50 процентов..
С этим я согласен, однако это опровергает ваши слова:
> по любому будут иметь ниже приоритет, чем потоки режима ядра
Потоки режима ядра вы ведь не снимали.
> Точность - понятие очень относительное, а вот если говорить об дискретности программирования временных интервалов, то иногда лучше жевать, чем говорить (см. ниже).
Уважаемый Игорь, не надо меня отправлять за орбитом, я его конечно не против пожевать, но здесь вы хотите так все повернуть, что мол я должен жевать а у вас типа все гладко. Не выйдет, ваши слова:
> ну, еще бы на уровень 0 прыгнуть, там отсчет доступен с дискретностью 100 наносекунд :-).
Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков..
> я не говорил, что речь идет о системе на базе 8086/8088. Что это не так, можно было бы догадаться хотя бы по упоминанию режима ядра. То есть, что речь идет как минимум о 386.
Не имеет разницы, таймер остался прежним. (1.3 Mhz, и его вполне хватает для любых нужд ОС).
> да, еще. Посмотрите на описание KeWaitForSingleObject, KeSetTimer и иже с ними - обратите внимание на дискретность задания временных интервалов.
Нет проблем, видел описание раньше.
> Подсказка - смотреть нужно не в msdn, а в ddk от систем nt-шного ряда.
А зачем смотреть ddk для nt ядра, если аппаратные средства все равно не способны дать такую точность?
← →
GuAV © (2004-11-07 22:38) [17]Кстати по этому давно волнующий меня вопрос -
procedure TimerProc(wnd: HWND; Msg: UINT; idEvent: UINT; Time: DWORD); stdcall;
Она вызывается не при обаботке сообщений а в любой момент. Должен ли быть код в нутри неё потокобезопасным ? создаёт ли такоё таймер "неявный" дополнительный поток ?
← →
Defunct © (2004-11-07 22:41) [18][16].
написал до того как запостили [14, 15]
поэтому
2 Ihor: ладно забей, это от скуки начал к словам придераться.
← →
Ihor Osov'yak © (2004-11-07 22:54) [19]2 [15] Piter © (07.11.04 22:25)
Хоть я и обещал тебя в глубокий игнор, но раз ты составляешь FAQ - несколько дополнений.
Не рассмотрен еще один вариант использования таймера, а именно - и хендл, и процедура - нулевые, то есть SetTimer(0, 0, NNNN, 0);
В таком случае таймер будет просто посылать WM_Timer в очередь потока, в котором был создан таймер. Сообщение обрабатываем в цыкле выборки сообщений. Здесь есть одна очень красивая возможность получить грабли. Дело в том, что очень часто либо сам разработчик, либо в коде стороних модулей, которые выполняются в потоке создавшем таймер делают альтернативные цыклы обработки сообщений, что-то типа
while getmessage() do
begin
case Msg.Message of ..
end;
DispatchMessage(Msg);
end;
хотя бы для организации некоторых временных задержек. Так вот, во время, когда будет работать такой цикл, наш обработчик сообщения для потока это сообщение не получит - ведь обработчик то в главном цыкле, а альтернативный цыкл WM_Timer просто проигнорирует, либо обработает совсем не так, как нам нужно - ведь там будет не наш код. Аналогичной проблемы при использовании хендла окна не будет, при условии естественно, что в альтернативном цыкле будет стоять DispatchMessage (мы все же надеемся, что программисты народ здравомыслящий в своем большинстве). Такой же проблемы вероятнее всего не существуеь и при втором способе - так как отложенный вызов процедуры таймера вероятнее всего делается где-то в глубине getmessage или ему подобных - но это догадка, я этого вопроса не исследовал..
Третий cпособ я упомянул лишь для полноты картины. Но. Его наверное все же можно использовать, если есть гарантия, что альтернативных циклов не будет..
Еще один неочевидный ньюанс с таймерами (независимо от способа). Если в очереди потока стоит хотя бы одно необработанное сообщение от таймера (или явное для третьего варианта, либо неявные для вариантов 1 и 2) - то новое сообщение от таймера в очередь помещаться не будет. МS наверное это сделал специально, чтобы исключить забиение очереди необработанными сообщениями какого-то не в меру шустрого таймера по отношению к обработчикам остальных сообщений (или одного из них)... Этим ньюансом и объясняется то обстоятельство, что "таймер иногда тормозит"...
← →
Ihor Osov'yak © (2004-11-07 22:59) [20]2 [18] Defunct ©
Не нужно говорить, что мне делать - и я тогда не буду говорить, куда Вам следует идти.. (с).
В дополнение - научитесь читать внимательно и не искажать смысл однозначно написанных вещей.
← →
Defunct © (2004-11-07 23:14) [21]Ihor Osov"yak © (07.11.04 22:59) [20]
> В дополнение - научитесь читать внимательно и не искажать смысл однозначно написанных вещей.
Если вы заметили, то меня там неустроило высказывание:
> Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков..
Про что я специально переспросил в [8]. После чего вы приплели приоритеты потоков ядра в [9]. Соответственно я вам указал на неспособность аппаратных средств обеспечить точность 100нс даже для потоков ядра.
Поэтому мне последнее ваше высказывание [20] крайне не понравилось.
Уважаемый Игорь, сейчас уже моя очередь послать вас за орбитом. Потому что, если после всего вы все еще считаете, что в посте в [6] все гладно, тогда нам просто не о чем разговаривать.
Так кто из нас невнимательно читает?
← →
Ihor Osov'yak © (2004-11-07 23:51) [22]> Соответственно я вам указал на неспособность аппаратных средств обеспечить точность 100нс даже для потоков ядра.
см. ниже.
Итак смотрим.
> После чего вы приплели приоритеты потоков ядра в [9].
Повторяю медленно - повышение приоритетов потоков в пользовательском режиме проблемы не снимает, так как всегда существуют потоки режима ядра, которые имеют все без исключения более высокий приоритет чем любой поток пользовательского режима с максимальным приоритетом. Мало того, часть этих потоков с уровнем выше PASSIVE_LEVEL никогда не прерываются для обслуживания пользовательских потоков (за PASSIVE_LEVEL не уверен, а сейчас поднимать документацию нет желания). Также, если в системе появляется поток с приоритететом выше PASSIVE_LEVEL (а это довольно часто при работе кода драйверов) - выполнение пользовательского потока прерывается незамедлительно. Отсюда вывод - время ожидания получения кванта времени пользовательским потоков очень сильно зависит от того, что происходит в коде режима ядра. То есть в коде, никак не подочетном коду нашего рабочего потока, который что-то там пытается делать с таймерами...
Все выше написанное илюстрирует тот тезис, что особо точно отслеживать временной интервал в специальном потоке не имеет смысла, так как непредсказуемость задержки на переключение пользовательских потоков значительно превышает ту якобы точность, что можно достичь всякими хитрыми решениями, о чем было сказано с упоминанием какого то кота и его хвоста..
> Соответственно я вам указал на неспособность аппаратных средств обеспечить точность 100нс даже для потоков ядра.
Повторяю еще раз. Я вел речь о дискретности интервала программирования временных задержек. Но никак не о точности. Если Вы не видите различия между дискретностью и точностью - то я в лучшем случае могу посоветовать почитать книжки.
Теперь смотрим еще раз [11]. Здесь Вы почему то вытащили платформу, совершенно не имеющую отношения к тому, что я говорил в контексте дискретности величиной в 100 наносекунд.
О чем я пытался обьяснить в дальнейших постингах.
> Соответственно я вам указал на неспособность аппаратных средств обеспечить точность 100нс даже для потоков ядра.
Где? Там, где было упомянута платворма на 8088? Я повторяю раз наверное уже четвертый - к контексту разговора о 100 наносекундном интервале эта платформа не имеет ни малейшего отношения.
>все еще считаете, что в посте в [6] все гладно
я это не считаю. Я знаю, что дело обстоит именно так. Знаю на основании изучения соотв. документации на архитектуру системы, на программное и аппаратное обеспечение, а также некоторых практических экспериментов.
> Так кто из нас невнимательно читает?
Попробуйте угадать..
Да, еще. Лично мне глубоко безразлично Ваше мнение по этому вопросу. На сем дискуссию с Вами оканчиваю.
← →
GuAV © (2004-11-07 23:56) [23][17] - никто не знает ?
← →
Defunct © (2004-11-08 00:35) [24]Удалено модератором
Примечание: Бех грубостей
← →
Ihor Osov'yak © (2004-11-08 00:43) [25]2 [17] GuAV © (07.11.04 22:38)
> Она вызывается не при обаботке сообщений а в любой момент.
Думаю, что это не так. Подозреваю, что вызов процедуры таймера происходит с помощью механизма APC, то есть в контексте потока, создавшего соотв. таймер и во время вызова либо какой-то функции выборки сообщения, либо во время тревожного ожидания на WaitForXXX и, возможно, sleepEx в состоянии Alertable.. Но это догадки. В литературе внятного изложения этого вопроса не встречал, впрочем особо и не искал - так как пока не было практической необходисости штудировать этот вопрос...
Можете сделать тестовое приложение и проанализируете контекст потока, в котором будет вызвана процедура и сравните с потоком, который создавал таймер... Также можно сделать логирование самой процедуры и мест, непосредственно перед и после функций работы с очередью и функций тревожного ожидания (и sleepEx?)...
← →
Ihor Osov'yak © (2004-11-08 00:55) [26]2 Defunct
Большая просьба - не занимайтесь интерпритацией моих высказываний. Я вас на это не уполномачивал. Это во первых. А во вторых еще и потому, что вы несете ахинею.
← →
GuAV © (2004-11-08 01:06) [27]Ihor Osov"yak © (08.11.04 0:43) [25]
Думаю, что это не так. Подозреваю, что вызов процедуры таймера происходит с помощью механизма APC, то есть в контексте потока, создавшего соотв. таймер и во время вызова либо какой-то функции выборки сообщения
Очень похоже. Без очереди сообщений (в безоконном приложении) такой таймер оказывается не работает. ThreadId тот же. с GetThreadContext что делать - не знаю...
← →
Defunct © (2004-11-08 01:08) [28]Ihor Osov"yak © (08.11.04 00:55) [26]
Просьба будет исполнена.
Я просто выскажусь как надо, без всяких интерпретаций.
Точность прораммного таймера 100нс в Windows не может быть достигнута не только из-за неизвестного интервала задержки между переключениями потоков, но и из-за ограничений аппаратных средств системы: аппаратный системный таймер всего один, работает всегда с одинаковой частотой, которая не превышает 1.13Mhz (мининимально возможный гарантированный временной интервал 1mks)..
← →
KilkennyCat © (2004-11-08 01:09) [29]
> Ihor Osov"yak © (07.11.04 23:51) [22]
значит, все-таки можно написать очень точный таймер с очень малым интервалом? например, как драйвер. Естественно, что события невозможно, получается, реально отобразить, но зарегистрировать и обработать в последствии вполне реально. То есть, можно написать свой собственный драйвер параллельного порта, который регистрирует свое состояние. После всего окончания процесса регистрации, идет дальнейшая обработка.
Я сделал правильный вывод? если да, то в принципе, можно сделать много интересных нереалтаймных вещей...
← →
KilkennyCat © (2004-11-08 01:13) [30]
> Defunct © (08.11.04 01:08) [28]
а вот с этим уже я не соглашусь... не обязательно использовать данный аппаратный таймер. Думаю, есть другие способы отсчитать промежуток времени.
← →
Defunct © (2004-11-08 01:21) [31]KilkennyCat © (08.11.04 01:09) [29]
Очень точный таймер написать можно, который будет выдавать абсолютно ровные осцилограммы. У нас в одном из проектов системный таймер использовался для синхронизации в программной реализации многоканального последовательного интерфейса (параллельный порт работал как 8 последовательных портов).
← →
Defunct © (2004-11-08 01:24) [32]KilkennyCat © (08.11.04 01:13) [30]
нет никаких других методов.
Есть система прерываний
IRQ0 - канал таймера, вот он и дергается периодически, прерывая выполнение текущего потока и передавая управление ядру системы - планировщику, который решает кому отдать управление.
← →
KilkennyCat © (2004-11-08 01:36) [33]
> Defunct © (08.11.04 01:24) [32]
совсем никаких? предположим, тупой цикл, который постоянно генерирует событие таймера. В идеале, если ничего другое не работает, скорость работы данного таймера превысит 1 МГц аппаратного. и нехило превысит. Или я ошибаюсь?
← →
Defunct © (2004-11-08 01:47) [34]KilkennyCat © (08.11.04 01:36) [33]
> совсем никаких? предположим, тупой цикл, который постоянно генерирует событие таймера. В идеале, если ничего другое не работает, скорость работы данного таймера превысит 1 МГц аппаратного. и нехило превысит. Или я ошибаюсь?
Так можно, но не забывайте, аппаратный таймер будет все равно крутиться, и будет прерывать ваш цикл, что внесет очень серьезную погрешность, порядка 1-99%!!! взависимости от используемого железа и от количества потоков в системе, приоритет которых равен или выше приоритета вашего потока в котором вы собираетесь крутить цикл.
В идеале, нужно с правами ядра перехватывать IRQ0 (вот тогда у вас будет действительно точный таймер), или повесить какое-то внешнее устройство синхронизации, по прерыванию от которого будет увеличиваться или уменьшаться значение какого-то вашего счетчика.
← →
KilkennyCat © (2004-11-08 01:51) [35]Как вы заметили, с помощью функции QueryPerformanceFrequency мы определяем частоту на входе счетчика таймера, а затем вычисляем величину, обратную частоте, то есть период импульсов в мкс (переменная sngUnit), после чего показания счетчика и его приращения переводим в доли секунды (мкс). Жмем на кнопку CmdPerformanceCounter, и наши труды вознаграждены ( Рис. 3) — мы получили приращения, равные приблизительно 5 мкс, причем частота счетчика таймера составляет 1193180 Гц при работе в Windows 9x/Me. Перейдя в Windows 2000/XP, получим приращения порядка 2.0—2.5 мкс при частоте 3579545. Да, и впрямь high resolution timer!
это отсюда - http://www.mycomputer.ua/text/6406;jsessionid=1C4E5BF46E1D64ACC37F7E80EE51030C
← →
KilkennyCat © (2004-11-08 01:52) [36]
> Defunct © (08.11.04 01:47) [34]
однако, теоретически, я могу учесть все погрешности. Но, если это так, то проще отказаться от программирования в пользу электроники
← →
Defunct © (2004-11-08 01:57) [37]KilkennyCat © (08.11.04 01:36) [33]
Нарисую временную диаграмму работы системы для всего 6-ти
потоков и ядра, чтобы все вам стало понятно.
Обозначу:
Ваш поток - буквой X
Ядро систмы - Я
Потоки с равным приоритетом - E
потоки с более высоким приоритетом - H
Итак:
^
|XЯHHHHEEXЯHHHEEXЯHHHEEXЯ
|______________________________________________________
По оси X процессорное время.
По оси Y - выполняемый поток
Там где выполняется Я - соответствует прерыванию от аппаратного таймера (IRQ0)
Итого, как видите ваш поток будет получать какие-то остатки общего процессорного времени, о какой тут точности можно говорить?
← →
Defunct © (2004-11-08 02:01) [38]> однако, теоретически, я могу учесть все погрешности.
не можете.
Такой тривиальный случай - Вася Певченко начал скачивать с вашего компьютера музыку по сети и все ваш таймер получает погрешность 20-50%
← →
KilkennyCat © (2004-11-08 02:04) [39]теперь я еще больше запутался... получается, что скорость работы процессора совершенно не важна при выполнение только одной задачи? , то есть, простая программка, предположим, выполняющая просто одну тупую операцию, будет работать одинаково на пне 166 и на пне-4 3 ГГц?
← →
KilkennyCat © (2004-11-08 02:05) [40]
> Defunct © (08.11.04 02:01) [38]
если теоретически, то учитывание погрешностей подразумевает и максимальное предотвращение их появления.
← →
Defunct © (2004-11-08 02:13) [41]KilkennyCat © (08.11.04 02:04) [39]
От процессора зависит, сколько команд для конкретного потока он успеет обработать за отведенное время.
Вот если взять диаграмму [37] и выполнить на двое более быстром процессоре, будет уже такая картинка:
^
|XЯHHEXXXXЯHHEXXXЯHHEXXXЯ
____________________________
Ну а если убить ваш поток с циклом - получим свободное процессорное время.
Конечно же то что я здесь рисую, очень упрощено, я не учитываю возврат управления Ядру процедурой Sleep.
> выполняющая просто одну тупую операцию, будет работать одинаково на пне 166 и на пне-4 3 ГГц?
Нет конечно же нет, от скорости процессора зависит, еще раз повторюсь, количество команд выполненных в секунду. А системный таймер работает-то одинаково.
← →
Ihor Osov'yak © (2004-11-08 02:13) [42]2 [29] KilkennyCat © (08.11.04 01:09)
вопрос спорный. Собственно таймер, дергающий соотв. аппаратное прерывание действительно не может быть запрограммирован на довольно высокую частоту, следовательно дискретность отсчета высокой быть не может.. Но с другой стороны - в процессорах начиная c Pentium есть такая вещь, как TSC - time stamp counter - обычный 64 битный регистр, считающий каждый тик тактовой частоты процессора и доступный по чтению (ОС может запретить доступность для пользовательского режима, и это, кажется, так и делается). С его помощью можна делать довольно точные временные задержки.. На уровне нескольких тактов процессора. Или измерять довольно точно интервалы времени.. А относительно таймера в классическом понимании - не уверен..
С другой стороны мs все же на уровне апи ядра дискретность временных интервалов установила в 100 наносекунд. Насколько точно будут срабатывать всякие KeSetTimer - не интересовался.. То ли там действительно есть такая точность ( что вряд ли - так как точный подвод можно сделать наверное только на основании чтения в цыкле TSC на завершальных стадиях ожидания ценой блокировки остальных потоков - а это маловероятно), то ли МS просто сделала запас на развитие аппаратной платформы - не могу сказать..
Но вот что измерения интервалов на основании TSC - довольно точное - то это таки факт.. Мне приходилось делать измерение некоторых интервалов времени в драйвере -фильтре с помощью KeQueryPerformanceCounter (которая в конечном итоге читает TSC) - то похоже на то, что действительно получается довольно точный результат..
← →
KilkennyCat © (2004-11-08 02:23) [43]ну, вообщем, все и вся еще раз доказали, что серъезные задачи решаются серъезными вещами. Я попозже покопаюсь во всем этом, ветку сохранил, и попытаюсь разобраться. Очень бы хотелось сделать возможным создание многоканального мониторинга быстрых процессов... интересно как и с моральной точки зрения, так и с материальной.
> Ihor Osov"yak © (08.11.04 02:13) [42]
TSC - я ведь слышал об этом... да забыл. Спасибо, за напоминание.
← →
Ihor Osov'yak © (2004-11-08 02:29) [44]2 [27] GuAV © (08.11.04 01:06)
>ThreadId тот же. с GetThreadContext что делать - не знаю...
я имел ввиду ThreadId. ThreadContext - оговорка..
... судя с Ваших слов моя версия правильная. Возьму во внимание, со временем наверно найду где-то подтверждение в соотв. литературе..
← →
Ihor Osov'yak © (2004-11-08 02:35) [45]2 [43] KilkennyCat ©
помнится, также в контекте пентиум 2 про проскакивало также сообщение о таймере, встроенном в ядро процессора - local APIC - не знаю, сохранилась ли эта фишка в PIII и далее, а также как дела с этим в K7 - я в общем то не специалист в современном аппаратном обеспечении, так, иногда прохожу мимо :-)
← →
Defunct © (2004-11-08 02:37) [46]Ihor Osov"yak © (08.11.04 02:13) [42]
ЗЫ, а по TSC кажется нет механизма генерации аппаратного прерывания при переполнении. так что его можно использовать в целях таймера только либо в совокупности с отладочным режимом либо просто опросом. (от проца будет такой таймер сильно зависеть, а добавить сюда всякие нововведенные D.O.T. (Dynamic Overclocking Tech") так вообще получается никакой точности (даже если синхронизировать по IRQ0).
← →
KilkennyCat © (2004-11-08 02:43) [47]
> Ihor Osov"yak © (08.11.04 02:35) [45]
и это самое ужасное... мне и так хватило головной боли сидеть в москве неделю, когда выяснилось, что прога, написанная для амд, не живет на интелле...
← →
KilkennyCat © (2004-11-08 02:47) [48]
> Defunct © (08.11.04 02:37) [46]
разве такты процессора менее точны? на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
Опрос нечем не хуже прерывания, меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.
← →
Ihor Osov'yak © (2004-11-08 02:54) [49]2 [46] Defunct © (08.11.04 02:37)
> а по TSC кажется нет механизма генерации аппаратного прерывания
а я что, утверждал что есть?
это я намек на способность внимательно читать.
>при переполнении
64 бита довольно трудно перемолнить, имхо..
> от проца будет такой таймер сильно зависеть, а добавить сюда всякие нововведенные D.O.T.
если посмотреть внимательно на декларацию KeQueryPerformanceCounter, то можно заметить еще один возвращаемый параметр - OUT PLARGE_INTEGER PerformanceFrequency - количество тиков в секунду на момент выполнения вызова функции - это не тему разных тактовых частот.. А относительно всяких D.O.T. - то на время измерения их вполне можно и отключить.
← →
Ihor Osov'yak © (2004-11-08 02:56) [50]> меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.
вполне может быть - и даже при определенных обстоятельствах оптимальние - ведь обработка прерывания довольно ресурсоемкая операция..
← →
KilkennyCat © (2004-11-08 02:58) [51]
> Ihor Osov"yak © (08.11.04 02:54) [49]
даже если бы PerformanceFrequency не было, разные тактовые частоты можно и предварительной юстировкой определить...
← →
Defunct © (2004-11-08 02:59) [52]KilkennyCat © (08.11.04 02:47) [48]
> разве такты процессора менее точны?
Знаете что такое D.O.T.?
Это, например, у вас процессор P4-3.0, а в виндовсе частота процессора пляшет от 2.6Ghz до 3.8Ghz взависимости от загруженности процессора. Ну и что вам даст подстчет тактов скажем 3.6 Гтактов, это больше секунды или меньше или равно?
(Мы даже еще на другой комп программу переносить не будем, а она будет уже неправильно работать)
> на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
no-comment ;>
было бы все так просто уже б давно были процессоры с бесконечной частотой, но вот есть одна маленькая проблемка - чем выше частота, тем меньше стабильность электроники из-за вихревых токов (приходится усовершенствовать технологический процесс, понижать напряжение питания и т.д., короче масса проблем).
> Опрос нечем не хуже прерывания,
плохо вас учили. Таких учителей надо наказывать.
Прогр. опрос - 1-ое поколение машин.
Прерывания - 3-е поколение машин.
← →
Defunct © (2004-11-08 03:08) [53]> это я намек на способность внимательно читать.
ок
> 64 бита довольно трудно переполнить
логично, ~2^32 секунд ;>
> PerformanceFrequency
не доверяю я таким штукам. погрешность очень высока.
> А относительно всяких D.O.T. - то на время измерения их вполне можно и отключить
Согласен.
imho все же лучше не использовать виндовс и ее программные средства для организации задержек с точностью менее 10ms.
← →
KilkennyCat © (2004-11-08 03:09) [54]
> Defunct © (08.11.04 02:59) [52]
я не знаю про ДОТ, не сталкивался. Но предполагаю, что изменение частоты процессора изменяется по вполне жестким законам, отследить или менять которые вполне по силам.
гм... не путайте стабильность различную... разве я говорил о стабильности самих электрических процессов? Почему в электронных часах не используют генератор с частотой 1 Гц, хотя это удобно?
Мои учителя, извините, намного умнее Вас. Я ведь не утверждал, что они абсолютно запрещали ипользовать прерывания. Тем более, что они работали не только с ПК, но и с другими представителями вычислительной техники...
И к поколениям машин они не привязывались. Они привязывались к удобным способам решения кокретной задачи. Под "удобным" понимается надежность, оптимальность и прочее...
← →
Defunct © (2004-11-08 03:24) [55]> я не знаю про ДОТ, не сталкивался. Но предполагаю, что изменение частоты процессора изменяется по вполне жестким законам, отследить или менять которые вполне по силам.
Да по вполне жестким законам китайских разработчиков:
- Загрузка процессора 100% - повышаем частоту плавно.
- Загрузка процессора 0% - снижаем частоту плавно.
какой же тут четкий закон для динамики?
> гм... не путайте стабильность различную... разве я говорил о стабильности самих электрических процессов? Почему в электронных часах не используют генератор с частотой 1 Гц, хотя это удобно?
Я вам объясню. Потому что RC-цепочка для обеспечения 1 Гц потребует электролит, и соответственно часы увеличатся в размере. Вот и взяли за основу частоту 32768 Гц для часов, которая обеспечивание маленьким кварцевым резонатором.
Выражайтесь нормально, потому что эта фраза
> на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
трактуется однозначно.
> Мои учителя, извините, намного умнее Вас.
Как вы определили? Не потому ли, что они не заходят на этот форум? ;)
> Я ведь не утверждал, что они абсолютно запрещали ипользовать прерывания.
Этого вы не утверждали, но зато сказали
> Опрос нечем не хуже прерывания, меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.
Эта фраза полный бред, и если вас учили тому что вы здесь написали, то таких учителей надо просто уволить.
В режиме прерываний программа прерывается ровно в момент происхождения события, а при программном опросе вы можете одно из двух либо пропустить событие либо потратить процессорное время на ожидание события.
> Тем более, что они работали не только с ПК, но и с другими представителями вычислительной техники...
С калькуляторами?
← →
KilkennyCat © (2004-11-08 03:48) [56]
> Defunct © (08.11.04 03:24) [55]
как однако вы все извращаете... ну ладно, я тоже поизвращаюсь.
я не понимаю плавных понижений частоты. или китайцы используют аналогыве процессоры?
можно сделать RC-цепочку и без электролита. можно и LC. но это не суть важно. почему использована частота и в кварце 32768 Гц? из-за размеров? нет, могу подарить малюсенький кварц на 1 кгц.
фразы трактуются по-разному. мы обсуждали точность работы таймера.
при чем здесь этот форум и то, что мои учителя умнее? Как мне это трактовать? Что я считаю, что все сюда ходящие - глупее? нет, не считаю. Просто они стояли у основ электроники. Не хватали поверхностно, и знания их фундаментальны. Не думаю, что Ваш возраст равняется ихнему.
Да, я выразился, что опрос предпочтительнее прерывания. И сказал, что меня так учили. Поясните мне, почему я не прав, а заодно и ложно мое обучение, а не увольняйте моих учителей :) Хотя, они вообще-то и так уже на пенсии.
о, вот и обяснение...
> В режиме прерываний программа прерывается ровно в момент
> происхождения события, а при программном опросе вы можете
> одно из двух либо пропустить событие либо потратить процессорное
> время на ожидание события.
замечательно. может, Вы все-таки соблаговолите расписать весь процесс прерывания, а заодно для нескольких устройств, скажем так, для двадцати. Люблю я многоразрядные шины... лучше, пущай у нас на компе будет 32 устройства. Воткнуты все в PCI. Как тут прерывания поработают? только подробно, пожалуйста, с учетом всех действий процессора, по сохранению того, что до прерывания было и восстановлением после.
И какое время на ожидание события? Вы же, если придираетесь к словам, то придирайтесь дальше - я ведь написал "старатся знать, когда надо опрашивать".
С калькуляторами? Любезный, ежели б Вы в те времена сумели бы разработать калькулятор, я бы снял перед Вами шляпу.
И вообще, Ваша агрессивность - это просто попытка скрыть что-то... Может, просто боитесь показаться в чем-то недостаточно образованным?
← →
KilkennyCat © (2004-11-08 03:54) [57]P.S. руководствуясь поговоркой, что спорят только подлецы и дураки (дурак - потому что проспорит, но все равно спорит, подлец - знает, что прав, но все равно спорит), спорить дальше не буду. Не хочу оказаться подлецом.
← →
Defunct © (2004-11-08 04:58) [58]Эх.. уйдет эта ветка похоже в потрепаться..
> фразы трактуются по-разному. мы обсуждали точность работы таймера.
Ах вот оно что. Кто бы мог подумать. Скажу вам честно я понял эту фразу
> на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
применительно ко всей электронике, вчастности и к процессорам тоже, потому что никаких оговорок вы нигде не указали.
> при чем здесь этот форум и то, что мои учителя умнее? Как мне это трактовать?
трактуйте как угодно.
я же вас не спрашивал как мне трактовать это:
"Мои учителя, извините, намного умнее Вас",
более того могу сказать, что у меня были учителя глупее Вас.
> Просто они стояли у основ электроники. Не хватали поверхностно, и знания их фундаментальны. Не думаю, что Ваш возраст равняется ихнему.
Скажите, вы вообще на какой волне? Я говорил об архитектуре вычислительных систем, именно там есть понятия режим программного опросаи режим прерываний, в электронике этих понятий нет. Я ничего не имею против ваших учителей как светил электроники. Но скажите почему вы вспомнили о них применительно совсем к другой области науки?
> Вы все-таки соблаговолите расписать весь процесс прерывания, а заодно для нескольких устройств, скажем так, для двадцати.
Скажем так.
В теории есть 3 метода организации контроллера прерваний.
1. Централизованный (микросхема/ы КПП).
2. Децентрализованный (дейзицепочка).
3. Гибридны (комбинацие первых двух).
В x86 применяется централизованный двухуровневый контроллер. Распишу по приоритетам 0-наивысший приоритет, дальше IRQ расположены по-убыванию:
IRQ0 - таймер
IRQ1 - клава
IRQ2 -> cascade -> (сюда подключен второй уровень)
< cascade >
IRQ8 - PCI
IRQ9 - PCI
IRQ10 - PCI
IRQ11 - PCI
IRQ12 - PCI
IRQ13 - FPU
IRQ14 - HDD
IRQ15 - HDD
[IRQ16] - опционально
.. - опционально
[IRQ23] - опционально
</cascade>
IRQ3 - com2/4
IRQ4 - com1/3
IRQ5 - ISA или lpt2
IRQ6 - Если не изменяет память - для используется для реген. памяти.
IRQ7 - Lpt1
Централизованный контроллер имеет место в архитектуре x86 и работает так:
1. От внешних устройств (ВУ) приходят запросы на прерывание (IRQ). Контроллер приоритетных прерываний (КПП) складывает по Or все запросы на прерывание (IRQ) и выдает процессору сигнал INT.
2. Процессор при получание сигнала INT завершеет текущую команду и приостанавливает выполение текущей программы, считывает с КПП вектор самого высокоприоритетного прерывания (приоритет определяется по IRQ, для централизованного контроллера приоритеты фиксированы) сохраняет текущий адрес CS:IP и регистр состояния программы Flags/FlagsD и переходит по адресу вектора. 3. Обрабатывается событие.
5. Контроллеру прерываний посылается сигнал EndOfInt, соответственно выключается (переводится в 0) самый приоритетный сигнал IRQ.
4. Восстаналивается сохраненный адрес прерванной программы, и регистр состояния программы.
Ну и работаем себе дальше, только событие уже обслужено. Не надо ничего ждать, ничего опрашивать.
> только подробно, пожалуйста, с учетом всех действий процессора, по сохранению того, что до прерывания было и восстановлением после.
Могу конечно, рассказать подробно, но только если вы хотите качественный ответ, то дучше подождать до завтра. Ибо уже 4 часа ночи, да и рисунки тут очень трудно рисовать.
> С калькуляторами? Любезный, ежели б Вы в те времена сумели бы разработать калькулятор, я бы снял перед Вами шляпу.
Значит я угадал.
Очень хочу спать, хотел и здесь вам возразить, но уж ладно как-нибудь потом, а то в голове просто кашмар какой-то (ни одной мысли).
> И вообще, Ваша агрессивность - это просто попытка скрыть что-то...
Возможно. А возможно так действует уходящее воскресенье.
> Может, просто боитесь показаться в чем-то недостаточно образованным?
Да нет, я наоборот могу сам сказать, что толком ничего не знаю. И совсем не стыжусь этого.
PS: допускаю, что в этом посте могут быть логические несоответствия.. пора спать..
← →
Defunct © (2004-11-08 05:02) [59]Удалено модератором
← →
KilkennyCat © (2004-11-08 05:10) [60]ладно, предлагаю замять.. что-то я тоже слишком эмоционален стал... да идействителдьно, возможно шоры электроники мешают, ибо я вообще считал, что есть три способа получения информации от устройств - прерывание, опрос и прямой доступ к памяти.
А почему воскресенье уходящее? Парздник же еще будет... так что сегодня - выходной.
← →
KilkennyCat © (2004-11-08 05:13) [61]а вообще, спешка и эмоции в данных случаях - вредная вещь. надо изживать.
← →
Defunct © (2004-11-08 05:14) [62]KilkennyCat ©
Я наконец-то понял что ваши учителя вам говорили, но вы этого похоже не поняли.
Если выбросить первую часть фразы:
> "Опрос нечем не хуже прерывания,"
выбросить так далеко как только можно.
то вторая часть фразы получается впоне корректой, и в ней как раз говорится про режим прерываний.
меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.
Как можно узнать когда опрашивать?
ответ очевиден:
по факту возбуждения прерывания.
← →
Defunct © (2004-11-08 08:19) [63]> что есть три способа получения информации от устройств - прерывание, опрос и прямой доступ к памяти.
да все вы правильно считаете именно 3 способа. Мы просто не затрагивали DMA
> А почему воскресенье уходящее? Парздник же еще будет... так что сегодня - выходной.
Дык, в нашей стране Янукович пока Президентом не стал. Вот как будет он президентом так и к нам праздник вернется. А пока 7 Ноября обычный будний день.
> а вообще, спешка и эмоции в данных случаях - вредная вещь.
угу
← →
KilkennyCat © (2004-11-08 10:18) [64]
> Defunct © (08.11.04 05:14) [62]
хорошо, ну а предположим такой вариант: данные, которые я должен получать, мне нужны только тогда, когда я их забираю. То есть, я читаю какой-либо порт, обрабатываю данные, и вывожу на порт команду внешнему устройству на обновление. Выгодно ли тогда прерывание? С точки зрения оптимальности и простоты программирования?
или такой вариант: я уже знаю, что скорость посылки данных настолько высока, что я в любом случае что-то потеряю. Ведь тогда простой опрос позволит получить больше?
З.Ы. Я не спорю, я спрашиваю :)
← →
Cobalt © (2004-11-08 12:57) [65]2 KilkennyCat © (08.11.04 10:18) [64]
> Выгодно ли тогда прерывание? С точки зрения оптимальности и простоты программирования?
1) Скорости жестко задаются, как правило, в электронике. В PC - скорость - несколько размытое понятие, т.к. он многозадачный.
Смотри - Прерывание:
* 1) Принимаешь сигнал от порта, читаешь из него.
2) Посылаешь в него команду пересылки новых данных
* 3) Принимаешь следущие данные. И т.д.
Опрос:
* 1) Принимаешь сигнал от порта, читаешь из него.
2) Посылаешь в него команду пересылки новых данных
3) Принимаешь следущие данные. (какова задержка между 2 и 3? в PC очень трудно гарантировать. И эту задержку тебя все остальные должны ждать? А сколько у тебя будет таймаут?)
* прерывание
← →
Piter © (2004-11-08 14:19) [66]Ihor Osov"yak © (07.11.04 22:54) [19]
так как отложенный вызов процедуры таймера вероятнее всего делается где-то в глубине getmessage или ему подобных
Цитата:
"When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure"
Defunct © (08.11.04 1:08) [28]
Точность прораммного таймера 100нс в Windows не может быть достигнута не только из-за неизвестного интервала задержки между переключениями потоков, но и из-за ограничений аппаратных средств системы: аппаратный системный таймер всего один, работает всегда с одинаковой частотой, которая не превышает 1.13Mhz (мининимально возможный гарантированный временной интервал 1mks)..
по-моему, очень логично. Если все сказанное правда - я не понимаю, почему Ihor Osov"yak пишет:
Ihor Osov"yak © (08.11.04 0:55) [26]
во вторых еще и потому, что вы несете ахинею.
← →
KilkennyCat © (2004-11-08 14:27) [67]
> Cobalt © (08.11.04 12:57) [65]
> 3) Принимаешь следущие данные. (какова задержка между 2
> и 3? в PC очень трудно гарантировать. И эту задержку тебя
> все остальные должны ждать? А сколько у тебя будет таймаут?)
в большинстве случаев я могу знать скорость реакции устройства на запрос данных. Почему меня нельзя ждать? Предположим, я просто регистрирую состояние какого-лтбо объекта через определенный промежуток времени. Мне не важно, что было в этом промежутке, мне важно состояние в момент опроса. Ну, практическая задача: синхронизация программных часов по внешнему высококоточному таймеру. Причем, программа делает что-то очень важное, ее нельзя дергать, то есть, приоритет ее основной работы выше. Есть возможность - она синхронизируется. Нет - извините. В случае прерываний, получается, что она должна все равно отвлечься, чтобы сказать - не до тебя сейчас, занята я.
← →
GuAV © (2004-11-08 14:27) [68]Piter © (08.11.04 14:19) [66]
DispatchMessage
Cпасибо. Не знаю почему я этого не нашел :(
← →
KilkennyCat © (2004-11-08 14:34) [69]ааааааа!
слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)
← →
Ihor Osov'yak © (2004-11-08 15:25) [70]2 [66] Piter © (08.11.04 14:19)
>так как отложенный вызов процедуры таймера вероятнее всего делается где-то в глубине getmessage или ему подобных
>When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure
я рассматривал случай, когда таймер SetTimer получает нулевой хендл окна. То есть здесь говорить о процедуре окна не следует. Во вторых, я делал предположение, что вызов процедуры таймера делается в контексте потока, создавшего таймер, и в общем случае для этого задействуются механизмы, подобные на APC - а когда эти механизмы активируются - вопрос совершенно иной..
> почему Ihor Osov"yak пишет:
>>во вторых еще и потому, что вы несете ахинею.
хотя бы потому, что человек в упор не замечает, что я говорю об дистретности программирования временных интервалов, а не об точности.
а во вторых, из за наличия уж многих шедевров вида
"который всего один и неспособен выдавать синхроимпульсы с частотой 10Mhz для всех потоков.." Интересно, что это за ноу-хау в архитектуре, способное передвать "синхроимпульсы" потокам? И какова физика этого ноу-хау.
Зы. я уже молчу о продемонстрированном незнании тематики о приоритетах потоков..
2 [69] KilkennyCat © (08.11.04 14:34)
>слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)
а вот это уже зависит от архитектуры конкретного решения. Вот, возьмем к примеру шину USB. Синхронизация общения между хост-контролером и устройствами, подключенными к USB шине идет как раз способом опроса, а не прерываний...
Или та же клавиатура, но внутри.. Опрос клавиш все же идет сканированием контролером клавиатуры. Прерывания - это уже на системной плате, после того как пришел сигнал от конролера клавиатуры.. То есть в случае клавиатуры имеем комбинацию - опрос и прерывание. Опрос на уровне дешевого и простого контролера, входящего в состав клавиатуры, и прерывание - это уже когда нужно привлечь внимание дорогого и постоянно занятого ЦП в случае реального ввода кода нажатой клавиши..
← →
KilkennyCat © (2004-11-08 15:31) [71]
> Ihor Osov"yak © (08.11.04 15:25) [70]
спасибо, в принципе я так и думал ведь...
← →
Piter © (2004-11-08 16:05) [72]Ihor Osov"yak © (08.11.04 15:25) [70]
я рассматривал случай, когда таймер SetTimer получает нулевой хендл окна. То есть здесь говорить о процедуре окна не следует
а кто говорит о процедуре окна? Вы предположили, что вызов TimerProc происходит где в недрах GetMessage, а я говорю, что он происходит где-то в недрах DispatchMessage, что логично, ибо приложение может и не пользоваться GetMessage, а использовать PeeMessage :)
← →
Ihor Osov'yak © (2004-11-08 16:32) [73]2 [72] Piter © (08.11.04 16:05)
>а кто говорит о процедуре окна?
блин, ну хоть то, что цитируем сами, читать то можно?
см. [66] Piter © (08.11.04 14:19)
>"When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure"
← →
Piter © (2004-11-08 18:11) [74]Ihor Osov"yak © (08.11.04 16:32) [73]
А, ты про это. Ну ладно... все равно не понимаю о чем мы говорим. Я своим постом хотел сказать одно - что вызов TimerProc происходит при вызове DispatchMessage - вот и все. Ты предполагал, что при вызове GetMessage или подобном, я же уточнил. Это все, что я хотел сказать :)
← →
Defunct © (2004-11-08 18:38) [75]Удалено модератором
← →
Defunct © (2004-11-08 19:25) [76]KilkennyCat © (08.11.04 14:34) [69]
> слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)
Ок.
Для того чтобы сказать в каких случаях следует использовать опрос, а в каких прерывание, достаточно рассмотреть преимущества и недостатки обеих режимов.
1. Режим программного опроса:
преимущества:
- простота реализации.
- как следствие простоты - отсутствие дополнительных схемных решений.
недостатки:
- потеря процессорного времени на ожидание событий
- возможность потери события в случае опроса нескольких устройств.
2. Режим прерываний
преимущества:
- возможность отделения операций ввода/вывода от выполнения основной программы
- запуск подпрограммы обслуживания ввода/выода по факту появления и/или требования данных ВУ.
недостатки:
- сложность реализации.
- как следствие необходимость использования дополнительных схемных решений.
Итак, программный опрос выгодно использовать в дешевых устройствах с простым процессором.
Во всех остальных случаях целесообразнее применять режим прерываний.
← →
Defunct © (2004-11-08 19:39) [77]> хорошо, ну а предположим такой вариант: данные, которые я должен получать, мне нужны только тогда, когда я их забираю. То есть, я читаю какой-либо порт, обрабатываю данные, и вывожу на порт команду внешнему устройству на обновление. Выгодно ли тогда прерывание?
Конечно, если спецификация устройства с которым вы работаете способна обеспечивать хранение данных сколь угодно долго тогда безусловно можно обойтись опросом.
Но как правило ВУ неспособны долго хранить данные. Давайте рассмотрим на примере всем известного COM порта:
COM порт - медленное устройство.
Если использовать режим опроса, тогда быстрый процессор будет все время ждать. Если же опрашивать через определенные интервалы времени, то не исключается возможность ситуации, когда принятый байт COM порта будет затерт следующий принятым байтом.
В режиме же прерываний, сам COM порт просигнализирует процессору о приходе байта, таким образом достаточно будет просто сразу взять и прочитать этот байт, потеря данных исключается и нет никакого ожидания.
← →
Piter © (2004-11-08 20:09) [78]мне вот тоже кажется, что Ihor Osov"yak ругался и обзывал ламером Defunct"а из-за утверждения, с которым сам потом и согласился. Я про:
Ihor Osov"yak © (07.11.04 19:34) [6]
ну, еще бы на уровень 0 прыгнуть, там отсчет доступен с дискретностью 100 наносекунд :-).
Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков
ни слова о неточности самого аппаратного таймера
Ihor Osov"yak © (07.11.04 22:16) [13]
я не говорил, что речь идет о системе на базе 8086/8088. Что это не так, можно было бы догадаться хотя бы по упоминанию режима ядра. То есть, что речь идет как минимум о 386
эта фраза я так понимаю подразуемвает то, что в 386 отсчет временных интервалов точнее. При этом фраза:
Defunct © (08.11.04 0:35) [24]
системный таймер не изменялся. как был 1.3Mhz или точнее сказать 1.13Mhz так и остался
не была опровергнута. Более того, с ней вроде даже как согласились:
Ihor Osov"yak © (08.11.04 2:13) [42]
собственно таймер, дергающий соотв. аппаратное прерывание действительно не может быть запрограммирован на довольно высокую частоту
То есть, Ihor Osov"yak нигде не утверждал, что можно отсчитать точно промежутки времени по 100нс, но как минимум давал понять, что в современных компьютерах это можно сделать куда точнее, чем в 8086/8088 компьютерах. А, видимо, это не так. Таймер как был так и остался.
Спор то вообще ни о чем. Ihor Osov"yak говорил, что нельзя отсчитать точные промежутки времени из-за переключения потоков и из-за недостаточного приоритета пользовательских потоков по сравнению с потоками ядра. А Defunct говорит, что даже если все было бы в реальном времени, то отсчитать такие промежутки времени все равно нереально из-за ограничений аппаратного таймера.
Я так понял вашу дискуссию.
P.S. А насчет несдержанности Ihor Osov"yak - это да. Я тоже был удивлен его поведением, когда кто-то пытается доказать, что он не прав, искры летят налево и направо. Прямо удивительно для взрослого человека...
← →
Anatoly Podgoretsky © (2004-11-08 20:22) [79]Defunct © (08.11.04 02:37) [46]
При частоте прочессора на переполнение потруется порядка 600, для 3 ггц 200. Долго ждать придется
← →
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 и т.п. и поставили бы меня на место.
Ничего личного.
← →
Ihor Osov'yak © (2004-11-09 20:02) [109]2 Defunct ©
>Вы меня отправили пожевать непонятно почему и совсем не обоснованно в посте [13].
Вы приписали мне слова, которые я не говорил. В ответ последовал совет пожевать (с приведенной ниже по тексту аргументацией). Я считаю вполне адекватный для данного случая ответ.
> зачем обзывать меня ламером в [70]
Пожалуйста, цитату, где это я сделал в посте [70]. То, что там были сделаны выводы о вашей компетентности в некоторых вопросах - то были основания для этого.
← →
Ihor Osov'yak © (2004-11-09 20:08) [110]> Для чего вы вспылили в [9] после того как была упомянута лишь одна константа в
Абсолютно спокойный и аргументированный ответ, даже прелполагающий, что собеседник имеет некоторый уровеньквалификации, чтобы понять о чем речь.
> Согласитесь если бы я написал о Вас то же самое, вы бы тоже полезли в DDK, MSDN и т.п. и поставили бы меня на место.
Я уже раз просил не делать за меня выводы.
← →
Defunct © (2004-11-09 20:29) [111]> Вы приписали мне слова, которые я не говорил. В ответ последовал совет пожевать (с приведенной ниже по тексту аргументацией). Я считаю вполне адекватный для данного случая ответ.
Я ничего вам не приписывал.
Я просто сам сказал, помимаете сам, не искажая и не трогая вашего поста [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 подходит более чем.
> Я уже раз просил не делать за меня выводы.
Насколько мне не изменяет память вы просили не трактовать ваши слова. (и я вашу просьбу удовлетворяю).
← →
VMcL © (2004-11-09 20:43) [112]>>Defunct © (09.11.04 19:09) [105]
>Вы что так и не поняли
Я по Вашему читать не умею? Привожу еще раз:
Defunct © (09.11.04 08:12) [95]
VMcL © (09.11.04 07:59) [94]
> Что я делаю не так?
Вызываете не ту функцию.
>величина, возвращаемая QueryPerformanceFrequency, исчисляется в каких-то ничего не значащих попугаях.
Я не знаю, что Вам рассказывал Ваш учитель/преподаватель физики, но меня учили, что частота (frequency) измеряется в герцах, а не в "ничего незначащих попугаях", которыми удава измеряли в известном мультфильме.
← →
Ihor Osov'yak © (2004-11-09 20:50) [113]странный вы человек. Я говорил о дискретности, вы начали спич о точности. Вопроса точности я даже не затрагивал.
> Вы взяли мою цитату исказили в ней смысл так,
я не мог исказить смысла, так как цитирование я всегда делаю методом копирования. При желании - сделайте посимвольное сравнение.
> Может там что-то было написано неверно
я, кстати, не комментировал, что там верно, а что нет. я пытался обратить внимание на то, что вы сделали отход от темы. ТО есть начали вести речь о платформе, которая неприемлимая в контексте разговора о режиме ядра NT ряда. Я уже устал повторять это.
> Насколько мне не изменяет память вы просили не трактовать ваши слова. (и я вашу просьбу удовлетворяю).
Вы это сделали, как минимум, два раза. И оба раза некоректно.
Также позволю себе заметить, что за вами наблюдается способность уходить от прямых и конкретных вопросов, напоминаю еще раз - где конкретно в [70] я назвал вас ламером, о чем вы утверждаете в [108]. Вас в школе не учили, что лгать - плохо?
← →
Defunct © (2004-11-09 20:55) [114]VMcL © (09.11.04 20:43) [112]
Уважаемый VMcL, читайте [46] и [84] до полного просветления.
Я не намерен вести спор с вами непонятно о чем.
3 579 545
2 992 560 000
тут разница на 3 порядка.
О режиме программного опроса в этой ветке говорилось неоднократно. А также о D.O.T. Поэтому я не хочу тратить свое время на переливание из пустого в порожнее.
> что Вам рассказывал Ваш учитель/преподаватель физики, но меня учили, что частота (frequency) измеряется в герцах, а не в "ничего незначащих попугаях", которыми удава измеряли в известном мультфильме
Я очень уважаю своего бывшего учителя физики и прекрасно помню в чем меряется частота и что 1/Hz = сек.
← →
VMcL © (2004-11-09 21:00) [115]>>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 совпадают.
← →
VMcL © (2004-11-09 21:04) [116]>>Defunct © (09.11.04 20:55) [114]
>Я очень уважаю своего бывшего учителя физики и прекрасно помню в чем меряется частота и что 1/Hz = сек.
>величина, возвращаемая QueryPerformanceFrequency, исчисляется в каких-то ничего не значащих попугаях.
Так какое из этих 2-х мне выбрать, не менее уважаемый Defunct?
← →
Defunct © (2004-11-09 21:07) [117]> Также позволю себе заметить, что за вами наблюдается способность уходить от прямых и конкретных вопросов, напоминаю еще раз - где конкретно в [70] я назвал вас ламером
Признаю - нигде.
Поэтому вы тоже будьте добры не уходите от прямого вопроса и скажите, где именно я показал некомпетентность в тематике о приоритетах потоков?
Спасибо за приятный разговор.
Скажу честно, мне принесло много удовольствия участие в этой ветке.
← →
Anatoly Podgoretsky © (2004-11-09 21:07) [118]lpFrequency
Points to a variable that the function sets, in counts per second, to the current performance-counter frequency.
← →
VMcL © (2004-11-09 21:11) [119]>>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.
← →
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)
особенно после проявления такого неуважения к затраченному времени:
> Кстати, я так и не дождался расшифровки крякозябликов из
> Даже если там и есть заблуждения (а я бы попросил указать на них конкретно), то не находите ли вы несколько наглым называть это ложью?
Нет уважаемый, после всего что вы тут мне наговорили, я считаю ЛОЖЬ это именно то слово, которое должно быть.
Вы позволили себе на ложном утверждении судить о моей компетенции.
← →
VMcL © (2004-11-10 12:19) [145]>>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
Если покажет всё-таки правильное значение, то тогда встает вопрос: как?
← →
Defunct © (2004-11-10 12:32) [146]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 вообще похоже не меряет частоту, что было при старте виндовс ту и показывает.
← →
Ihor Osov'yak © (2004-11-10 12:35) [147]about 144 и не только.
Вместо ответа на конкретные вопросы идет серия оскорблений.
Идет постоянный увод темы разговора.
Вполне возможные не совсем коректное употребление одного-двух слов в течении нескольких десятков постингов называются ложью. В то же время как сам опоннент допускает вольную интерпритацию моих высказываний, делает подмену понятий, несклько раз цепляет ярлыки, а в конце концов таки лжет обычной базарной ложью - (см. 108, фразу "зачем обзывать меня ламером в [70]" - и для справки просьба взглянуть 93 - и авторство этого постинга (ключевая цитата этого постинга - см [98], так как 93, кажется, удален) ).
Только факт присутствия в публичном месте не позволяет мне сказать, кто вы есть на самом деле.
На этом пересонаж с ником Defunct переходит в режим глубокого игнора. Мне жаль потраченого времени.
← →
Defunct © (2004-11-10 12:47) [148]Ihor Osov"yak © (10.11.04 12:35) [147]
> Вместо ответа на конкретные вопросы идет серия оскорблений.
Уважаемый, хочешь чтобы к тебе уважительно относились - относись уважительно к другим. Как аукнется, так и откликнется (C)
> Defunct переходит в режим глубокого игнора
О боже, что же мне теперь делать!
Он добавил меня в игнор!
Теперь никто меня не будет необоснованно обвинять в некомпетенции, называть лжецом. И самое главное, я не услышу кто я есть на самом деле!
Как я много потерял. Хахаха.
Да глаза открой товарисч.
Единственное о чем я возможно буду жалеть, так это то, что ты не видел пост [75]
> Мне жаль потраченого времени.
А мне нет.
← →
VMcL © (2004-11-11 09:59) [149]>>Defunct © (10.11.04 12:32) [146]
>Я обязательно проверю, к вечеру выложу результат.
Ку?
← →
Piter © (2004-11-11 19:48) [150]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 же спорит по другой причине - просто дает понять, КТО на самом деле разбирается в вопросе. Грубо говоря - сверкает гранями. И очень не любит, когда сверкать ему мешают.
Очень жаль, что такой знающий человек так относится к собеседникам. Говорит, что придираются к неточностям в его словах, хотя самм придирается к тому же самому, на мой взгляд... в общем, ладно...
← →
Cardinal © (2004-11-11 20:05) [151]> Таймер программно
> Ответов: 150 ...
← →
Defunct © (2004-11-13 07:30) [152]VMcL © (11.11.04 09:59) [149]
Хороший тест. Спасибо за ссылку!
> Ку?
Просто забыл об этой ветке.
Вот что получилось:
При вкл. DOT, программа (1 раз в секунду) очень точно отображала изменения значений:
FSB от 200 до 240
Bus Clock от 800 до 960
и Core Speed соответственно от 2.8 до 3.36
Думаю это неудивительно, если программа использует IRQ0 в качестве эталона временной задержки, а TSC используется для подстчета тактов.
← →
Defunct © (2004-11-13 07:40) [153]VMcL © (11.11.04 09:59) [149]
Обнаружил баг в программе.
При включенном DOT - иногда неправильно определяется кол-во каналов памяти (постоянно пишет Channel# = single) и неверно определяется тип памяти (из SPD), точнее сказать вообще никак не определяется.
С выкл. DOT, кол-во каналов и тип памяти распознаются и отображаются без ошибок.
PS: Больше всего меня удивила ошибка чтения SPD.
А в целом тест хорош.
← →
VMcL © (2004-11-13 15:38) [154]>>Defunct © (13.11.04 07:40) [153]
Напишите разработчикам. Думаю, исправят.
>>Defunct © (13.11.04 07:30) [152]
>Думаю это неудивительно, если программа использует IRQ0 в качестве эталона временной задержки, а TSC используется для подстчета тактов.
Может быть, может быть. Но вот мне всё-таки хотелось бы глянуть исходники.
:-)
Страницы: 1 2 3 4 вся ветка
Форум: "Потрепаться";
Текущий архив: 2004.11.28;
Скачать: [xml.tar.bz2];
Память: 1.16 MB
Время: 0.038 c
