Топология сети и расчет пропускной способности

М-ммм да уж!

8-(

Стоимость сетей падает!

Но при этом - сети нужно строить правильно-заточенные под задачи видеонаблюдения!

Ну дык и сказалбы честно: - для передачи IP видео ПОТОКА реального времени с числом фиксируемых фаз движения не мение чем 25 в секунду, необходимо строить персонально-заточенную сеть, которая после ПОСТРОЙКИ будет даром никому не нужна из-за своей узкой специализации!

ПРИЧЕМ сказал бы честно - строить нужно не просто сеть на полу-бытовых коммутаторах, а именно сеть на самом новом сетевом оборудовании а-ля CISCO ну или на оптических GPON!

Сказал бы чтестно - необходимо построить сеть, со стоимостью затрат на её постройку - значительно превышающей стоимость не только всех камер системы даже с разрешением в 4k вместе со стоимостью объективов, но и всего серверного оборудования под видеозапись и видИмое наблюдение!

Вот только я сомневаюсь - что после такого честного заявления, продвижение IP-видео пошло бы вверх!

PS

Ну а очередной "ЗК-развод" (прикольно PR=ЗК) про скорость реакции при управлении PTZ через IP - меня откровенно порадовали.

:-)))

Вообще то скорость реакции PTZ на команду и задержка отображения получаемой с данной камеры картинки - вещи "немножеЩко" разные!

И то что PTZ получит команду по IP и то что PTZ начнет исполнять эту команду фактически молниеносно - никто и не сомневался даже раньше.

Только вот то что в действительности управлять подобными PTZ-IP системами в реальном времени фактически невозможно - знает любой, кто хотя бы раз просто пытался вручную крутить резкость объектива и даже не на мегапиксельной IP-ВК подключенной напрямую к компьютеру, а на самых что ни наесть простых IP-SD камерах:

- И скорость управления "мышечно-мальчикового PTZ" - вреде бы большая! И скорость ШЗ- прохождения пакетов от мозжечка до ручек золотых - вроде бы то же маленькая! Да и задержек на "передачу команд" от момента восприятия картинки на экране до сокращения мышИцы - вроде как значительно ниже чем та же команда на PTZ по IP, - а вот резвости настройки резкости на IP-ВК - "почему-то" тоже нет!

;-)

Особенно впечатлили перлы:

Минимальная: 300 Kbit/s

соотношение пиковой скорости 15 Mbit/s к минимальной скорости в 300 Mbit/s будет приблизительно равно 1:14

9 800 000 bit / 12000 бит = 816,6(6) IP-кадров (816,6(6) IP-кадров * 10 потоков = 8166(6) IP-кадров) - но за 0,6 секунды

в сети IP даже имея скорость на приемном порту в 1000 мбит/с будет не возможно гарантированно получить трафик от 10 но АСИНХРОННЫХ видеопотоков в формате сжатия MPEG-2

По арифметике, как всегда, твёрдая двойка, дорогой Вадим Викторович. Снова в школу в 3-ий класс на второй год.

Описанная вами модель - это задачка для школьника третьего класса про бассейн, в который втекает 10 труб, а вытекает 1.

Если принять, что пиковая скорость 15 МБит/сек, то очевидно, что она достигается в момент передачи самого "тяжеловесного" опорного кадра из GOP. Но так как частота следования кадров строго f=25 Гц, то время передачи опорного кадра t=1/f=40 мсек. А частота следования этих пиков равна F = 25/15 = 1.6(6) Гц (как задано в условиях задачи).

Т.о. пиковая нагрузка на канал возникает с частотой 1.67 Гц и длится 40 мсек.

Разберём модельную ситуацию, когда все 10 камер абсолютно одновременно начинают передавать опорный кадр (легко понять, что именно в этой ситуации создаётся "пиковая исходящая скорость" [-термин В.В.Тюрина]).

За эти 40 мсек на входы коммутатора втекает R=15 Мбит/сек * 40 мсек *10 = 750 Кбайт, а вытекает T = 97,52 МБит/сек * 40 мсек = 487600 байт.

Таким образом, размер буфера, который необходим коммутатору, чтобы сгладить колебания сетевого трафика B = R-T = 262.4 КБайт < 300 КБайт.

Если максимальный средний поток от каждой камеры Rср < 9752 КБит/сек, то Fast Ethernet-коммутатор будет справляться с потоком данных от 10 камер и сглаживать сетевые нагрузки, заданные условиями задачи, при наличии буфера размером не менее 300 КБайт.

