Comments 73
А можно вкрадце объяснить что такое этот таймер и зачем он вообще нужен?
По DOS'у помню, дефолтный тик 18.2 раз в секунду. en.wikipedia.org/wiki/Intel_8253
Тоже начав читать статью возник вопрос про какой вообще таймер идет речь, что он делает и т.п.
Если я правильно понял, то это тот самый таймер, по которому происходит смена контекста процессора. То бишь, такая реализация вытесняемой многозадачности.
Речь идет о так называемом Multimedia Timer — софтовом таймере, который позволяет приложениям создавать очереди задач с высоким разрешением. Используется в основном мультимедийными и серверными приложениями.
Другими словами, если я делаю из компьютера DSP, таймер необходимо разгонять — по-другому я и не смогу добиться минимальной задержки.
А вот не факт — надо проверять. Теперь мы знаем, как.
Каким образом я в принципе смогу достичь задержки звука 2 мс? Чтоб такой задержки достичь, необходимо как минимум не реже раза в 2 мс переключаться на приложение, которое обрабатывает поступающий звук, чтоб оно могло собственно обработать свои очередные 128 сэмплов и выдать результат обратно на звуковуху.
Очевидно, что чтобы приложение могло вызываться не реже раза в 2 мс, таймер должен стоять меньше, чем на 2 мс. А не на 15.6.
Короче, я против этого безаппеляционного высказывания «маленький период — это плохо». Это совершенно неверно. Всему своё место, вполне может попасться задача, в которой нужно именно такое значение этого таймера.
Надо просто понимать при разработке, где и когда. Для звука, как вы видите, это жизненно важно. Для игрушке в реальном времени, когда 5 мс уже влияют — тоже важно. Для потоковой обработки видео — нет: между кадрами там 40 мс, между полями — 20 мс (в стандарте PAL 25 кадров или 50 полей в секунду).
Очевидно, что чтобы приложение могло вызываться не реже раза в 2 мс, таймер должен стоять меньше, чем на 2 мс. А не на 15.6.
Короче, я против этого безаппеляционного высказывания «маленький период — это плохо». Это совершенно неверно. Всему своё место, вполне может попасться задача, в которой нужно именно такое значение этого таймера.
Надо просто понимать при разработке, где и когда. Для звука, как вы видите, это жизненно важно. Для игрушке в реальном времени, когда 5 мс уже влияют — тоже важно. Для потоковой обработки видео — нет: между кадрами там 40 мс, между полями — 20 мс (в стандарте PAL 25 кадров или 50 полей в секунду).
Если вы общаетесь со звуковой картой, умеющей генерировать прерывания, и обрабатываете очередную порцию данных по прерыванию, то частота таймера вам не важна — Windows может переключать потоки после любого прерывания, не только таймера. Конечно, если программа осуществляет задержки вызовом Sleep, то от повышения частоты никуда не деться.
UFO just landed and posted this here
Не так. Во-первый мы не с ОС реального времени работам и время обработки прерываний никто не гарантирует. Во-вторых звуковые карты уже давно прямом доступом буфера воспроизводят, а не по прерываниям (прерывания редкие будут).
В третьих, звук как правило нужно с чем-то синхронизировать — с сетью, с графикой. Где взять опорное время?
В третьих, звук как правило нужно с чем-то синхронизировать — с сетью, с графикой. Где взять опорное время?
Если я правильно понял, что вы об источнике частоты дискретизации, то опорное время в таких случаях всегда берётся с самой звуковухи. Откуда она получает — это её дело — либо на ней самой кристалл стоит, либо там есть вход World Clock и где-то стоит внешний генератор.
Если имеются ввиду «когда начать играть звук» а не «когда вывести очередной сэмпл» — в игре это игровые события (например, таймер, если речь о действиях бота).
Если имеются ввиду «когда начать играть звук» а не «когда вывести очередной сэмпл» — в игре это игровые события (например, таймер, если речь о действиях бота).
Сталкивался с задачей точного задания временных задержек и изучал проблему с изменением гранулярности шедулера и timeBeginPeriod — единственный способ заставить sleep(1) спать одну миллисекунду без оверхеда для процессора. Немного исследований на эту тему: www.geisswerks.com/ryan/FAQS/timing.html
Некорректно выразился. Используется этот таймер всеми приложениями. Как замечено выше, это реализация виндовой многозадачности. А вот тягу к изменению испытывают как раз мультимедийные и серверные приложения.
Да не только виндовой. Так по-моему все preemptive multitasking системы устроены.
В линуксе указанный таймер может принимать четыре значения: 100, 250, 300 и 1000 Hz. Т.е. 10, 4, 3.333, 1 мс. Причём на десктопах обычно используют последний вариант, а энергопотребление снижают другим способом: система хитра, и таймер умеет пропускать тики (эта фича так и называется: dynamic ticks).
В линуксе указанный таймер может принимать четыре значения: 100, 250, 300 и 1000 Hz. Т.е. 10, 4, 3.333, 1 мс. Причём на десктопах обычно используют последний вариант, а энергопотребление снижают другим способом: система хитра, и таймер умеет пропускать тики (эта фича так и называется: dynamic ticks).
dynamic ticks есть и в Windows 8 — я даже специально отключал их в своей системе, так как из-за них валился BSOD :)
Речь идет о системном таймере.
Это маленькая железка, которая с определенной периодичностью генерирует прерывание.
Соответственно, начинает отрабатывать обработчик прерывания, который, например решает будет ли текущая программа продолжать исполнение или будет вытеснена чем-то еще.
Но, если процессор находится в неглубоком сне (что он и делает, например, когда вы читаете этот коммент), прерывание его разбудит по сути в холостую. Будет потрачена бесценная энергия. Ну и, соответственно, лучше чтобы это происходило в данном случае реже.
Это маленькая железка, которая с определенной периодичностью генерирует прерывание.
Соответственно, начинает отрабатывать обработчик прерывания, который, например решает будет ли текущая программа продолжать исполнение или будет вытеснена чем-то еще.
Но, если процессор находится в неглубоком сне (что он и делает, например, когда вы читаете этот коммент), прерывание его разбудит по сути в холостую. Будет потрачена бесценная энергия. Ну и, соответственно, лучше чтобы это происходило в данном случае реже.
Ну я на него ссылку и давал выше. Только вот вопрос у меня — как в современном железе этот таймер аппаратно выглядит? Всё та же микруха или нечто покруче?
а у меня этим балуются chrome, qip и Aimp.
"+5 копеек": \Device\HarddiskVolume2\Program Files (x86)\Mozilla Firefox\firefox.exe
UFO just landed and posted this here
Не просто так этот таймер придумали.
Увеличение частоты уменьшает производительность за счёт бОльшего числа прерываний таймера за тот же период времени (как-то круто в винде, видимо, обработчик этого прерывания чересчур тяжёлый) и увеличивает энергопотребление, но взамен он увеличивает субъективную отзывчивость системы.
Увеличение частоты уменьшает производительность за счёт бОльшего числа прерываний таймера за тот же период времени (как-то круто в винде, видимо, обработчик этого прерывания чересчур тяжёлый) и увеличивает энергопотребление, но взамен он увеличивает субъективную отзывчивость системы.
Шедулер задачам по нему кванты времени раздает, сам обработчик не виноват — меняется логика работы.
Не, ну мало ли, чего там нужно сделать обработчику. Я в основном хотел сказать, что повышение потребления — это не просто так, это оборотная сторона повышения отзывчивости.
Вот я сильно сомневаюсь, что повышение отзывчивости в данном случае имеет место быть. Вдумайтесь, что такое 1 мс, и зачем такие интервалы тому же браузеру, или игрушке. Звук, да, требует учащенного таймера, но опять же 1 мс это перебор для программной обработки, а аппаратная обработка чего угодно и без ускорения этого таймера произойдёт вовремя.
Имеет место. Если речь о ритмичных событиях, то человек ощущает отклонение ритма даже на долю миллисекунды, а если речь о неритмичных событиях, то вполне реально время реакции 5 мс.
Для звука считается удобным работать, если задержка в мониторах не больше 2 мс. (За это время звук в воздухе проходит 0.6 метра — примерно такое же расстояние при игре от натурального инструмента до ушей музыканта.) Больше 10 мс уже играть неудобно, именно такого порядка задержки звука между музыкантами в симфоническом оркестре и требуется дирижёр для синхронизации.
В общем, 15.6 мс — это очень много по сравнению с комфортным для человека.
Для звука считается удобным работать, если задержка в мониторах не больше 2 мс. (За это время звук в воздухе проходит 0.6 метра — примерно такое же расстояние при игре от натурального инструмента до ушей музыканта.) Больше 10 мс уже играть неудобно, именно такого порядка задержки звука между музыкантами в симфоническом оркестре и требуется дирижёр для синхронизации.
В общем, 15.6 мс — это очень много по сравнению с комфортным для человека.
На практике — имеет место быть :) Основная проблема, что шедулер завязан на этот таймер тоже. Я чуть ниже в комментарии приводил пример ( habrahabr.ru/company/intel/blog/186998/#comment_6508774 ), когда на одноядерных системах, или когда на многоядерных все ядра загружены — отзывчивость заметно повышается при маленьких timeBeginPeriod
Да, аналогично, хром. А вот какие-то методы борьбы с этим есть со стороны пользователя? И нужна ли она, эта борьба (судя по выводам статьи — нужна)?
Значит это куча вкладок Chrome'а виновата в скорости разрядки моего старого ноутбука :-)
А решения никакого, стало быть, нет?
А решения никакого, стало быть, нет?
Помню, люди, которые держали игровые сервера Counter-Strike на Windows, запускали специально Windows Media Player на сервере, чтобы увеличить tickrate и уменьшить «лагучесть» в игре (-:
Пример с 33 миллионами компьютеров с Chrome и 10 МегаВатт энергии впечатляет. Учитывая прозрачную систему обновления Chrome, можно успешно спекулировать на рынке продаж электроэнергии, просто включая или выключая разгон таймера в очередной версии. И ведь никто не догадается.
Так процессоры ж стали многоядерными
1. Нельзя ли на одном ядре переключаться для медийных, а на другом помедленнее для остальных?
2. И как с этим в Linux, Mac OS, Andoid, iOS?
1. Нельзя ли на одном ядре переключаться для медийных, а на другом помедленнее для остальных?
2. И как с этим в Linux, Mac OS, Andoid, iOS?
И был ещё бага в Windows из-за которого частое переключение между режимами таймера в Java приложении приводило к изменению в нормальном ходе системных часов.
Вот ведь подстава, а нельзя ли просто запретить пользовательским приложениям монопольно лезть и менять этот несчастный таймер? Или хотя бы приаттачить к каждому процессу по dllке, которая бы перехватывала этот вызов и дальше уже разрешала, запрещала приложению менять это значение таймера?
Я далек от программирования под Windows, но у меня есть вопрос общего характера: я написал код, который при запуске выяснил период работы системного таймера и в дальнейшем программа исходит из данного значения. Потом кто-то меняет период работы таймера. Что будет с моей программой?
программа будет работать неправильно
Зависит от того, что Вы называете словом «исходит».
Например, короткий sleep или timed wait в цикле будет отрабатывать в N раз чаще или реже. Если тело (или условие) цикла имеет побочные эффекты, эти побочные эффекты тоже будут отрабатывать в N раз чаще или реже. Например, если Вы делаете пошаговую анимацию с фиксированным шагом, ее скорость изменится. Если Вы используете интерполяцию по времени, скорость анимации в среднем (amortized) не изменится, но она станет более или менее плавной. Наконец, если логика Вашей программы полагается на определенную частоту таймера, скорее всего, в ней есть и другие проблемы (hardcoded constants, смешение спецификации с реализацией, смешение бизнес-логики со вводом-выводом и еще что-нибудь столь же пионерское).
Для внеклассного чтения: staff.um.edu.mt/jskl1/turbo.html#Error
Например, короткий sleep или timed wait в цикле будет отрабатывать в N раз чаще или реже. Если тело (или условие) цикла имеет побочные эффекты, эти побочные эффекты тоже будут отрабатывать в N раз чаще или реже. Например, если Вы делаете пошаговую анимацию с фиксированным шагом, ее скорость изменится. Если Вы используете интерполяцию по времени, скорость анимации в среднем (amortized) не изменится, но она станет более или менее плавной. Наконец, если логика Вашей программы полагается на определенную частоту таймера, скорее всего, в ней есть и другие проблемы (hardcoded constants, смешение спецификации с реализацией, смешение бизнес-логики со вводом-выводом и еще что-нибудь столь же пионерское).
Для внеклассного чтения: staff.um.edu.mt/jskl1/turbo.html#Error
Касательно вопроса таймеров — я так и не осилил синхронизацию времени в Windows с локальным Linux NTP сервером с точностью более ~10мс… Вероятно таймер виноват.
habrahabr.ru/qa/31893/
habrahabr.ru/qa/31893/
> «что составляет почти 10% от стандартного потребления упаковкой процессора»
Что еще за упаковки процессора?
Что еще за упаковки процессора?
MIcrosoft и Google специально замедляют работу своих продуктов, чтобы в следующей версии они работали быстрее предыдущих)))
Бред какой-то.
Во-первых, Windows (как и Linux) в общем случае не ОС реального времени и никто вам никакой периодичности не обещает. Включая планировщик задач.
Поэтому как только стоит задача привязки к каким-либо физическим процессам, то нужны мульти-медиа таймеры.
Звуковой карте — чтобы синхронизировать звук с картинкой.
Играм и видео-плеерам — чтобы синхронизировать звуковую дорожку и картинку.
Играм — чтобы картинка не дёргалась.
VS? Скорее всего они как-то профайлинг или синхронизацию на фоне делают (та же .NET, например). Потому и хотят разрешение 1 мС.
Хрому может быть нужен, чтобы использовать ускорение видео, как и играм.
Во-вторых, вы про какой из таймеров?
"Период таймера Windows по умолчанию составляет 15.6 мс" ?!!!
Вы утверждаете, что планировщик переключает и балансирует задачи 64 раза в секунду? Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?! Посмотрите, сколько в системе потоков.
Планировщик замечательно увеличивает частоту до 1мс.
Про линукс — весьма аналогично.
Во-первых, Windows (как и Linux) в общем случае не ОС реального времени и никто вам никакой периодичности не обещает. Включая планировщик задач.
Поэтому как только стоит задача привязки к каким-либо физическим процессам, то нужны мульти-медиа таймеры.
Звуковой карте — чтобы синхронизировать звук с картинкой.
Играм и видео-плеерам — чтобы синхронизировать звуковую дорожку и картинку.
Играм — чтобы картинка не дёргалась.
VS? Скорее всего они как-то профайлинг или синхронизацию на фоне делают (та же .NET, например). Потому и хотят разрешение 1 мС.
Хрому может быть нужен, чтобы использовать ускорение видео, как и играм.
Во-вторых, вы про какой из таймеров?
"Период таймера Windows по умолчанию составляет 15.6 мс" ?!!!
Вы утверждаете, что планировщик переключает и балансирует задачи 64 раза в секунду? Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?! Посмотрите, сколько в системе потоков.
Планировщик замечательно увеличивает частоту до 1мс.
Про линукс — весьма аналогично.
Вы утверждаете, что планировщик переключает и балансирует задачи 64 раза в секунду? Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?!Ну, во-первых, это не я утверждаю, а Брюс Досон, программист из Valve. А во-вторых, это действительно так. Вот отчет powercfg с моей машины:
Установленное по умолчанию разрешение аппаратного таймера, равное 15,6 мс(15 625 000 нс), следует использовать во всех случаях простоя системы. При увеличении разрешения таймера возможно снижение эффективности технологий управления электропитанием процессора. Разрешение таймера может увеличиваться при воспроизведении файлов мультимедиа или анимации.
Текущее разрешение таймера (х100 нс) 156000
Могу привести нотариально заверенный скриншот :)
Именно так, шедулер дергается раз в 15.6 мс по дефолту.
Кстати вы помните как бывало на одноядерных машинах, когда какой-нибудь зависший процесс валит CPU на 100%? Приходилось со скрипом кое-как открывать диспетчер задач, и прибивать процесс. Если бы вы поигрались с мультимедиа таймером, вы бы заметили, что при timeBeginPeriod(1) открыть диспетчер задач гораздо проще, чем при дефолтных 15.6мс
Вот тут кстати неплохое мини исследование того как работает шедулер: dtf.ru/articles/read.php?id=39888
Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?!Да, но тут многое зависит еще и от приоритета, и от действительной активности. Если поток отработал, и у него осталось свободное время от кванта — то оно будет отдано другому. В действительности же очень мало потоков одновременно нагружают процессор, ожидающие потоки сразу же отдают свое время и проблем с этим не возникает.
Кстати вы помните как бывало на одноядерных машинах, когда какой-нибудь зависший процесс валит CPU на 100%? Приходилось со скрипом кое-как открывать диспетчер задач, и прибивать процесс. Если бы вы поигрались с мультимедиа таймером, вы бы заметили, что при timeBeginPeriod(1) открыть диспетчер задач гораздо проще, чем при дефолтных 15.6мс
Вот тут кстати неплохое мини исследование того как работает шедулер: dtf.ru/articles/read.php?id=39888
Может от этого зависит прикол на некоторых компах, когда ставишь систему и все работает отлично только звук в любых программах играет очень быстро! И никакие драйверы не помогают, только внешняя звуковая
Можно ли изменить этот период в Opera(2ms), Winamp(2ms) и Sametime(1ms)?
ктонибудь пожалуйста напишите программу которая запускаясь устанавливает таймер в 0.5мс.
дело в том что в бф4 лучше стреляется с минимальным временем таймера.
я нашел две программы TimerTool.exe и TimerResolution.exe но они после запуска требуют введения нужного числа. А после закрытия возвращают 1мс взад.
Оптимально программку которая по аргументу в команде вызова устанавливает нужное время таймера.
дело в том что в бф4 лучше стреляется с минимальным временем таймера.
я нашел две программы TimerTool.exe и TimerResolution.exe но они после запуска требуют введения нужного числа. А после закрытия возвращают 1мс взад.
Оптимально программку которая по аргументу в команде вызова устанавливает нужное время таймера.
Так можно самому написать.
Здесь написано как.
Здесь написано как.
Sign up to leave a comment.
Почему не стоит разгонять таймер Windows или мегаватты, потраченные впустую