qqqqq wrote:
>
> По моему, Ваши сведения немного устарели. Если бы все было бы так плохо
> то тогда многие программы, которые сейчас уже стали привычными, просто
> бы не работали.К тому же у Windows таймер по умолчанию настроен на 10ms
> а не 20. 20мс это ну очень долго. Самый простой путь наверное будет
> использовать мультимедиа таймеры см.
> http://www.sysinternals.com/Information/HighResolutionTimers.html

Точность, с которой можно узнать время, выше, чем точность, с которой
можно заказать задержку.

Задержку (без цикла ожидания) можно заказать с точностью до следующего
таймерного прерывания. Я не знаю всех деталей, но думаю, что маленькие
задержки Форточки отрабатывают циклом ожидания, а большие — с помощью
прерываний от таймера. Т.д., для задержек выше некоторых точность будет
не слишком высокая. Где проходит эта граница, я не знаю.

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

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

> Вообще тема таймеров и реал-таймености Windows заслуживает отдельной
> ветки в разделе Низкоуровневое программирование. Здесь я бы хотел узнать
> о хороших сетевых библиотеках у которых время затрачиваемое за посылку
> пакета более менее постоянное.

Как я Вам уже пытался объяснить, надежным образом это сделать нельзя.
Hint: задержки в ядре на DISPATCH уровне могут доходить до единиц
миллисекунд. Что уж говорить об user space процессах!

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