Наконец, оценим вероятность того, что интервалы времени, когда все 10 камер транслируют опорный кадр, пересекутся, т.е. вероятность того, что создастся "пиковая исходящая скорость". Эта верояность P ~ (1/15)^10 = 1.7E-12

Если максимальный средний поток от каждой камеры < 9752 КБит/сек, то Fast Ethernet-коммутатор будет справляться с потоком данных от 10 камер и сглаживать сетевые нагрузки, заданные условиями задачи, при налиии буфера размером не менее 300 КБайт.

Мой злейший друг, - ну коли вы уже взялись выставлять мне оценки и в очередной раз "опровергать" математикой средней температуры по больнице (включая морг) - реалии "ШЗ-жизни", то не поведаете-ль местной публике:

- Почему в эфирном DVB, занимающем один частотный ВЧ канал шириной 8 мГц, при возможности иметь скорость потока в 100 мБит/с (при QAM-256) и всего-то при разрешения SD вещания, но в формате MPEG-2 (50i) - в одном мультиплексе передается не более 6-8 транспортных потоков MPEG-TS.

Причем передаются эти 6-8 потоков MPEG-TS со средним битрейтом не боле чем 3-5 мБит/с.

Но даже при этом, картинка рассыпается на шашечки на любых динамичных ("тяжелых") сценах.

Так почему же - всего 8 SD потоков 3-5 мбит/с (да еще и подобных UDP), - если по вашим "доказательствам" даже 100 мБитный фаст изЕрнет - в состоянии справиться с 10 потоками MPEG-2 c битрейтом даже в 9.752 мБит/сек?

Да к стати! А не подскажете еще и то, почему: - в системах IP-CCTV не применяется метод кодирования MPEG-2?

Вот даже ШЗ-MGPEG - и есть, и применяется, а вот более "легковесный" MPEG-2, ну не как! :-)))

Ну и попутно, до кучи:

- Вокр"дУшка" :-)), а чем отличается BMP кадр, от RAW кадра с точки зрения передачи его по сети IP, но при условии что и тот и другой получен с матрицы ЧБ камеры?

Наконец, оценим вероятность того, что итервалы времени, когда все 10 камер транслируют опорный кадр, пересекутся, т.е. вероятность того, что создастся "пиковая исходящая скорость". Эта верояность P = (1/F)^10 = 1,7E-12

Мой злейший друг - построй (как я уже и предлагал) демонстрационный стенд из 16 камер собственно производства, запрограммируй в них величину GOP равную 15 (пусть даже для формата сжатия h264) с величиной битрейта 10 мБит/с - а затем выдерни вилку из розетки и с имитируй одновременную пропажу, а затем одновременное восстановление электропитания на всех 16 камера стенда. Вот тогда и будешь рассуждать об теории вероятности от Эйнштейна и теориях очевидных не вероятностей от Капицы.

PS

Описанная вами модель - это задачка для школьника третьего класса про бассейн, в который втекает 10 труб, а вытекает 1.

Это действительно задачка для младшего возраста. ;-)

Вот только условия в ней немного другие:

- Из бассейна, через наполовину забитую трубу канализации - капает вода.

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

Вопрос задачи ;-)

- До каких поры мы будем барахтаться и тонуть в этом IP-дерьмище, под "предводительством" выпускников лучших вузов столицы?

;-)

- Почему в эфирном DVB, занимающем один частотный ВЧ канал шириной 8 мГц, при возможности иметь скорость потока в 100 мБит/с (при QAM-256) и всего-то при разрешения SD вещания, но в формате MPEG-2 (50i) - в одном мультиплексе передается не более 6-8 транспортных потоков MPEG-TS.

По той же причине, что по одним и тем же линиям ТфОП по древнему стандарту ITU V.21 передавалось 300 бит/сек, а по самому современному стандарту ITU G.992.5 (ADSL2+) передаётся до 24 МБит/сек. Современные доступные вычислительные мощности позволяют использовать оптимальную модуляцию и приблизиться к пределу Шеннона пропускной способности канала.

Т.е. закономерность простая: старая технология - скорость низкая, новая технология - скорость высокая.

Да к стати! А не подскажете еще и то, почему: - в системах IP-CCTV не применяется метод кодирования MPEG-2?

Вообще-то применяется. Например, Bosch (которого так восхваляет Н.Е.Уваров) выпускает IP-CCTV MPEG-2 изделия, при этом позиционируя их, как дающие максимальное качество:

