Каково определение реального времени, почти реального времени и пакетного?Приведите примеры каждого? - PullRequest
5 голосов
/ 11 марта 2011

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

  • В реальном времени это синхронизация веб-сервисов или асинхронных веб-сервисов.
  • Практически в реальном времени могут быть JMS или системы обмена сообщениями или большинство систем, управляемых событиями.
  • Партия для меня - это скорее синхронизированная система, которая обрабатывает, когда просыпается.

Приведите примеры каждого из них и не стесняйтесь исправлять мои предположения.

Ответы [ 4 ]

22 голосов
/ 13 марта 2011

https://stackoverflow.com/tags/real-time/info

Реальное время

Реальное время означает, что время завершения действия является частью его функциональной корректности.Например, правильность функции sqrt() выглядит примерно так:

Функция sqrt () реализована правильно, если для всех x> = 0 sqrt (x) = y подразумевает y ^ 2 ==x.

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

Предположим, у нас есть мифическая функция под названием sqrtrt(), версия квадратного корня в реальном времени.Представьте, например, что нам нужно вычислить квадратный корень из скорости, чтобы правильно выполнить следующее торможение в антиблокировочной тормозной системе.В этом параметре мы могли бы вместо этого сказать:

Функция sqrtrt () реализована правильно, если

  1. для всех x> = 0, sqrtrt(x) = y подразумевает y^ 2 == x и
  2. sqrtrt() возвращает результат в <= 275 микросекунд. </li>

В этом случае ограничение по времени является не просто параметром производительности.Если sqrtrt() не завершится за 275 микросекунд, вы можете опоздать с включением тормоза, что приведет к скольжению или снижению эффективности торможения, что может привести к аварии.Ограничение по времени является частью функциональной правильности процедуры.Поднимите это на несколько уровней, и вы получите систему реального времени как одну (по крайней мере, частично), состоящую из действий, которые имеют своевременность как часть условий их функциональной корректности.

Near Real-Time

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

Разница между "реальным временем" и "почти реальным"время "- это разница как в точности, так и в величине.Системы реального времени имеют временные ограничения, которые варьируются от микросекунд до часов, но эти временные ограничения имеют тенденцию быть достаточно точными.Почти в реальном времени обычно подразумевается более узкий диапазон величин - в пределах допусков человеческого восприятия - но, как правило, они не сформулированы точно.

Я бы сказал, что системы, близкие к реальному времени, можно назвать в реальном времени.систем, но их временные ограничения являются просто вероятностными:

Цена акции будет отображаться пользователю в течение 500 мс после ее изменения на бирже, с вероятностью p> 0,75.

Пакетная обработка

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

Исходное сообщение

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

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

Пакет "близок к реальному"время ", когда вы еще более терпимы к длительным временам ответа.

Часто эти термины используются (плохо, ИМХО), чтобы различать человеческое восприятие латентности / производительности.Люди думают, что в реальном времени очень быстро, например, миллисекунды или что-то в этом роде.Время, близкое к реальному, часто составляет секунды или миллисекунды.Пакет представляет собой задержку секунд, минут, часов или даже дней.Но я думаю, что это не особенно полезные различия.Если вы заботитесь о своевременности, есть дисциплины, которые помогут вам получить это.

2 голосов
/ 28 февраля 2012

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

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

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

Это дает хорошую структуру систем реального времени и почти реального времени, где они могут (в теории) работать вечно при получении новых данных ... обработка происходит параллельно с получением.Пакетная обработка происходит после того, как все данные были собраны.

В любом случае, я мог бы вступить в конфликт с некоторыми техническими определениями, о которых я не знаю ... и я предполагаю, что кто-то здесь радостно исправит меня, если потребуется.

1 голос
/ 17 декабря 2013

У всех этих ответов есть проблемы в том, что определения ошибочны. Например, «пакет» означает, что транзакции сгруппированы и отправлены вместе. Реальное время подразумевает транзакции, но может иметь и другие последствия. Поэтому, когда вы объединяете пакет в одном атрибуте с реальным и почти реальным временем, ясность цели для этого атрибута теряется. Определение становится менее сплоченным, менее четким. Это сделало бы любое приложение, созданное с данными, более хрупким. Я предполагаю, что практикующим будет лучше с четко смоделированной таксономией, такой как:

  • Атрибут1: пакетные (сгруппированные) или отдельные транзакции.
  • Атрибут2: Запланированный (управляемый временем), управляемый событиями.
  • Атрибут3: скорость за транзакцию. Для партии это будет средняя скорость / транзакция.
  • Атрибут4: Протокол / Технология: SOAP, REST, комбинация, FTP, SFTP и т. Д. Для перемещения данных.
  • Атрибут: все, что угодно.

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

0 голосов
/ 30 августа 2011

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

...