Загрузка процессора

вин не является rtos так что слишком дотошной точности можно не ждать

 

Проверил, точнее задать можно, только нижний предел всё равно 10 миллисекунд......

 

Ответ найден во время экспериментов с мультимедиатаймером, по совету leo.

С таймером удалось получить задержку в 1 мс, но результате экспериментов оказалось что запуск мультимедиатаймера на 1мс
уменьшает нижний предел для команды Sleep до 1мс !!!
После поисков в сети, нашёл тому развёрнутое подтверждение:
http://www.rsdn.ru/forum/Message.aspx?mid=1387967&only=1

Оказалось, по умолчанию, разрешение таймера 10мс и изменить его можно функцией timeBeginPeriod до 1мс, что повлияет на функцию Sleep. Причём повлияет это на всё приложения в системе!
Глядя а код функции timeBeginPeriod видно, что разрешение таймера можно ещё увеличить, вызывая напрямую функцию NtSetTimerResolution.
Буду экспериментировать дальше. Думаю, что получится добиться результатов меньше 1мс, используя ZwDelayExecution.

Проблема решена.
Всем спасибо за помощь!

 

Tropez

Угу, а также на разрешение GetTickCount, GetThreadTimes и т.п.
Причем разрешение в 1мс может устанавливаться в системе звуковыми прогами\службами аль еще кем, что может создать впечатление, что TickCount "всегда" изменяется с частотой 1КГц вместо стандартных 10-15 (камешек в огород CrystalIC | Clerk )

 

Всем привет! У меня такая проблема: Мне нужно добиться задержки в 100 мксек. Использую CreateWaitableTimer, SetWaitableTimer, WaitForSingleObject. Но при проверке
GetTickCount 100 периодов повторения у меня показывает 94..140 мсек. , хотя пишут, что SetWaitableTimer должен работать от 200 нсек. Почему так, и как добиться нужной задержки?
Использую VC++ 6 Создаю проект как MFC диалог
Код:

Код (Text):

1.     UINT iCnt = 0;
2.     CString str;
3.  
4.     int iTime = -GetTickCount();
5.  
6.  
7.     HANDLE hTimer;
8.     hTimer = CreateWaitableTimer(NULL, FALSE, NULL);
9.  
10.     LARGE_INTEGER delay;
11.     delay.QuadPart = -100L; //100000 = 1 msec
12.  
13.     for(int i = 0; i<100; i++)
14.     {
15.         SetWaitableTimer(hTimer, &delay, 0, 0, NULL, 1);    // Установка Задержки
16.         WaitForSingleObject(hTimer, INFINITE);          // Ожидаем завершения
17.         CancelWaitableTimer(hTimer);
18.     }
19.     CloseHandle(hTimer);
20.  
21.     iTime += GetTickCount();
22.  
23.     str.Format("%d", iTime);
24.     AfxMessageBox(str);                     // Выводим сообщение

 

Tropez
Помоему ты не в ту сторону смотришь. И почемуто тебя до сих пор не поправили.
Чтобы ждять по-нормальному, т.е. чтобы могли в это время исполняться другие процессы включая idle, ты должен работать с устройством, генерирующее прерывания, например через DMA.

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

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

Предложенный вариант с ожиданием в корне неверен.

 

Привет.
А нужно, чтобы процессор был в это время (200нс) занят другими задачами, или достаточно, чтобы он занимался только отсчётом таймера?

 

Squirrel

По моему, это все туфта, и по разрешению WaitableTimer ничем не лучше MM-таймера, GetTickCount и т.п. , и все его достоинство только в том, что поток может спокойно вздремнуть какое-то время, будучи уверенным, что винда его разбудет не позднее системного тика от заданного момента "Ч"

 

hlt

 

Попробуй совсем тупо, вот так: http://www.wasm.ru/forum/viewtopic.php?id=15235&p=2