Задержка на время меньше 1 мс

Black_mirror



Точно, дело не в сервиспаке!!! вот результаты на той же 2К, что и выше, но теперь стоят дрова kX Project для SB

(на XPSP2 эти же дрова и так стояли, и цифры идин в один)



CPU AuthenticAMD at 1666 MHz

running Windows NT 5.0.2195

Sleep(1) time = 1952 microseconds

Sleep(1) time = 1953 microseconds

Sleep(1) time = 1952 microseconds

Sleep(1) time = 1953 microseconds

Sleep(1) time = 1954 microseconds

Sleep(1) time = 1954 microseconds

Sleep(1) time = 1953 microseconds

Sleep(1) time = 1951 microseconds





TarasCo



Ну дык и предложи корректный вариант imho тест как раз работает как надо - учитывает влияние других трэдов и кривых дров, которые долго не снижают IRQL до пассивного уровня.

 

imho тест как раз работает как надо

Главное, что он доказывает этот тест?



Ну дык и предложи корректный вариант

В поставленном условии задача не решается . В режиме приложений точно отмерить интервал времени <= 1мс не крутясь в цикле нельзя.



В режиме ядра можно использовать таймер. Вот тут может как раз проявится эффект "кривых дров". Таймер вызовет колбек на диспетчерском уровне, соответсвенно не гарантируется точное срабатывание, но в нормальной системе точности порядка 100мкс можно ожидать. Опять же как и для режима приложений можно существенно улучшить определение за счет собственного цикла. Тут принципиально можно даже точнее системного таймера посчитать...

 

Код (Text):

1. CPU GenuineIntel at 2992 MHz
2. running Windows NT 5.1.2600 Service Pack 1
3. Sleep(1) time = 15631 microseconds
4. Sleep(1) time = 15615 microseconds
5. Sleep(1) time = 15628 microseconds
6. Sleep(1) time = 15626 microseconds
7. Sleep(1) time = 15628 microseconds
8. Sleep(1) time = 15626 microseconds
9. Sleep(1) time = 15635 microseconds
10. Sleep(1) time = 15617 microseconds
11. Sleep(1) time = 15628 microseconds
12. Sleep(1) time = 15627 microseconds
13. Sleep(1) time = 15626 microseconds
14. Sleep(1) time = 15626 microseconds
15. Sleep(1) time = 15631 microseconds
16. Sleep(1) time = 15627 microseconds
17. Sleep(1) time = 15623 microseconds
18. Sleep(1) time = 15627 microseconds
19. Sleep(1) time = 15627 microseconds
20. Sleep(1) time = 15626 microseconds
21. Sleep(1) time = 15627 microseconds
22. Sleep(1) time = 15627 microseconds

 

Код (Text):

1. CPU GenuineIntel at 2826 MHz
2. running Windows 4.10.2222  A
3. Sleep(1) time = 835 microseconds
4. Sleep(1) time = 1003 microseconds
5. Sleep(1) time = 985 microseconds
6. Sleep(1) time = 982 microseconds
7. Sleep(1) time = 970 microseconds
8. Sleep(1) time = 962 microseconds
9. Sleep(1) time = 969 microseconds
10. Sleep(1) time = 983 microseconds
11. Sleep(1) time = 961 microseconds
12. Sleep(1) time = 944 microseconds
13. Sleep(1) time = 984 microseconds
14. Sleep(1) time = 909 microseconds
15. Sleep(1) time = 1078 microseconds
16. Sleep(1) time = 882 microseconds
17. Sleep(1) time = 1087 microseconds
18. Sleep(1) time = 948 microseconds
19. Sleep(1) time = 895 microseconds
20. Sleep(1) time = 1012 microseconds
21. Sleep(1) time = 915 microseconds
22. Sleep(1) time = 971 microseconds
23.  

ps: что-то с частотой прога лажается конкретно...

 

TarasCo >

возник спор, сколько длится Sleep, вот что бы цифры были не с потолка, этот тест и появился.



>

к этому вывду ещё на предыдущей странице пришли.





infern0 >

Щас попробую угадать, проц с HyperThreading ???

И мастдай не поддерживает многопроцессорность, в отличае от XP



А звуковуха случаем не SB ?

 

S_T_A_S_

да, проц с HT, звук бортовой, внутри ICH5 если не ошибаюсь.

 

возник спор, сколько длится Sleep, вот что бы цифры были не с потолка, этот тест и появился.



И что он показал? Что подтвердил или опровергнул? Какие, интересно мне, можно сделать выводы?



Sleep переводит тред в режим ожидания. Через 1мс система взведет семафор и тред снова станет доступен для планировщика задач. Реально он получит управление только в соответствии с регламентом планирования. Это может произойти:

через 1мс - скорее всего просто не нашлось другого активного треда.

через 10-15мс - активный тред нашелся таки и честно отработал свой слайс

