2. Понятие приложений реального времени. Приложении мультимедиа. Требования к сетевым протоколам.

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

Real time системы – должны отвечать и совершать какие-то определенные действия за определенный период времени, и мы должны за этот промежуток получить корректный результат. Такие системы узко специализированные. Они решают обычно одну задачу, НЕ multi user (для одного пользователя). Они делаются в кач-ве SOC’ов – system on chip = на одном чипе.

Данные системы требуют:

чтобы у нас были специальные контроллеры multi memory unity (MMU) – это их хардвеерная часть

Распределенная память.

· работаем через tlb – табличку распределения физических адресов памяти. Процессор обращается к page table, а дальше через нее получаем физический адрес странички физической. Этот вариант более правильный, есть защита, мы не попадаем куда попало. У нас должен быть специальный management memory unit – это хард, без него будет очень медленно и, вообще, не работать.

В системах real time больше используют третий вариант, но при наличии mmu.

Мультимедиа

Multi media системы – голос, видео – составные части системы. Однако видео – очень необычный вид передачи данных. Видео требует, чтобы мы получили определенные действия – delivery или передача за определенный период времени. Для того, чтобы добиться и того и другого нужно предпринять массу действий.

Считается, что 70% информации - это видео теперь. В чем проблема передачи видео? Здесь возникает понятие потока – стрима. Stream в ос используется в трех вариантах:

1. вопросы performance

2. технология написания драйверов. Передается запрос потоком, он от upper level передается ниже при помощи определенного потока параметров: передаю сначала udp к ip, от ip к драйверам и т.д. до тех пор, пока не дойдем до драйверов адаптера, до канальных протоколов, которые сейчас хардвеерные.

3. Поток передачи мультимедийных данных, имеется в виду видео, все остальное не инересует. Мы видим не глазами (ауф), а видим головой (ауф х2). Наша голова воспринимает данные только с определенной скоростью – 25-30 фреймов в секунду в процессе передачи.

Требования

Любая передача мультимедиа очень объемна. Потому что, если передавать в hd tv (высокого разрешения 24.47), то 100минутный фильм = 15 гб. Это очень много, при учете даже современной передачи через оптоволокно, т.к. это передается всем. Скорость передачи должны быть определенная – средний фрейм 800 на 600 пикселей (битов) и на 24 (цвет каждого пикселя, который мы должны передать), все это перемножить и поделить на 30, то скорость передачи должна быть 345 мегабит в секунду. И еще здесь добавляется play back.

Требования к мультимедийным серверам:

· Поскольку везде 345 мегабит в секунду не везде можно обеспечить, займемся компрессией – сжимать данные, чтобы передать больше. Любе устройство, передающее мультимедиа, должно уметь compression и decompression.

Компрессия бывает с полным и неполным восстановлением. Полное нам не надо, потому что мы не передаем данные, а видео. Алгоритм mpeg – умеет передавать до 15 мбит в сек.

· Должны иметь мультимедийные расписания, то есть расписания с перехватом, иначе не уложимся в эти 25-30 фреймов в секунду. Нужен rt linux, его нет и начинают искать выход из ситуации. Любая ос должна обрабатывать запросы такие переодически. Это значит, что раз в доле милисекунды идет кусочек информации - периодический процесс. При этом ос поддерживает функцию quality of service, то есть ос поддерживает определенную скорость:

o ОС делает это в варианте best effort (оно есть у всех ос) – стараюсь очень сильно отдать тебе все-все ресурсы, чтоб ты выполнил требования по скорости, однако ни одна ос так не работает, потому что любая ос приберегает какое-то кол-во ресурсов для задач, которые могут появиться.

o Есть вариант soft cost – я раздам процессам приоритеты динамически. У винды для процессов высокий приоритет от 16 до 32. Но такое не прокатит с системой мультимедиа. Soft cost не гарантирует скорость, я гарантирую давать тебе приоритеты и пропускать тебя быстрее других. Осуществляется при помощи shaping, polling, обработка буферов.

o Hard cost – ос гарантирует вам скорость. Для такой гарантии нам нужна определенная пропускная способность (необходимая для передачи мультимедиа), delay должны быть как-то фиксированы и считается в битах, jitter (дрожание, которое возникает при передаче данных), которое может возникать при разной работе софта и харда (определение ошибок или еще чем-то занят) – мы не моем гарантировать, что у нас будет всегда одна заявленная скорость (между фреймами дрожания быть не должно, иначе эти фреймы «встанут»), reliability (надежность) – мы не можем передавать стрим еще раз.