Форум МАКАТЕЛ
Оборудование и SOFT => Головные станции => Тема начата: kaunis от 12.02.2016, 12:55
-
давеча получил небольшую плюшку от оптической волокиты,
вырубили аналог на профилактику,
а по оптике все показывало ...
Чем принимаете поток от РТРС у себя на ГС. Какой "железякой"
-
шлюз EMR 3.O
на входе мультикаст -на выход юникаст
-
На нашем РТРС стоит DGS-3124TC к нему воткнуты потоки с Хамелеона, отдают в IP/MPTS оба мукса (~33 Мбит/с каждый) + отдельно IP/SPTS Россия 24 (~3.5 Мбит/с), отдают только по L3 (PIM-SM).
У меня стоит на входе DGS-3612G, настроен PIM-SM с него уже в Tantrax, ну и дальше в IP и QAM.
Для резерва оставил в Tantrax карту T2, ну и для совсем уже плохого стечения обстоятельств держу тарель на 90й под основные т/к.
На аналог пока мне жмутся купить Roton, поэтому вещаю муксы откуда попало (эфир аналоговый и T2, НЧ с РТРС, спутник)
-
Аналогично, бывает вырубят на полдня Т2 и песец.
А ты думаешь, что у тех кто по опте присоединился писец ушел? Там скорее всего отрубают полностью всё.
Меня именно постоянные срывы сигнала с эфира T2 и смотивировали процесс переключения на кабель ускорить.
А в кабле по T2 отдавать не хотят, хотя сложного тут ничего нет и передатчик на 1310 волну можно купить (даже б/у).
Просто нет и все, типа вот ТУ - там все написано и идите лесом.
Есть кстати еще один плюс от этого присоединения (имхо конечно) всех местных доставщиков рекламы на каналы из этой 20-ки - послал нах... по направлению к РТРС. Теперь это геморрой их и РТРС о врезке рекламы, я законно буду получать сигнал у РТРС.
-
отдают только по L3 (PIM-SM).
Это значит , что не получится подцепить PBI или поглядеть VLC ?
-
отдают только по L3 (PIM-SM).
Это значит , что не получится подцепить PBI или поглядеть VLC ?
получиться. только надо будет ip, маску и шлюз выданный вам РТРСом прописать на PBI/ комп с vlc,
а так это обычный мультикаст.
PIM-SM тут для того чтобы развязать потоки ваши и РТРС (если вы заводите например потоки РТРС в общий коммутатор ГС)
тогда если на ГС у вас уже что-то приходит по IP (например на IP-QAM шлюз), то надо будет маршрутизатор/коммутатор L3 с поддержкой PIM, чтобы разрулить маршрутизацию из разных IP-сетей.
-
PIM-SM тут для того чтобы развязать потоки ваши и РТРС (если вы заводите например потоки РТРС в общий коммутатор ГС)
тогда если на ГС у вас уже что-то приходит по IP (например на IP-QAM шлюз), то надо будет маршрутизатор/коммутатор L3 с поддержкой PIM, чтобы разрулить маршрутизацию из разных IP-сетей.
А Vlan разные разве не решают эту проблему? Зачем еще маршрутизацию городить в пределах одного коммутатора ?
-
кроилово ведет к попадалову
экономия с физическим шлюзом штука веселая
-
В L2 Vlan ах от Мегафона , время от времени то один , то другой оператор начинает какать свои потоки в приемный конец со своего коммутатора с IGMP или другим L3 сервисом, позволяющим вызвать джинна в общий Vlan.
C L2 такого не может произойти , если уж только совсем кривые пальцы.
-
советую всем почитать, отличнейшая статья на тему: http://linkmeup.ru/blog/129.html
в век IP-коммутации приходиться вникать.... ээээхх где те счастливые времена ASI/BNC и AV/RCA ?! =)
-
В L2 Vlan ах от Мегафона , время от времени то один , то другой оператор начинает какать свои потоки в приемный конец со своего коммутатора с IGMP или другим L3 сервисом, позволяющим вызвать джинна в общий Vlan.
C L2 такого не может произойти , если уж только совсем кривые пальцы.
как раз с L2 это и происходит. По сути мултикаст на L2 = бродкаст. т.е. шлет все и всем.
именно L3, а точнее PIM решает проблему не запрошенного срача потоками из своей сети в чужую,
т.к. трафик разных сетей изолирован VLANами, а маршрутизируется между ними через IP-интерфейсы этих VLANов.
по ссылочке там все очень хорошо объясняют.
-
В рамках одного коммутатора на головной ;D
-
L3-коммутатора =) теже DGS-3124, 3612, 3627 не плохо варят мультикаст для небольшого сегмента.
хотя после Cisco 10720 плакать хочется от Dlink'ов =)
-
Задача на ГС противоположная - смешать N Vlan ов в N портов так, чтобы любой из Vlan ов не смог какать в другой ни при каких обстоятельствах. Мультикаст и так льется вам в порт и IGMP и PIM вам не понадобятся.
-
L3-коммутатора =) теже DGS-3124, 3612, 3627 не плохо варят мультикаст для небольшого сегмента.
хотя после Cisco 10720 плакать хочется от Dlink'ов =)
не надо все делинки под одну гребенку , не надо
Вы 3610 значит не видели , он даже на делинк не похож,
в кишках ios , на морду - про делинк и не подумаешь ,
работает изюмительно
-
(http://savepic.net/7704307.jpg)
схема работает уже года три , прожевать еще несчастных 70 мегабит - не проблема
-
А одноадресные потоки на выходе зачем ?
Какие то железки не понимают мультикаст ?
Единственно , зачем нужно L3 на входе , это случай если у вас в потоках более 100Мбит а порты ваши все сотки. В это случае IGMP вам отделит отдельные мультикастовые группы(если они есть ) :D
Сума потоки до 600 Мбит потоки разбирает легко без дополнительных ухищерений.
-
Ну если начать общаться то у Вас явные пробелы в знаниях построения коммутационных поток цифровой станции :)
Я руководствуюсь тем что ИСКЛЮЧИТЕЛЬНО я знаю куда и что будет отправлено ,
по этому я и использую исключительно юникаст .
Зная что QAM модуляторов 4 шасси,
зная что 2 комплекта шасси энкодер - кодер ,
зная что IP - PAL одна станция ,
я знаю что весь трафик уйдет ТОЛЬКО к ним ,
зачем мне тогда мультикаст ???? вот зачем ???
В ip тв уйдут каналы только те что есть в QAM значит я их и отдам через QAM и отдам их в мультикасте ,
потому что вот тут как раз и нужно что бы одно и тоже досталось всем , по моему все логично .
ПО L3 v-lanы есть (гибрид)
Шлюз в виде EMR 3.0 выполняет всю "грязную" работу по вычищению\редактированию PSI\SI ,
работе с джитером, выполняет функцию "предохранителя по битрейту"
(есть у нас идиоты которые могут подумать что пора бы поднять качество и задрать битрейт в два раза,
без шлюза mux ссыпется в труху, со шлюзом который настроен , только этот канал)
МОй принцип прост, QAM модулятор должен формировать и $ , стримить для IP TV, более он делать не чего не должен ,
по этому у всех приемных станций количесво IP для отправки статично,
по этому же на всех QAM станциях количесво ip адресов не ровно количеству каналов которые он транслирует,
а равно количеству приемных sat станций + 2 SDI кодера,
работать с пачками по 60 - 160 мегабит проще даже в отношении стафинга ! его будет куда меньше .
Все гениальное просто .
-
(http://savepic.net/7679503.jpg)
юникаст в действии
-
Я руководствуюсь тем что ИСКЛЮЧИТЕЛЬНО я знаю куда и что будет отправлено ,
по этому я и использую исключительно юникаст .
У богатых свои причуды.
На L2 разруливается ничуть не хуже.
Шлюз в виде EMR 3.0 выполняетфункцию "предохранителя по битрейту"
(есть у нас идиоты которые могут подумать что пора бы поднять качество и задрать битрейт в два раза,без шлюза mux ссыпется в труху, со шлюзом который настроен , только этот канал)
Вот этой функции я там не видел, может не там смотрел.
-
можно только представить сколько нужно внести правил в L2,
при этом я записываю только куда отправить ,
будем спорить у кого проще и надежнее ????
или так поверите ????
-
можно только представить сколько нужно внести правил в L2,
при этом я записываю только куда отправить ,
будем спорить у кого проще ????
или так поверите ????
Я исхожу из того , чем проще( а в данном случае и дешевле) тем надежнее работает.
У Дедлинков на L3 глюков тьма на части прошивок , и не узнаешь что в новой починили а что запороли , пока сам не проверишь в течении длительного времени.
-
по L3 , при покупке сразу был обновлен ,
настроен , более софт не меняли,
я напишу еще раз, на все делинки одинаковы !
есть делинки которые выглядят даже иначе !
и делаются они не в Китае , они же и управляются чуть иначе,
более того, тех поддержка делинка приезжая к на в гости,
посмотреть, почитать лекции, проконсультировать изернетчиков,
тихо на ушко грит ( хорошая штука )
-
я напишу еще раз, на все делинки одинаковы !
C этим согласен , некоторые линейки полное .......
-
Интересно как это можно мультикаст на L2 разруливать без срача в соседние порты? ACL тут не катят, да изврат это полный. PIM решает эту проблему на раз и очень просто.
У меня стриминг мультикаста для IPTV идет сразу с Tantrax'ов, и на QAM отдается с них же. Все завязано на одном DGS под каждое шасси свой vlan и интерфейс, везде включен PIM-SM, и при этом никакого лишнего срача между шассями, только то что запрашивают. РТРС прикрутился также просто, создан vlan и интерфейс, потоки завел на тоже шасси, где щас с Ямала беру, перебил источники для выходных портов и все.
Да DGS-3610 я видел, но гибрид солянки с борщем пугает еще больше :)
Кстати я не ругаю Dlink, они мне оч нравятся даже :)
У меня весь доступ абонентский на DES-3526/3200 и агрегация отдельных районов на DGS-3312/3710 в качестве гигабитных молотилок. Ядро сети было построено давно, до коммерческой сетки для физиков, там изначально киски стояли. Оператор этот раньше только на юриков работал.
-
да уж , 3610 стоит на приему IP с "внешних" сетей , по этому нет не солянок не борщей
и открою секрет можно сделать так , и не надо даже думать об изоляции V-lan SM
вот инструкция в картинках, как в "Мурзилке"
шаг первый , спутник - дескремблер - IP OUT too QAM
(http://savepic.ru/8710404.jpg)
Шаг второй
прием сервисов на порту и отдача в QAM Модулятор
(http://savepic.net/7723586.jpg)
в этой схема IGMP даже запрашивать не чего не надо ,
"коньяг сам с трубы льется, ложись и пей до усрачки , бармен не нужен"
а знаете почему ?
потому что юникаст это "фактически" TCP ,
не передача данных поверх чего то ,
а как раз та самая передача данных TCP
что бы понять разницу UDP и TCP
(http://savepic.ru/8707332.jpg)
тут даже и без очков видно что TCP прям явно в майке лидера .
" Вы все еще парите ? "
-
Видимо пора в отдельную тему выносить :)
На кой лес мне шасси за 150к использовать просто как шлюз мультикаст в юникаст? Таблицы я чищю и на основных, мультик вещаю сразу с принимающих шасси. Так и надежнее, вылетело шасси (тьфу-тьфу-тьфу) и я потерял всего 30-40 каналов, а не все разом еще и c QAM.
Холивара разводить не охото, но мультикаст тут намного гибче.
Проще поставить DGS за 60к (а б/у можно и дешевле найти) и на нем сделать как это положено делать.
Создаете влан, добавляете порты
Создаете интерфейсы, навешиваете на вланы
PIM-SM настривается в неск команд
conf igmp all st e
en igmp
conf igmp_sn all st e
en igmp_sn
conf pim all mode sm st e
en pim
Далее прописываете источники статикой
cr igmp st gr (мультикаст ip) rp (юникаст ip интерфейса)
Можно по одному с маской /32 можно диапазоном с любой маской
P.s. Что такое tcp я знаю.
-
чего, чего ?
Вы точно знаете что такое TCP ?
я столько кнопок при создании целого пакета в qAM модуляторе не нажимаю сколь Вы написали ,
чего там надо
Создаете влан, добавляете порты
Создаете интерфейсы, навешиваете на вланы
WTF ???
зачем ?
Что там гибше ?
ЧТо за создание трудностей ?
ВЫ одного видимо не можете принять, того что все Ваши действия в комутаторе не нужны ,
вот просто не нужны и ВСЕ , в схеме использования TCP надо что бы порты были соединены физически,
и что бы комутатор был включен в розетку, потом надо по тех регламенту пылевой фильтр чистить,
и все , вот просто ВСЕ !
вот тот текст на английском языке он не нужен , понимаете ?
да и к 150 , да кто же руки то выкручивает поставить можно и дешевле ,
но шлюз нужен, я ночь плохо спать буду зная что де факто сеть торчит жопой в интернет ,
при схеме со шлюзом , работает схема "за дверью , да пусть все сгорит или замерзнет, у меня не жарко не холодно"
-
не вижу смысла холиварить, и что-то еще доказывать.
считаете ваше решение лучшем в мире - ок =)
-
лучшим , нет !
коротким в настройке,
понятным в логике,
надежным в принципе работы,
это да ,
а лучшим нет , я это и не утверждал =)
лучшее это наверное если соединить Ваш текст и мой вариант, но я не уверен что бриджтех сможет зафиксировать разницу, с текстом или без оного
ПЫ СЫ попрожу админа вынести наши "терки" из ветки , отпишу ему в личку
-
Важный момент: EMR, в отличии от Luminato и Tangram, не поддерживает Vlan.
-
Важный момент: EMR, в отличии от Luminato и Tangram, не поддерживает Vlan.
EMR видит тегированный трафик ?
-
Важный момент: EMR, в отличии от Luminato и Tangram, не поддерживает Vlan.
EMR видит тегированный трафик ?
Вообще-то Gul написал, что EMR не поддерживает Vlan, и я не припомню там такой настройки
-
Очень не хочется плодить тему новую, давайте сюда уже все тех. вопросы стыковки с РТРС кидать.
Сегодня вот интересную особенность заметил с потоками от РТРС.
У меня отдается все в VBR (сразу скажу не тема очередного холивара)
с РТРС потоки приходят в CBR (добитые нулями).
Решил взглянуть на них через TSReader... и вот что увидел:
PCR всех каналов была под 15! Мбит видео и 1! Мбит звук (это уже потоки в VBR с моего EMR/Tantrax) при том выходные потоки всего 3,3-3,4M
Протер глаза, попил кофе и решил глянуть исходный поток РТРС.
Там все норм, видео 2,70-2,80М аудио ~192к.
Думаю что то тут не так, выставил на своих выходных потоках CBR 3,5М
и все пришло в норму.
При том артефактов не замечано, и на других потоках со спутника и кодеров с VBR после шасси, такого нет.
Кто что думает на этот счет? Глюк TSReader?
-
Вообще-то Gul написал, что EMR не поддерживает Vlan, и я не припомню там такой настройки
Я в a2b случайно обнаружил ( если я не путаю ,не использую и было давно), (там идиотская схема управление и мультикаст в одном порту) управление доступно только для нетегированных пакетов, мультикастовые потоки с тегом из разных Vlan ов при этом для самой железки прекрасно доступны.
Поэтому и спрашиваю, не пробовал ли кто с EMR это провернуть ?
-
не пользуйтесь шлако софтом :)
сколь раз уже писать , тсридер не в силах отличить vpid От pcr pida если тот вложен в видео
используйте приборы
-
Важный момент: EMR, в отличии от Luminato и Tangram, не поддерживает Vlan.
тут ошибка в логике , EMR этого не надо,
что бы разобраться в этом, надо всего лишь понять что такое коммутатор на логическом уровне ...
ну это нужно
Only fans of multicast
-
не пользуйтесь шлако софтом :)
сколь раз уже писать , тсридер не в силах отличить vpid От pcr pida если тот вложен в видео
используйте приборы
Обязательно буду, вод бакс обратно хотя бы до 40 упадет и буду плешь проедать топам) кстати железка есть, Tanberg TT, но там только ASI IN, нечем на нее поток передать :( да H.264 она не понимает, старенькая уже
На остальных ведь все прекрасно отличает. Если я Вам кусочег этого торта приглю в .ts, можно его на VB подать для анализа?) так просто душу успокоить)
-
atx, не совсем понял, вы поток смотрели напрямую с РТРС? тогда где меняли CBR?
TSReader - нормальная программа, поставьте себе ещё StreamGuru и будет вполне рабочий комплекс.
Перед покупкой VB ещё раз подумайте, штука не плохая, но не без изъянов, а стоит не мало.
sky star, вы только не обижайтесь, но ваше упертое использование юникаста больше походит на старообрядчество, возможно я и заблуждаюсь, но я так и не понял в чем же реальный плюс такого метода?
-
а что за изьяны у VB я бы хоте узнать ,
и по подробнее,
ибо у меня под рукой VB 120 три года и я изьяны не нашел пока ,
хотя юзаю все порты, IP ASI SAT QAM
по юникасту - может и старообрядничество ,
но использование там где это можно и это работает и не накладывает вообще не каких ограничений это ПРАВИЛЬНО,
это как ,
"можно потратить мильон долларов на разработку ручки что бы писала в космосе,
а можно по СТАРООБРАДНИЧЕСКИ писать карандашом, сохранив и деньги и время"
да и простите, если обидел
-
atx, не совсем понял, вы поток смотрели напрямую с РТРС? тогда где меняли CBR?
TSReader - нормальная программа, поставьте себе ещё StreamGuru и будет вполне рабочий комплекс.
Перед покупкой VB ещё раз подумайте, штука не плохая, но не без изъянов, а стоит не мало.
sky star, вы только не обижайтесь, но ваше упертое использование юникаста больше походит на старообрядчество, возможно я и заблуждаюсь, но я так и не понял в чем же реальный плюс такого метода?
1) Смотрел исходный поток приходящий с РТРС, CBR = 3,3М, видео 2,7-2,8М, аудио ~192к
2) Подал поток на EMR и выдал в IP, VBR = 3,3-3,4М, видео 3-10М, аудио ~800-1000к
3) Подал поток на EMR и выдал в IP, СBR = 3.5М, видео 2,7-2,8М, аудио ~192к
p.s. нашел таки как подать поток на анализатор Tanberg TT4010, вспомнил про карточку ASI С350 для EMR на складе =)
Tanberg подтвердил показания для 1, 2 и 3. А также показал срывы PCR
Подал оба мукса РТРС на ASI-out карты и другой конец в ее же ASI-in. Включил на ASI-out карты PCR adjust и PCR regen.
После этого все пришло в норму, хоть CBR хоть VBR. PCR ровненький, видео всего на ~40к отличается от изначального, звук один-в-один
Я начал эту всю проверку, потому как нет-нет а срывы бывали. Осталось теперь понять откуда ноги растут...
-
скорее всего С355
так как С350 только in
-
Ноги ростут вот отсюда
(http://savepic.net/7770525.jpg)
на профильном форуме пишут что трудно работать с таким сигналом :)
а хамилион подкинет еще проблему когда свалиться в штопор,
потеряет PLP , растусует все хрен победи как,
и пишут что пока его с розетки не дернешь,
сам вряд ли вылечиться ,
но это все лирика
-
а что за изьяны у VB я бы хоте узнать
тут смотря, что от него ожидать, вот например, определение состояние скремблирования канала доступно только через опцию ETR, т.е. для онлайн мониторинга, скажем 100 каналов будут трудности. Есть ещё такая штука, что по идеи MLR и СС errs - это одно и тоже и время их появления должны совпадать, как правило так оно и есть, но не всегда. Очень убогий лог ошибок, прям удручает, возьмите SreamGuru - сколько нужно столько и будет лог писать.Ноги ростут вот отсюда
от куда скриншот?
-
по СА , да она доступна в ETR , но за три года , реально СА понадобилась только при узко специальном допиливании кое чего,
более это не требовалась, запущеный $ работает :) он просто работает и все , мониторить СА можно, но если есть проблема
с железом, но это не проблема VB , это проблема железа, я повторюсь,
мне за три года достаточно после перелопачивания сети один раз посмотреть ,
как работает $ , периоды СА , EMM ECM , и все - что там мониторить то ?
(http://savepic.ru/8660173.jpg)
не монимаю, сделал, ребутнул скремблер , глянул - потом до следующего раза ,
или у Вас не так ?
Если не так то надо что делать с железом .
По MLR если Вы на это не можете повлиять, то будь у Вас лог 10 см , или 100 метров,
то врядли что то измениться , однако когда я мониторю Синтерру Медиа,
мне достаточно того что дает VB , техники на той стороне реагируют ...
как то так
-
Обязательно буду, вод бакс обратно хотя бы до 40 упадет
Не знал.
-
тут смотря, что от него ожидать, вот например, определение состояние скремблирования канала доступно только через опцию ETR, т.е. для онлайн мониторинга, скажем 100 каналов будут трудности. Есть ещё такая штука, что по идеи MLR и СС errs - это одно и тоже и время их появления должны совпадать, как правило так оно и есть, но не всегда. Очень убогий лог ошибок, прям удручает, возьмите SreamGuru - сколько нужно столько и будет лог писать.
MLR и СС, это все таки немного разные вещи. СС errors могут легко появится, при отсутствии MLR, а вот наоборот, вряд ли.
Состояние скремблирования, не совсем понял, что имеется в виду. Если просто, скремблирован/не скремблирован, смотрим на вкладке мониторинга, для всех каналов, и в ETR ходить не надо. Если именно анализ сообщений CAS, тут да, увы, только через ETR.
По поводу логов. Есть такая штука - VBC. Раньше он был бесплатным в базовой комплектации, при условии подключения до двух анализаторов. Там с длиной логов проблем нет.
-
MLR и СС, это все таки немного разные вещи. СС errors могут легко появится, при отсутствии MLR, а вот наоборот, вряд ли.
я даже и не против, но если вы поясните в чем разница, то буду признателен
Состояние скремблирования, не совсем понял, что имеется в виду. Если просто, скремблирован/не скремблирован, смотрим на вкладке мониторинга, для всех каналов, и в ETR ходить не надо.
Имел в виду именно скремблирован/не скремблирован канал, в мониторинге не нашел, если тыкнете пальцем, то буду признателен, но помойму, там нет такого.
По поводу логов. Есть такая штука - VBC. Раньше он был бесплатным в базовой комплектации, при условии подключения до двух анализаторов. Там с длиной логов проблем нет.
В VBC проблемы может и нет, а вот в VB есть.
sky star, мы используем VB как систему мониторинга (используем VB120 - статичный мониторинг, VB20 - перенастраиваемые анализаторы) т.е. у нас все каналы монитрятся всё время, это позволяет решать вопрос не по принципу "начнем собирать статистику и будет видно", а "сейчас глянем статистику и станет ясно", очень знаете ли экономит время. Состояние скремблирования (не только его) мы проверяем не после модуляторов, а после SAT приемников или на других источниках.
Скажем так, когда настраивал VB очень жутко матерился про себя, была куча нюансов, которая не устраивала, но сейчас настроил и забыл, только статистику поглядываю, и к слову не смотря на то, что VB позиционируется как профжелезо, у шасси всего только один БП, что как бы не характерно для профа.
-
skarxxl а подробнее, с примерами что Вы мониторите
после SAT приемников или других источников ,
я бы проникся и помониторил, вдруг мне надо тоже
теперь конструктивно, на фразу "очень знаете ли экономит время"
Вы сколько раз до обеда и после обеда бегаете домой что бы
проверить проверку той крайней проверки до следующей проверки вдруг дверь не заперта
я комплекс который работает знаю, если возникнет манюсенькое при манюсенькое подозрение , то стану рыть,
а тупа снимать данные , что бы эти данные потом в logах лежали мне незачем ,
город маленький , каких то 300 000 населением
и на счет проф
(http://savepic.ru/8704217.jpg)
профистее просто некуда, дорого, и буржуйское , могу привести еще примеры
-
Имел в виду именно скремблирован/не скремблирован канал, в мониторинге не нашел, если тыкнете пальцем, то буду признателен, но помойму, там нет такого.
Посмотрите вложения.
В VBC проблемы может и нет, а вот в VB есть.
Так VBC как раз был создан для расширения функционала VB, для тех, кто не желает заморачиваться интеграцией, SNMP и т.п.
-
skarxxl а подробнее, с примерами что Вы мониторите
мониторится весть тот мультикаст, который в дальнейшем идет либо к абонентам либо используется для QAM или analog модуляторов (пример загрузки модулей)
к слову, один раз столкнулся с ситуацией, когда один канал, размещавшийся на нашей площадки, отдавал канал Ростелекому, а те его не принимали т.к. за сутки было более 24MLR т.е. своего рода свой внутренний стандарт. Посидел, подумал, а ведь и верно, чтобы канал совсем не сыпал - такого практически не бывает, нужен какой-то допуск и критерий "больного" канала, с которым нужно решать вопросы. Суть в том, что теперь не абоненты мониторят качество (хотя куда без них), а мы сами. Да и ситуаций когда, абонент звонит и говорит, что у него вечером каналы сыпятся, а линейщики, мол проблема на головной удается избегать.
DK, вы только не обижайтесь, но это не рабочая схема, а всего лишь хитрость, то что вы прислали это всего лишь возможность определить скремблированный канала или нет, зайдя на страницу мониторинга, а т.к. каналов 100, то получается 10 страниц, которые оператор должен протыкивать? Не смешите мои подковы, конечно, каждая картинка имеет свой адрес, но тогда нужна система сравнения картинок? Да и с обновлениями картинок тоже какая-то трабла была... то ли обновлялись только когда страница мониторинга раскрылась, то ли ещё что-то.... уже и не вспомню. В общем для реальной системы пригодна только ETR
-
DK, вы только не обижайтесь
А мне зачем обижаться, мы же не мои функции, как человека, обсуждаем? Вы пишите, что нельзя смотреть, я пишу, что можно. Я же специально спросил, что нужно определить... Изъясняйтесь более ясно, что ли.. Задача была увидеть скремблированные каналы в списке.
В мониторинге два режима. Постраничный и All streams. В режиме All streams нет никаких проблем крутнуть колесо мыши и просмотреть какие каналы у нас скремблированы. Хоть их будет сто, хоть двести. Естественно речь об SPTS, мы же о них говорим? Да, маленькая оговорка. В режиме All streams параметры отображаются в режиме offline, но нам ведь не требуется online, когды мы решаем именно Вашу задачу с вычислением скремблированных каналов...
И никаких хитростей, нужно просто знать, как работает оборудование.
Про сравнение картинок вобще не понял. Что мешает поименовать каждый SPTS по названию канала?
-
DK, суть мониторинга в оперативном получении информации о проблеме т.е. режим офлайн точно не прокатывает, да и прокрутка колесиком туда сюда тоже не есть гуд.
Если говорить уж совсем просто, то у дежурного на экране должна появляться надпись: "канал такой-то скремблированн" и он уже по инструкции начинает выяснять проблему. Естественно, что VB сам не сможет зажечь лампочку и его нужно интегрировать во что-то (интерфейс системы мониторинга), а для этого данные от VB нужно получить. Вот я и спрашиваю: как получить данные о скремблировании канала, не используя ETR? Картинка - тоже данные, но её нужно верно суметь интерпретировать, ведь так? А сделать это можно только сравнивая изображения.
-
как получить данные о скремблировании канала, не используя ETR
Здесь вопрос в другом. Я понял, что Вам нужно. Это не совсем обычная задача. Дело в том, что если канал скремблирован, это не является ошибкой. Для канала как раз нормально быть скремблированным. Или быть не скремблированным. Переход из одного состояния в другое тоже не является ошибкой и не описан как ошибка ни в одном стандарте. Поэтому и нет функции контроля (именно как ошибки) этих состояний ни в одном известном мне анализаторе.
И именно для таких ситуаций существуют видеостены, и диспетчеры, которые на эти видеостены смотрят. Замерла картинка - получаем типичную ошибку Freeze, идем разбираться с помощью анализатора, кто же этот фриз вызвал. И это стандартная функция систем визуального мониторинга (видеостены) и на такую ошибку она активно отреагирует, сирену включит, голосом закричит.
А Вашу задачку с помощью VB, я думаю, решить можно, но это вопрос опять же интеграции, нужен грамотный программист, который сможет превратить "неошибку" в "ошибку". Благо, у бриджтеха все материалы по интеграции открыты и доступны для пользователей.
Пора уже третью тему выделять. ;) Как-то было дело, тут пытались поговорить об анализе/мониторинге, да не взлетело. Зато сейчас... :o
-
по поводу канал $ от себя добавлю, документирование/логирование это одно дело,
а вот что бы у дежурного возникла инфа ,
тут надо типа мультискрина - видел как мониторят 20 каналов ,
от мониторинга 100 каналов я думаю надо молоко давать,
а если 200 каналов - то пенсия через пару лет
фактически на мультскрины нужно выдавать состояние одного QAM пакета,
и тогда я бы получил 32 телевизора 42"-46" ,
а что будет когда на аплинке гроза придет, или на приеме гроза будет, или случиться сразу и тут и там,
то дежурный смены с ума сойдет , но его можно заменить, а вот тот кто будет логи разгребать ...
тому молоко , покой ...
-
Дело в том, что если канал скремблирован, это не является ошибкой.
абсолютно согласен
Переход из одного состояния в другое тоже не является ошибкой
это не является ошибкой, но является событием!
И именно для таких ситуаций существуют видеостены, и диспетчеры, которые на эти видеостены смотрят.
эм... скажем 150 каналов... это ж какая стена нужна, да и дежурный помимо просмотром ТВ занимается другой работой
А Вашу задачку с помощью VB, я думаю, решить можно
можно, я её решил через ETR, хоть скорость реагирования и снижена (из-за поочередной проверки), зато работает
тут надо типа мультискрина
мультискрин - бред, нужна лампочка или звонок (был вариант контакную пару к креслу оператора) чтобы возбуждать его только по аварии
DK, вы мне так и не ответили, чем отличается MLR от CC
sky star, так чем же всё таки юникаст лучше мультикаста (если не принимать во внимание: "я настроил и оно работает")?
:) а то как-то и в правду отклонились от темы
-
собственно, что бы не мусорить в интересной теме, внес предложение вот тут (http://macatel.ru/forumsmf/index.php?topic=9684.0)
-
это не является ошибкой, но является событием!
Совершенно верно. Я сейчас бегло просмотрел Eii Bridgetech. Любой параметр можно выдернуть из анализатора и интерпретировать его как угодно, но с помощью стороннего ПО. Т.е. можно сделать ошибкой переход состояния в SCR.
И я еще раз намекаю на демонстрационные версии VBC и VB288. Посмотрите, может быть удастся расширить функционал до требуемого. Это не железо, софт, скачал, установил.
эм... скажем 150 каналов... это ж какая стена нужна, да и дежурный помимо просмотром ТВ занимается другой работой
Лехко. Но очень дорого. Я видел видеостены и на большее количество каналов. Дежурных, конечно, несколько.
DK, вы мне так и не ответили, чем отличается MLR от CC
В моем понимании. MLR - потеря пакетов транспорта UDP/RTP. CC - потеря, либо нарушение последовательности пакетов MPEG-TS
-
И я еще раз намекаю на демонстрационные версии VBC и VB288
Намек, я понял. На самом деле уже качал, ставил, смотрел... но т.к. всё равно нужна интеграция с существующей системой мониторинга, поэтому VBC - просто деньги на ветер.
Любой параметр можно выдернуть из анализатора и интерпретировать его как угодно, но с помощью стороннего ПО.
Всё верно, но к сожалению нет инфы где найти требуемое?
В моем понимании. MLR - потеря пакетов транспорта UDP/RTP. CC - потеря, либо нарушение последовательности пакетов MPEG-TS
возможно я и ошибаюсь, но мне кажется, что в том же описании VB было написано, что высокие значения IAT приводят к возникновению MLR, значит MLR всё же нарушение последовательности. ..
-
Я уже как бы сообщал чем юникаст способнее мультикаста,
даже скрин прилагал, но могу повторить,
в первую и решающую тем что ,
юникаст это фактически TCP ,
а мультикаст это UDP,
чем один от другова отличается можно почитать
-
Всё верно, но к сожалению нет инфы где найти требуемое?
Eii_External_Integration_Interface_a21.pdf
3.2 Detailed information for one Transport Stream
When accessing the URL /probe/etrdata?inputId=XX&tuningSetupId=YY where XX
is set to the input ID and YY to the tuning setup ID for a given stream (found in
the /probe/etrdata xml), the probe will return detailed information for the
specified transport stream.
● PID list. Key parameters: id, current, minimum and maximum bitrates, PID
type, maximum pcr jitter, cc error count, [b]scrambling [/b]information
Это не оно?
возможно я и ошибаюсь, но мне кажется, что в том же описании VB было написано, что высокие значения IAT приводят к возникновению MLR, значит MLR всё же нарушение последовательности. ..
Лучше читать первоисточник, а именно, стандарт, описывающий методику MDI (RFC 4445 https://tools.ietf.org/html/rfc4445)
Но, в принципе, бриджтех прав. Высокие значения IAT говорят о "некачественном" транспорте и потеря пакетов здесь вполне возможна. Да, конечно, нарушение последовательности пакетов, это тоже MLR.
-
чем один от другова отличается можно почитать
чем отличается TCP от UDP на самом деле я представляю, но в плане работы ГС не понял.
DK, дадите ссылку на Eii_External_Integr ation_Interface_a21 .pdf ?
Это не оно?
не оно, т.к. идет описание ETR (через него мы и сделали), а не Mon, да и про scrambling нет информации
<pidList>
<pid id="0" bitrate="3256" minBitrate="1472" maxBitrate="5304" pidType="PAT" numCcErrors="8"/>
<pid id="8" bitrate="3256" minBitrate="1472" maxBitrate="5304" pidType="Unknown" numCcErrors="3"/>
<pid id="1760" bitrate="3256" minBitrate="1464" maxBitrate="5440" pidType="PMT" numCcErrors="4"/>
<pid id="2104" bitrate="2491736" minBitrate="2437992" maxBitrate="2560960" pidType="MPEG2 Video" maxPcrJitter="NA" numCcErrors="21"/>
<pid id="2105" bitrate="74912" minBitrate="72384" maxBitrate="78232" pidType="MPEG1 Audio" numCcErrors="9"/>
</pidList>
-
в первую и решающую тем что ,
юникаст это фактически TCP ,
Вот поэтому и в стране разруха.
Ампер - это фактически сечение. Как-то так . :(
-
Ну тут целая поэма получиться если расписывать.
Вот смотрите , у нас станция маленькая, 15 sat приемников, 1 T2 , и 1 Gate , и 2 SDI mpeg2
получается 19 штук источников сервисов.
Далее у нас 4 QAM модулятора
и 2 SDI приема .
Получается что все что будет принято от всех возможных источников , будет иметь быть отправлено не более чем в 6 адресов !
Улавливаете мысль ?
Тут обычно возникает улыбка и возглас "мол куй то угодал товарищь !" а как же IP TV ?
как ты мол его юникастом то мол , а ???? умник мол !
На что я говорю, что мы не стали мудрствовать лукаво и у нас все QAM EMR имеют лецензию на все порты ,
тут апонент обычно скисает , мол дорого ...
А поскольку список в ТВ и IP TV почти не отличается, все что приходит юникастом в порт GBE2 ,
отправляется в QAM card и отправляется в GBE1 но уже мультикастом ,
но что там за GBE1 происходит меня волнует примерно так же как события на Альфа Центавре .
Отправляя трафик юникастом я минимализирую любые ошибки в логистике потока ,
ибо если я ошибусь, то я просто сервиса на искомом порту не увижу ,
отправляя трафик юникастом я более разумно использую "стафинг"
в QAM я подаю CBR .
Завершая поэму , можно сказать , что протокол TCP он изначально родной для передачи данных,
а вот UPD приручали , приручают, и еще будут приручать ой как долго .
-
Завершая поэму , можно сказать , что протокол TCP он изначально родной для передачи данных,
а вот UPD приручали , приручают, и еще будут приручать ой как долго .
:-\ :-\ :-\Теперь все стало понятно. Даже не поспорить.
Отправляя трафик юникастом я минимализирую любые ошибки в логистике потока ,
ибо если я ошибусь, то я просто сервиса на искомом порту не увижу ,
отправляя трафик юникастом я более разумно использую "стафинг"
в QAM я подаю CBR .
На самом деле в мультикаст пакетах значение некоторых байтов попадает во определенный диапазон, из чего коммутатор делает вывод, что пакет нужно рассылать по другим правилам.
Более существенных различий как бэ нет :)
-
1076 Я с очень большим вниманием прочитаю Вашу трактовку передачи данных юникастом .
-
DK, дадите ссылку на Eii_External_Integr ation_Interface_a21 .pdf ?
Ссылку не могу дать, оно в закрытом разделе Bridgetech. Запросите у своего поставщика доступ. Там не только инструкции лежат, но и обновления ПО.
Описание интерфейса интеграции во вложении.
-
1076 Вы знаете что в юникасте указывается порт получателя ???
и для этого не требуется дополнительный "светлый разум" между отправителем и получателем,
это как бы сразу делается , чего проще то ?
-
Ну во-первых ТСР как был изобретен для г...о линий связи, где была необходима проверка и отправка запроса отправителю на повторное получение потереного куска.
UDP не волнуют ошибки на транспорте пакетов, он просто "льет воду", а механизм выявления и коррекции ошибок перекладывает на протокол верхнего уровня.
Для MPEG-TS - TCP зло! Потому как проще одбросить битый кусок потока и рассыпать картинку на квадратики, чем пытаться восстановить целостность повторным запросом этого куска. В первую очередь это ударит по синхронизации.
Для хорошей сети (читай идеальной), который является коммутационная шина коммутатора - фиолето вообщем то ТСР или UDP. Но "стандарт" де-факто передавать MPEG-TS в UDP-пакетах.
Юникаст - один отправитель = один получатель (на сессию), т.е. для каждого отправителя надо создавать отдельный канал связи - сессию, поэтому там стандарт де-факто TCP (но не всегда). Не мало важно, что необходимо дублировать трафик. Это у вас все подключения точка-точка, а если надо отдать поток в несколько железок? Это уже битрейт*железки.
Мультикаст - один отправитель - пофиг сколько получателей. Там не важно кто получит трафик, главное идентифицировать его (ip группы) и сообщить стеку tcp/ip, что шлет его Вася с ip 1.2.3.4 и порта 1234. Значит не надо устанавливать сессию, значит идеально для передачи в одну сторону, значит идеально подходит UDP.
А чтобы трафик у вас без присмотра не блуждал по коммутатору, умные дядьки и придумали мультикаст-маршрутизацию, где PIM стал стандартом де факто (кроме особых случаев).
По поводу вашей схемы, не вижу смысла собирать все по юникаст на одном шасси, тем более с него стримить и в QAM и в IPTV. Как минимум это нужно вторую железку рядом в горячий резерв. И да именно под вашу схему фиолетово мульти или юни.
-
НЕ вижу не чего того что бы я не знал,
но вижу то что мне совсем не сложно при гигабитных портах ,
отдать несколько десятков каналов в QAM, единицы в IP - PAL.
Да и трафик у меня не блюждает и без присмотра "светлого разума" ,
он просто изначально не может блуждать, я ему это не дозволил .
Ударов по синхонинизациям не выявляли несколько недельные
мониторы ERT 290 /
Да и я не собираю весь трафик юникаста в одном шасси ,
таких шасси 6 .
-
Да и еще, при всем моем уважении, я всякий раз слышу фразу
"надо отдать в несколько железок "
напишите хоть кто нибудь, сколько этих железок ?
ну кто нибудь напишите ?
25 \ 50 \ 100 \ может 200 ???
или может быть их и до 10 не досчитать ?
-
f_emo_27 Я описал общий случай, по вашей схеме последний абзац.
У меня 4 шасси ЕMR (Tantrax), три прием и отдача в IPTV, один QAM. IPTV летит на ПК для мониторинга, летит на сервак под юникаст для смарт-телегов и прочий гаджет-тв. Еще есть источники от старенького SA D9600 (в основном кодеры подкл по ASI), который изначально про юникаст не знает. Еще два Форварда отдают мультикаст мне и др оператору, и теперь еще солянка с РТРС.
Я доказать не хочу как лучше. Мне как сетевеку, мултикаст и маршрутизация роднее. А так оба варианта по настройке не сложны, а оборудование по цене фактически одинаково (не на DGS-1016 же вы все подключаете), каждый выберет свое решение, с поправочкой на ТУ РТРС.
-
напишите хоть кто нибудь, сколько этих железок ?
ну кто нибудь напишите ?
25 \ 50 \ 100 \ может 200 ???
или может быть их и до 10 не досчитать ?
ИМХО, да хоть от двух начиная уже разумнее мультикаст.
-
К теме по самому РТРС (буду тута флудить). Сегодня второй мульт опять сыпет весь день. У нас прием идет с Ямал-401, первый мульт 4024L, второй 4026R. Сдается мне, что у них проблемма на приеме, т.к. от перегруза ошибками бошку сносит их модулятору (слухи дошли что просто повисает :) )
Разведка доложила, что схема всего зоопарка у них такая:
На приеме стоят Гармоники (по одному на мукс), далее все слитается на какой то мега-ремультпплексор (какой не сказали), там рабирается на spts, туда же подмешивается местная версия этих каналов (наложение рекламы + перехват ГО и ЧС). Далее все собирается в два мукса, подается модулятор T2 и отдается в эфир. В "разрез" эфира и выхода модулятора, сигнал отдается на хамелеон на обычный T2 приемник, а с хамелеона уже отдается по IP. Выглядит жутко :) учитывая разношерстность всего зоопарка железа.
-
1076 Вы знаете что в юникасте указывается порт получателя ???
Вижу дальнейшая дискуссия смысла не имеет.
-
Выглядит жутко :) учитывая разношерстность всего зоопарка железа.
Вот это больше всего смущает.
-
IP FEC всех спасет ;D
-
Да как бы вопрос то простой, зачем было эту пирамиду городить, когда есть вполне себе платфомы все-в-одном. Думаю те же китайцы под гос заказ в сотню шасси, могли бы норм цены предложить. Нет надо было по старинки собрать, дорого и сердито :) еще не удевлюсь, что там ASI на межблочье :)
-
IP FEC всех спасет ;D
Имхо, мертворождено. Слишком дорогая защита, для дешевого IP-транспорта.
-
Имхо, мертворождено. Слишком дорогая защита, для дешевого IP-транспорта.
Для межблочной коммутации, согласен, из пушки по воробьям. Проще и дешевле поставить/настроить правильный коммутатор.
А вот когда появляется станция с распределенными IP-QAM модуляторами и поток до них доставляется не по самым лучшим каналам, через несколько коммутаторов...
-
Имхо, мертворождено. Слишком дорогая защита, для дешевого IP-транспорта.
Для межблочной коммутации, согласен, из пушки по воробьям. Проще и дешевле поставить/настроить правильный коммутатор.
А вот когда появляется станция с распределенными IP-QAM модуляторами и поток до них доставляется не по самым лучшим каналам, через несколько коммутаторов...
Тут тоже надо считать. Если сеть своя, сегменты не по 1000км, то проще QOS или вообще отдельное волокно.
FEC вещь необходимая для передачи на огромных скоростях (10-100G) по оптике на большие расстояния (>70-100км). Там из-за использования сложных модуляций и особенностей передачи по оптике (дисперсия в первую очередь), необходим большой уровень SNR. FEC помогает хоть как то переложить проблему на вычислительный уровень.
-
сылку не могу дать, оно в закрытом разделе Bridgetech. Запросите у своего поставщика доступ. Там не только инструкции лежат, но и обновления ПО.
Понял, спасибо, доступ в этот раздел есть, был по крайней мере, поищу там.
sky star, вашу схему я, кажется понял: вы с приемников подаете юникастом на модулятор, который помимо QAM ещё вещает и мультикаст...
если честно, то у меня есть некоторые сомнения в целесообразности, вот смотрите, как кто-то здесь правильно написал, UDP (мультикаст) - это броадкаст т.е. если какой-то пакет запоздает или придет битый, он просто отбросится и абонент увидит рассыпание картинки; если же использовать TCP (юникаст), по пакет будет перезапрошен и что в этот момент увидит абонент фриз или пропадание изображение? Думаю второе т.к. QAM - это уже , или я ошибаюсь? И что будет дальше, если ошибок (скажем по видео пиду) будет много, будет происходить рассинхронизация видео и звука?
sky star, что-то меня подобная схема смущает, или я где-то ошибся?
-
Ну наконец то, опасения однако ошибочны :) перезапросов не происходит ,
почему рассказывать не буду (хотя бы исходя из того что тот же гармоник позволяет вещать юникаст,
не было бы гарантий качества , тупа не было возможности)
А схема, схема простая, линейная :)
И не одного меня если посмотреть
http://macatel.ru/forumsmf/index.php?topic=2320.msg51828#msg51828
один я бы мог ошибаться и не замечать фризов или пропаданий,
но вот двое :)
Фишки юникаста документирована, по этому используется по полной :)
-
да и что Вам мешает отправить какой либо канал юникастом в Бриджтех ?
Все у Вас уже там, а один добавить и тупа посмотреть ETR :)
В 2012 году я схему коммутаций нарисовал очень крутому цискарю (он как раз читал коммутатор станции) будучи на семинаре САТпро,
он отошел пару шагов, еще раз посмотрел, и спросил, а что тебя смущает ?
А сказал что не чего :)
Потом он сказал что тут проблем не может по логике даже :)
-
sky star дружище, да никто же не говорит что ваша схема ошибочная =)
имхо, она чутка избыточна, ведь мультикаст можно отдавать сразу с приемного шасси - это в принципе его основной функционал, принять + обработать + отдать потребителю, иначе нафиг вся эта 3G-платформенность? =)
ваша схема слегка напоминает мне мой старенький добрый Scientific Atlanta D9624 ASI-ремультиплексор со встроенным IP-стримером,
где заводилось все по "юникаст" ASI и выдавалось по "мультикаст" IP.
и еще вопрос, а как вы будете при вашей схеме РТРС-мультикаст заводить? на отдельный порт EMR (лицензия стоит не копейки)?
Ведь просто воткнув его в ваш L2 коммутатор, его не получиться принять без нахождения IP-интерфейса EMR с IP-интерфейсом РТРС (выделенном для вас) в одной IP-подсети. мультикаст просто не польется к вам, т.к. не знает куда =), т.к. собственно сам PIM ничего не маршрутизирует, а только строит путь от потребителя к источнику, маршрутизацией занимается протокол обычной unicast-маршрутизации.
-
как я завел все внешнии источники , так и сейчас беру с ОРТПЦ сигнал оцифрованного аналога для IP-PAL ,
в тоже волокно вдуют РТРС 1 и РТРС2 и все будет так как работало пару лет назад :)
(http://savepic.ru/8650855.jpg)
-
Все "местное" все такое вшивое, по этому за имя надо ухи держать в настроенном состоянии,
они могут и битрейт поднять, и пиды поменять, и могут жахнуть в место mpeg2 пульнуть mpeg4,
надо короче бдить, шлюз в этом случае прям меня выручает :)
Все сделано тоже три года назад было, и сейчас только растет предложение "возьмите нас пожалуйсто" :)
По этому я тут готов был задоооооооооооооооо ооооооооооооооооооо ооооооооооооооооолг о до РТРС1 & РТРС2
-
Ну наконец то, опасения однако ошибочны перезапросов не происходит, почему рассказывать не буду
лучше расскажите т.к. отличие юникаста от мультикаста как раз в том, что есть возможность проверить доставку пакетов и в случае необходимости перезапросить её.
-
если же использовать TCP (юникаст), по пакет будет перезапрошен и что в этот момент увидит абонент фриз или пропадание изображение?
Не увидит, размер буфера , как правило несколько секунд, за это время пропавшие пакеты будут перезапрошены, но к мульти(уни) касту это отношения уже не имеет.
-
Не увидит, размер буфера , как правило несколько секунд, за это время пропавшие пакеты будут перезапрошены, но к мульти(уни) касту это отношения уже не имеет.
Погодите, по логике вещей, если имеется буфер в несколько секунд, то это как раз для юникаста и нужно, чтобы была возможность сделать перезапрос, к мультикасту же он отношения не имеет - тут согласен
-
осталось только найти причину по которой возникнет необходимость
запросить тот самый пакет :)
-
осталось только найти причину по которой возникнет необходимость
запросить тот самый пакет :)
согласен, что что единственной такой причиной может стать дроп на порту, что у приличного оператора маловеротно.
в предидущем посту, я немного не корректно написал, что буфер не имеет отношения к мультикасту, это не совсем так т.к. мультикаст - это помимо UDP ещё и RTP, а вот особенность RTP - он действительно кешируется, следовательно его применение в рамках ГС более оправданно... как-то была у меня мысль перейти на RTP, но что-то меня удержало...
Следовательно, если нет дропов, то разницы между юникастом и мультикастом (RTP) нет (разумеется кроме многоадресности)?
-
Не увидит, размер буфера , как правило несколько секунд, за это время пропавшие пакеты будут перезапрошены, но к мульти(уни) касту это отношения уже не имеет.
Погодите, по логике вещей, если имеется буфер в несколько секунд, то это как раз для юникаста и нужно, чтобы была возможность сделать перезапрос, к мультикасту же он отношения не имеет - тут согласен
Буфер есть в любом случае, хоть с Tcp, хоть с Udp.
Да и вопрос даже не в этом, вопрос в юникате или мултикасте
И юникастом в тср вещают (hls как пример), но делается это прежде всего из-за того, что приходится отдавать потоки через "чужую" сеть (например интернет тв), или по каналам с значительным процентом негарантированной доставки пакетов (например по wifi на гаджеты). Там вариантов, кроме как отправлять по юникаст/тср и ждать буферизации больше и нету. Но там (инет тв или вещание по wifi на гаджеты) и битрейт потоков поскромнее, поэтому буферизация заметна только на низкоскоростном канале связи (или же при сильной потере пакетов на транспорте).
В межблочной комутации приемущество мултикаста именно в отсутствии дублирования трафика при необходимости отдать источник (битрейт*колво потоков) на разное оборудование/провайдеров/систему мониторинга и т.д. Мультикаст просто льется, дальше обо всем заботится коммутатор/маршрутизатор. Настроить это не сложнее прописать канал с транспондера, тут не надо мега знаний. Делается это один раз и забывается, оно просто работает.
Да юникасту тут тоже место есть, но в особых случаях (аритектура как у sky star). Однако свои замечания я уже по этому поводу говорил, считаю ее не оправдано избыточной. А для внешнего подключения коммерческих источников по IP, есть договор и SLA (соглашение о качестве услуг).
-
осталось только найти причину по которой возникнет необходимость
запросить тот самый пакет :)
согласен, что что единственной такой причиной может стать дроп на порту, что у приличного оператора маловеротно.
в предидущем посту, я немного не корректно написал, что буфер не имеет отношения к мультикасту, это не совсем так т.к. мультикаст - это помимо UDP ещё и RTP, а вот особенность RTP - он действительно кешируется, следовательно его применение в рамках ГС более оправданно... как-то была у меня мысль перейти на RTP, но что-то меня удержало...
Следовательно, если нет дропов, то разницы между юникастом и мультикастом (RTP) нет (разумеется кроме многоадресности)?
RTP имхо также мертворожден, как и FEC IP. Приемуществ (кроме возможности согласовать параметры "медиа-сесси") перед Тср у него нет. Фактически RTP конфетная обертка, а потоки все равно льются по UDP.
Если уж смотреть дальше в будущее, то оно за H.265 + HLS. Именно хорошие кодеки (соотв-но меньший обьем данных) и адаптивная (по битрейту) передача до получателя вытолкнет мультикаст. Хотя не исключен, что операторских сетях он будет успешно со-сущетсвовать с мультикастом: мультикаст магистрали, HLS на узлах в направлении пользователя. Вот только до будущего этого еще как до Марса на бензине :)
-
О каких запросах дополнительных пакетов идет речь? Не забывайте, что все потоки, которые мы рассматриваем в данном контексте, это реалтайм и если пакет не доставлен, то он не доставлен и все.
Буфер есть в любом случае и UDP/RTP, multicast/unicast тут не при чем.
А вот MDI, который мы обсуждали несколькими страницами ранее, имеет отношение к буферу. В рамках этой методики есть показатель IAT, который оценивает время доставки транспортных (не MPEG-TS) пакетов. Если пакеты полетят быстрее, чем ожидает приемник, буфер переполнится, медленнее - опустошится. Отсюда вытекает проблема переменного битрейта. Именно переменный битрейт приводит к резким колебаниям времени доставки пакетов. У кого есть VB120/220 могут в этом легко убедиться. Как должны передаваться IP TS описывает стандарт TS 102 034.
Теперь о юникаст/мультикаст. Мое личное мнение. Я использую мультикаст. С ним тупо проще работать на межблочке. Завел стример, а дальше цепляю к нему столько приемников, сколько нужно. И при анализе потока я анализирую именно тот, который уходит в эфир, а не искусственно созданную копию.
Но, мультикаст всегда накладывает требования к коммутаторам и настройке коммутаторов. Я не сисадмин, подробностей рассказать не могу, но очень часто встречаю ситуации, когда на ненастроенном, либо плохо настроенном гигабитном коммутаторе проблемы с потоками начинаются уже при общем битрейте 450-500Mbps. Мультикаст ломится везде, в том числе на тот порт, из которого он исходит. Про снупинг, PIM многие не знают.
Юникаст проще в своей сути. Это соединение точка-точка. Настроил и забыл. Не гибко, не универсально. Зато можно гонять через тупые хабы и не заморачиваться настройкой непонятных функций маршрутизации.
Т.е. здесь выбираем, либо надежность, либо гибкость. Кому что больше нравится.
-
Коллеги, вы уж простите мою дотошность, но давайте разберемся вот в чем:
вы говорите, что не важно юникаст/мультикаст есть буфер, тогда откуда возникают ошибки последовательности? По идеи если данные буферизируются, то и передаваться они должны в строгой последовательности.
Либо весь вопрос в размере буфера, для UDP он меньше, поэтому когда значения IAT первышают буфер возникает ошибка последовательности.
Не забывайте, что все потоки, которые мы рассматриваем в данном контексте, это реалтайм и если пакет не доставлен, то он не доставлен и все.
о перезапросе пакета я рассуждал в том ключе, что это TCP т.е. должно быть подтверждение удачной доставки пакета, если подтверждения нет, то пакет должен перепослаться. Если для TCP DVB это не актуально, тогда какой смысл использования юникаста? Только жесткое ограничение приемников сигнала? Тогда получается верно утверждение:Зато можно гонять через тупые хабы и не заморачиваться настройкой непонятных функций маршрутизации.
-
TCP - транспортный протокол гарантированной доставки данных. Все сегменты (куски данных) он нумерует, и принимающая сторона эту нумерацию проверяет. Получатель проверяет пришел ли сегмент с ожидаемым номером, пришел ли он битый (ошибка контр суммы) или отправитель не получил подтверждения от получателя, во всех этих случаех сегмент отправляется повторно. Медлено, но гарантировано.
Но беда не только в скорости передачи ТСР, беда в его сессионости. ТСР требует установления канала точка-точка для каждого нового получателя, и соответственно пересылает копии одних и тех же данных каждому отдельному получателю.
UDP фиолетово на гарантированность доставки пакетов, он изначально надеется на два фактора: канал идеальный и все ошибки исправит вышестоящий протокол/программа.
И ему впринципе все равно кто получатель, он просто шлет данные на сетевой интерфейс, через протокол сетевого уровня (например IP).
Все что требует UDP чтобы получатель знал с какого UDP-порта эти данные летят, а где они находятся получатель узнает из поля IP-адрес протокола IP.
Мультикаст особый вид/способ передачи трафика сетевым протоколом IP, когда не важен конечный получатель, а важен лишь отправитель и идентификация трафика (IP-адрес группы).
Имено поэтому IP-мультикасту, протокол UDP - роднее, они "говорят на одном языке". На канальном (Ethernet) уровне мультикаст IР-адреса отображаются в диапазон определенных МАС-адресов, таким образом коммутатор знает что это мульткаст, ему фиолетового кто его получатель, он просто шлет (копирует) этот траффик во все свои порты, кроме того откуда он пришел. Копирует - тут ключевое слово, т.е. одни и теже байтики множит по всем портам.
Вот тут то и задача L2/L3 фич коммутаторов/маршрутизаторов наводить порядок, доставля трафик только тем кому он нужен.
Мультикастом можно в принципе и с использованием TCP передавать, хотя сложно представляю себе как это увязать.
Данные UDP конечно тоже складываются в буфер, это прежде всего необходимо чтобы протокол IP успел их из буфера забрать и отдать вышестоящему протоколу UDP, который должен успеть отдать их дальше (например на вход MPEG-TS демультплексора).
В случае засранного ошибками канала, предпочтительнее для потоковых данных (видео, аудио) использовать UDP, который не получив пакет и не отдаст его выше, что просто сквадратит картинку или сжует звук (упрощенно :). А ТСР будет до последнего выеживаться, пытаясь собрать пазл. И ведь все равно рано или поздно вышестоящий протокол во время не получивший очередную порцию данных, просто пропустит ее. Нафига тогда козе баян? если резльтат один и тот же.
Понятно что по инету передавать UDP для целей мультимедия просто жесть, т.к. это не твоя собственная сеть и гарантировать тебе никто и ничего не может. И мультикаст тебе по инету передавать никто не будет, слишком накладно (хотя и спорно). Пожтому там проще передавать юникаст, заране согласившись с тем что пакеты надо будет буферезировать, чтобы из этой каши выделить хоть какой то полезный поток видео/аудио. Ну и соответвенно т.к. это все равно юникаст, то передавть его проще по ТСР, который к тому же возьмет на себя устранение хоть части ошибок среды передачи.
Спасти конечно ситуацию (и спасает) может избыточное кодирование именно потоковых данных - FEC. Правда это сильно увеличивает накладные расходы на передачу потоковых данных (чем избыточнее кодирование, тем толще итоговый поток), но результат на лицо - за счет передачи в потоке избыточных данных, их проще восстановить на другом конце.
Так например делается в DVB-S/S2/T2, т.к. передача потрадиоканалу подвержена куче проблем - это не кабель, и даже не инет.
Сейчас пытаются пропихнуть IP FEC, но имхо сложность реализаци, несовместимость с уже существующим оборудованием без FEC, свидут все его усилия на нет.
-
Подведем итог:
1. В пределах одной ГС (читай одного коммутатора) прелести гарантированной доставки данных по протоколу TCP вряд ли используются.
2. Передавая юникастом суммарный поток 400 Мбит/сек двум получателям мы порождаем 800 Мбит/сек трафик на коммутаторе ГС, трем получателям - 1,2 Гбит/сек, и т. д. Решайте много это или мало, и при скольких получателях станет узким порт источника. Да и кроме порта источника с возрастанием числа получателей возрастает нагрузка и на процессор источника, который выполняет работу по отправке данных.
3. Сложность настройки того или иного способа пока еще спорна:
3.1. С юникастом как будто бы наглядней маршрутизация. То есть ты заранее знаешь куда зарулить поток и никто более его не получит без надобности на то. Настройки коммутаторов, передающих этот самый поток практически не требуется. Отметим, что с юникастом работает меньше железок, чем с мультикастом.
3.2. С мультикастом наоборот минимум настроек источника и получателей, а с настройкой коммутатора надо чуток повнимательнее, дабы не зафлудить непотребным трафиком не нуждающиеся в нем устройства. По аналогии с предыдущим пунктом у мультикаста богаче выбор по оборудованию (на сколько я знаю).
-
2. Передавая юникастом суммарный поток 400 Мбит/сек двум получателям мы порождаем 800 Мбит/сек трафик на коммутаторе ГС, трем получателям - 1,2 Гбит/сек, и т. д. Решайте много это или мало, и при скольких получателях станет узким порт источника. Да и кроме порта источника с возрастанием числа получателей возрастает нагрузка и на процессор источника, который выполняет работу по отправке данных.
Справедливо только в том случае если Вы двух кратно или трех кратно резервируете что то на модуляции к примеру ,
в противном случае эта ситуация не возникнет . Тут надо понимать следующее, что все что ушло юникастом , для кого либо, второй раз туда же не отправляется :) , при этом сразу же все становиться на свои места :)
ДЛя примера , ну приняли Вы канал "спас" Вам надо его сколько раз отправить в QAM ? , у меня один , сколько раз отправить в IP-PAL тоже один ! И магия сейчас в тот же IP -PAL у меня приходит 165 мегабит, При этом там РТРС 1 + РТРС 2 прямиком с DVB-T2, потом там же оцифрованный аналог, там же только то что со спутника валит, степень ввода IP-PAL где то %80, часть каналов еще в ASI , потихоньку догребаю, как видно, страшных запредельных для понимания и созерцания цифр то нету :)
В QAM все еще легше , каналов которые в QAM Могут быть поданы ДВА раза всего 20 !
При чем в моем случае ситуация еще проще, в qAM эти 20 каналов придут тоже один раз,
они дважды или трижды или четырежды придут только в mpeg4--too SDI --mpeg2 и уже от туда полетят в qAM,
и только один раз (ну это когда все устаканиться)
Я думаю список что это за каналы писать не надо .
Отправить в IP TV - каналы что приходит в QAM , труд минимальный :)
Я повторюсь, нет страшных цифр .
3.1. С юникастом как будто бы наглядней маршрутизация. То есть ты заранее знаешь куда зарулить поток и никто более его не получит без надобности на то. Настройки коммутаторов, передающих этот самый поток практически не требуется. Отметим, что с юникастом работает меньше железок, чем с мультикастом.
Я уточню коллега , не КАК БУДТО БЫ , а именно НАГЛЯДНО
Вася отдает булочку Тане, не посредников, нет даже гипотетической возможности что булочка будет не вручена Тане.
На счет оборудования, то оборудование что не работает с юникастом я как раз и не считаю оборудованием,
ибо не полная поддержка сетевого стека, это уже настораживает, что там разработчик решил не поддерживать еще - тайна великая, гармоники, тандберги, циски, сумавижен - поддерживает юникаст в полный рост, для меня это ориентир.
-
sky star, дофантазируем вашу схему чутка:
https://yadi.sk/i/2QU9eq0wp2z8k
холодным зимним утром ген. дир. сообщил: "Свершилось! Мы купили ИП Васю Пупкина. Он там аналог гонял 3 канала, надо людям счастье дать - надо дать IP, QAM и расширить аналог".
и вот у нас появились три региональных ЦГС.
волокно до города А у нас есть.
до городов Б и В можно добраться только через А, и к тому же оптики туда своей и Васеной нет, а есть только по каналу 1 Гбит/с от ТрансКолхозТелеком.
а людям еще и Инет надо раздовать - сразу!, сотовиков подвинуть с рынка.
пропуская всю лирику, следуя логике изначально устаканеной схемы ЦГС, как поступить? использовать "наглядный" юникаст или рациональный мультикаст. Религия или прагматизм?
-
Не ну Вы ребята молодцы , я рад за Вас, но у нас город маленький 300 000 населением, и мне в моих условиях стать вторым ЭР Телекомом не грозит . От этого я отталкиваюсь .
А так я очень рад что кто то растет и развивается, и конечно у него будут не мои "келейные" возможности и само собой штат будет по более,
оборудование будет по лучше , а так у меня не милионик .
И до ближайшей цивилизации больше 100 км
-
Коллега, у меня город тоже не Москва, единое муниципальное образование, население 200-250 тыс., раскиданное по 4 городам, канал в инет спутник 100 Мбит/с, ближайшая точка цивилизации в 2 тыс. км
Расстояния между городами-сателитами благо позволяют аналог+QAM гонять с ЦГС, но IP передается через маршрутизаторы по PIM.
У вас такой прекрасный ""монстрик" DGS-6600, настроить PIM дело не сложное, команды все в мануале есть.
Да у DLink приходиться додумывать очевидные в настройке вещи, с Cisco в этом плане проще,
но сама настройка не сложна, один раз продумать все, настроить и забыть.
Влазить в конфиг надо, только при появлении нового источника или получателя, что не каждый день происходит.
-
300 000 населением
кхм... я уже не первый раз слышу от вас, что город не большой, но железо вы юзаете не дешевое, не по Хуану сомбреро, если вы, конечно, не монополист :)
-
У нас тут одно образование, называется тупик :)
дальше дороги нет в прямом смысле :)
по этому городов сателитов у нас нет,
на счет оптики из нашего тупика тоже засада :)
тут МТСу чет как "день сурка" пару месяцев к ряду рвали оптику ,
так сидели все на спутнике , без инета, без СМС на федеральных номерах,
и не чирикали (ну в смысле чирикали , а чё делать ?)
:) так что , не грозит , обидно для меня конечно, но с другой стороны , чет та достали "дристания" каналов,
письма от ВГТРК с подарками к 1 апреля 2016 года, что может и к лучшему
На счет монополии , так она на ДВ одна --> РТК
хотя и у нас в городе два десятка лет назад , не кто не кому руки не выкручивал, к стенке не ставил,
но делать начали только мы , а сейчас TV только ленивый не предлагает, при чем БЕЗПЛАТНО :)
кругом одна халява .
На счет железа, есть притча , "Мы не так богаты что бы каждый год под любой чих sat оператора покупать новую железку"
когда МТС появился, я даже не сомневался что С545 заработает (и это при чем что мы пересели с 22000 7/8 DVB S), а вот многие побежали по магазинам за новыми PBI ,
(тому есть на этом же форуме много строчек текста)
по этому делать надо с умом и учитывая что назад в DVB S 27500 3/4 mpeg2 уже не кто не вернется .
-
А можно еще вопросик? а мульткаст с "пограничного" EMR в сеть абонентам вы как отдаете? тоже по L2?
-
Если понять что "пограничный" это QAM модулятор,
только с него может вылететь мультикаст в IP TV
то SFP из QAM EMR воткнуты в 3627G ,
а какой он L я даже и не подозреваю,
не мая тема :)
-
... у нас город маленький 300 000 населением
15 тыс. у нас не наберется. Вот это маленький. А 300 тыс. нормальный такой город.