2010-08-24 5 views
2

У меня есть процесс, который передает часть аппаратного обеспечения (устройство передачи данных) с определенным размером буфера. Что я могу ожидать от окон планировщика окон, чтобы убедиться, что я не получаю переполнение буфера?Какое минимальное гарантированное время для процесса в окнах?

Мой буфер составляет 32 КБ и потребляется со скоростью ~ 800 тыс. Байт в секунду.

Если я заполняю его в партиях по 16-кратным байтам, которые составляют одну партию каждые 20 мс. Однако, каков мой нижний предел для его заполнения. Если, скажем, я называю сон (0) в моем цикле заполнения, каков мой разумный худший временной интервал планирования?

OS = Windows XP SP3 Dual Core 2.2Ghz

Заметь, я делаю вызов API, чтобы проверить уровень заполнения буфера и вызов к API драйвера передать ему данные. Я предполагаю, что это точки планирования, которые Windows могла бы использовать в дополнение к сну (0).

Хотелось бы (как процесс) играть красиво и по-прежнему соответствовать моему сроку в реальном времени. Машина посвящена этой задаче, но ей необходимо получить данные по сети и отправить ее на устройство ввода-вывода.

Что я могу ожидать от исполнения планировщика? Что еще мне нужно учитывать.

ответ

3

Нет гарантийного наихудшего случая. Потеря процессора на сотни миллисекунд вполне возможна. Вы зависимы от любых потоков ядра, они всегда будут работать с более высоким приоритетом, чем вы когда-либо сможете получить. Запуск в плохой сетевой адаптер, USB или аудио драйвер - проблема, с которой вы постоянно будете бороться. Если вы не можете контролировать оборудование.

Если вы можете пережить случайные промежутки времени, убедитесь, что запрос ввода-вывода, который вы используете для получения данных устройства, является ожидаемым событием. Windows нравится планировать потоки, которые блокируют запрос ввода-вывода, который завершен раньше всех остальных. Опрос со сном() не является хорошей стратегией. Он автоматически сжигает циклы процессора, и планировщик вообще не поддерживает поток.

Если вы не можете пережить недоработки, вам необходимо рассмотреть драйвер устройства.

+0

Я думаю, вы имеете в виду потоки уровня прерывания и DPC-уровня; в ядре есть другие потоки с более низким приоритетом. – ChrisW

+0

Сон может быть не так уж плох: в худшем случае он может выкидывать ненужный процессор, что неплохо на выделенной машине (возможно, он хочет, чтобы процессор зависел от того, что он хочет делать). Причиной Спящего может быть то, что он пытается сохранить буфер передачи как можно более полным. – ChrisW

+0

Да, драйвер устройства. Например, стандартный последовательный порт имеет 1-байтовый или 16-байтовый аппаратный буфер передачи; драйвер последовательного порта принимает несколько неограничивающих буферов из приложения: поэтому хорошая стратегия приложения состоит в том, чтобы делать WriteFile на 2 больших буфера и использовать запрос ввода-вывода, который будет разбужен, когда драйвер использовал/исчерпал/вернул один из них: приложение может затем отправить следующий (третий) буфер, в то время как драйвер devce уже имеет (второй) буфер. – ChrisW

3

Какое минимальное гарантированное время для процесса в окнах?

Нет гарантии: Windows не является оперативной памятью в режиме реального времени.

Что еще мне нужно принять во внимание

  • Что еще работает на машине (что-то с высоким приоритетом может упредить вас)
  • Сколько оперативной памяти у вас есть (изменения производительности системы много, если оперативная память отсутствует)
  • Независимо от того, являетесь ли вы донгом ввода/вывода (поскольку вы можете, например, останавливаться при ожидании доступа к диску или сети)

Хотелось бы (как процесс) играть красиво и по-прежнему соответствовать моему сроку в реальном времени. Машина посвящена этой задаче, но ей необходимо получить данные по сети и отправить ее на устройство ввода-вывода.

Оцените приоритет процесса и/или потока в «приоритете реального времени».