Bosch hardware using MPEG-2 delivers the highest quality pictures:

VIP 1000 MPEG-2 single-channel video encoder or decoder VideoJet 8000 8 channel MPEG-2 encoder

а чем отличается BMP кадр, от RAW кадра с точки зрения передачи его по сети IP, но при условии что и тот и другой получен с матрицы ЧБ камеры?

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

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

Таким пещерным способом, как предлагает В.В.Тюрин, синхронизации с точностью в милисекунды не добиться. Рассинхронизация и на старте будет превышать милисекунды, да и потом тактовые частоты камер "плывут", Чтобы смоделировать строгую по времени синхронность сетевых пиковых нагрузок, надо пользоваться методом Vocord IP-Syncro, разработанным компанией Вокорд. Но даже в этом случае правильно выбранный Ethernet-switch (с производительной матрицей коммутации и достаточным размером внутренних буферов) решает все проблемы неравномерности сетевого трафика.

Тюрин Вадим 14.08.2013 09:40: А чем дружище Вы, мне, прикажете заняться? Так что посоветуете?... Дружище! Куда "крестьянину" податься?

Попов Александр 11.09.2012 14:24: ...немцы и говорят, что на "шестисотых" у них ездят только чиновники очень высокого уровня и ...сантехники

Направление ваших мыслей, дорогой Вадим Викторович, определённо найдёт горячее одобрение Александра Леонидовича.

Обращаюсь ко всем.

У нас появился шанс не материть друг друга, как обычно происходит у нас с Уточкиным, а сделать полезную, коллективную работу. Мы все вместе сможем сделать IP сети понятными для многих, а не только для "избранных". Давайте без наездов говорить о теме. Публичный интим между между Тюриным и vocord.ru предлагаю перенести в другую тему.

Спасибо, надеюсь на понимание. Буду читать присланные Вадимом статьи.

Тезисы про первый и второй варианты не понятны.

Под первым вариантом имеется в виду способ организации "Hub", когда каждый ethernet-пакет транслирются на все порты, что эквивалентно топологии сети "общая шина" (более детально - CSMA/CD ) ?

Так вот, ethernet-коммутаторы с архитектурой "Hub" сегодня практические невозможно найти, они канули в лету более 10 лет назад.

Поэтому, рассмотрение "варианта1" имеет только теоретический и исторический смысл.

Любые современные Ethernet-коммутаторы (даже продающиеся по бросовым ценам ) имеют такую характеристику как Routing/Switching capacity (Ёмкость матрицы коммутации - ЁМК) - т.е. максимальный суммарный поток данных по всем портам. Именно эта характеристика устанавливает ограничение на максимальную скорость портов. Нужно просуммировать потоки по всем портам, и эта сумма не должна превышать ЁМК. Любой современный FastEthernet-коммутатор имеет ЁMK:

ЁМК >;= 200 МБит/сек * [число портов]

(обратите внимание, что 200 МБит/сек - в 2 раза больше чем 100 МБит/сек, потому что каждый порт FastEthernet обеспечивает дуплексный режим - одновременные приём и передачу 100 МБит/сек, т.е. 200 МБит/сек - двунаправленная скорость по порту Fast Ethernet Full Duplex).

Поэтому, формулы Вариант1 и Вариант2 - неправильны. Правильные формулы для FastEthernet-сети такие:

Vпр = 100 Мбит/сек = const

Vобр = 100 Мбит/сек = const

( Vпр - поток данных, входящий в порт, Vобр - поток данных, одновременно выходящий из этого же порта Fast Ethernet).

Под первым вариантом имеется в виду способ организации "Hub"

Вокор"дУшка"!

- Ну вы бы хоть для приличия что-ли, прежде чем нести ахинею про хабы, диалапы, адслы, и про 100 мегабитный двб-всех матсей в свете передачи 6-8 потоков MPEG-2, - статью-то прочли бы, в январском номере "Алгоритма" и тогда не задавали бы вопросов про инварианты:

Под первым вариантом подразумевается 100 мБит/с фаст изернет на "входе" и на "выходе".

Под вторм - 100 мбит/с на "входе" и 1000 мбит/с на "выходе".

Что такое "простой" коммутатор? Что автор имеет в виду?

Что такое "W – максимальная скорость порта (по паспорту)" ? Автор подставляет вместо W в свои формулы 100 МБит/сек. Т.е. автор считает, что "максимальная скорость порта (по паспорту)" для FastEthernet равна 100 Мбит/сек ?