Больше 15мс - в системе присутсвует насколько тредов, либо тред с высоким приоритетом, либо это серверная платформа....

Короче говоря, если тест что то и подтвержадет, то толко невозможность использования Sleep(1) для измерения миллисекундного интервала

 

infern0 >

Сенькс, остаётся ещё понять, как именно это влияет... )

если под мастдаем ошибается, то не очень страшно - можно отмазаться, что система не поддерживает HT Pentium IV %)



Со звуком интересно получается - значит именно дрова kX Project что-то меняют, осталось найти что именно.





TarasCo >

Что значит можно? разве кто-то запрещает делать выводы самостоятельно? imho приведённых цифр достаточно, что бы увидеть, что планировщики в NT и 9x(гы, мастдай рулит!) разные, да и в NT поведение планировщика далеко не одинаково.

хорошая теория, но как она объясняет такие результаты:



CPU AuthenticAMD at 1666 MHz

running Windows NT 5.1.2600 Service Pack 2

Sleep(0) time = 0 microseconds

Sleep(0) time = 0 microseconds

Sleep(0) time = 0 microseconds

Sleep(0) time = 0 microseconds

Sleep(0) time = 0 microseconds



То есть, если Sleep(1), то _всегда_ находится трэд, который честно отрабатывает 10-15мс; если установлены дрова kX Project, то честности хватает на 2мс; а если Sleep(0), то почему-то:

?

 

Разобрался с причиной изменения точности Sleep() 15627мкс -> 1952мкс под NT.

Дрова тут ни причём, существует довольно много программ, которые влияют на эти цифры.



Делают они это так:

Код (Text):

1. timeBeginPeriod(1)

))

В результате получаем погрешность (при отсутствии влияния других трэдов) Sleep 1мс (то есть пауза примерно равна параметру + 1мс), что уже гораздо лучше, чем 15мс.

Под влияние попадают трэды всех процессов в системе.



Если timeBeginPeriod не вызывать, величина величину timeslice определяется из

HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySep aration

(подробнее - у Соломона и Руссиновича)



ЗЫ: в аттаче "прога", которая делает timeBeginPeriod(1), если кому интересно посмотреть влияние и лень набивать.

1319979570__wait.zip

 

2 S_T_A_S_

программа на P 166 Win98SE выдает на Sleep(1) ~5000, но иногда 900-1300.

Хотя внешне я никаках программ не запускаю.



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



Чтоб сделать задержку на 0.5мс можно так:

Код (Text):

1.  
2. ...
3. thread_proc_1 proc x:DWORD
4. @@1: call my_func
5. invoke Sleep, 1
6. jmp @@1
7. thread_proc_1 endp
8. ...
9. thread_proc_2 proc x:DWORD
10. @@1: call my_func
11. invoke Sleep, 1
12. jmp @@1
13. thread_proc_2 endp
14.  
15. ...
16. my_func proc
17. ...
18. ret
19. my_func endp
20.  
21.  

Но вот вопрос и был насчет того, сколько жрут сами треды- если их сделать например 50 штук.

 

yureckor



Ты в мой предыдущий пост читал, про timeBeginPeriod ?

WinAmp (у меня его нет, что бы проверить) эту функцию вызывает, поэтому точность Sleep и возрастает.



А если сделать 50 трэдов, то вопрос должен быть не сколько жрут трэды, а какова вероятность, что на таких ОС как мастдай когда-нибудь запустится трэд из 20го десятка )

 

а какова вероятность, что на таких ОС как мастдай когда-нибудь запустится трэд из 20го десятка )





=1

 

yureckor

может реализовать всё через fibers? И разруливай "планировку" сам, по тому же rdtsc. На спектруме делал многозадачность?

 

На спектруме-то делал, у меня ядро ос через прерывание переключало задачи, (если задача занимала меньше 1/50 -то еще раньше).



В какую сторону копать?

Посмотрю про фиберы.

 

м.б. nanosleep?



товарищи, помните что время измеряется в частото IRQ. Больше IRQ -больше грузится проц.



таймер похволяет мерять время до одной микросекунды, но вот хватит ли проца на это?

 

Эх,спек...!

 

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

Во многих случаях достаточно псевдомногозадачности.



Я делал оконный менеджер на Спеке так:

есть сервер (диспетчер); при создании, "задача" регистрирует окно предоставляя некоторую структуру данных;

всё - создание окна выполнено - менеджер сам создаёт окно, и управляет им; при выборе контролов сам вызывает нужный код, который находится внутри клиента.

Клиенты не имеют ни "потоков", ни "цикла выборки сообщений".

Всё очень примитивно: простой вызов функций в цикле "по очереди", приоритеты определяются на основании положения окон относительно "передного плана". но такой подход (при соблюдении некоторых требований к коду клиентов) обеспечивал то, что сейчас может предоставить только real time OS.