почему ускорение процессора приводит к пропущенным срокам в системах реального времени?

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

Спасибо

4 5
embedded timing real-time

4 ответа:

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

См. также:

  • , Б. Андерссон; Йонссон, й.; , "упреждающий многопроцессорных расписаний аномалии," параллельная и распределенная обработка симпозиума., Материалы международных, IPDPS 2002, тезисов и компакт-диск , объемн., нет., с. 12-19, 2002. doi: 10.1109 / IPDPS.2002.1015483
  • Grahamm R. L., " границы многопроцессорных временных аномалий ", SIAM Journal on Прикладная Математика, Т. 17, № 2 (Мар., 1969), стр.
6

Такие вещи случаются, и Дуглас уже объяснил аномалию Грэхема. Я попытаюсь объяснить это на небольшом примере. Я надеюсь, что это облегчает понимание того, что происходит:

Аномалия возникает, если вы имеете дело с несколькими параллельными задачами и общим ресурсом фиксированной скорости, таким как канал связи. Хорошим примером этого в контексте системы реального времени является сбор данных. Если вам нужно прочитать x миллисекунд данных из аналого-цифровой преобразователь это всегда займет x миллисекунд, независимо от скорости процессора. В моем примере я называю это "Ио-время" или "Ио-задача".

Теперь рассмотрим следующий сценарий:

У вас есть одна задача (А), которая состоит из:

  • 4 миллисекунды вычислений процессора
  • 4 миллисекунды времени ввода-вывода (сохранение данных)

Вторая задача (B) будет запущена аппаратным событием, состоящим из:

  • 4 миллисекунды времени ввода-вывода (загрузка данных)
  • 2 миллисекунды процессорного времени

Вторая задача запускается в миллисекунду 3.

IO и CPU являются общими ресурсами. Они могут работать параллельно, но IO или CPU могут обрабатывать только одно задание одновременно.

Один из возможных графиков для этого может выглядеть следующим образом: 

timestamp:   cpu/io   job:
---------------------------------------------
t=0          event    <--- hardware event triggers task-a
t=0          cpu      start of task-a (4 ms)
t=3          event    <--- hardware event triggers task-b
t=3          io       start of task-b (4 ms)
t=4          cpu      task-a done
t=7          io       task-b done
t=7          io       start of task-a (4 ms)
t=7          cpu      start of task-b (2 ms)
t=9          cpu      task-b done
t=10         io       task-a done

Теперь мы удваиваем мощность процессора, так что процессор будет работать в два раза быстрее:

timestamp:   cpu/io   job:
---------------------------------------------
t=0          event    <--- hardware event triggers task-a
t=0          cpu      start of task-a (2 ms)
t=2          cpu      task a done
t=2          io       start of task a (4 ms)
t=3          event    <--- hardware event triggers task-b, but can't start
                           because io-bus is busy. Must wait.
t=6          io       task a done
t=6          io       start of task b (4 ms)
t=10         io       task b done
t=10         cpu      start of task b (1 ms)
t=11         cpu      task b done

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

Это всего лишь одна миллисекунда,но эти вещи могут сложиться и могут привести к пропущенным срокам.
5

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

Если скорость процессора увеличивается, распространение может пересекать тактовый цикл, возможно, вызывая задержку из-за повторной попытки, в зависимости от того, как настроена ваша система.

Если крайний срок привязан к счетчику или таймеру, основанному на процессоре, он также увеличится на пропорционально большую величину, так как нет доступа к основной памяти для счетчика.

Любой из них может быть одним из факторов, в зависимости от вашей конкретной установки.

2

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

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

1