Vetal13

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

оесть будет человек глазами мониторить? Проще смотреть самодельной прогой на пакеты, на наличие сс-errors, scrambled, и на скорость потока, чего хватит для опеделения большинства проблем автоматом: сломался канал совсем, Scrambled - заглючил CAM, нет совсем пакетов- сломали руками, сс-errors - ухудшение погоды, Не влазит в линк ... При наличии проблем, репортим админу, а тот конкретно смотрит, что с конкретным каналом

Если не охота искать pid PCR нада писать 8192 Строим aux ingests -p 8192 kino.ts Вещаем в сеть multicat -uU kino.ts -t 7 239.3.1.14:1234@ Или зацикленно while true; do multicat -uU kino.ts -t 7 239.3.1.14:1234@; done

В родной версии ограничение на 16 соединений, сразу сделали замену в udpxy-1.0-Chipmunk-16/uopt.h static const int MAX_CLIENT_COUNT = 512; static const ssize_t MAX_MCACHE_LEN = 2048 * 1024 * 10; За год зависал всего раза 3, по вечерам больше 100 постоянных коннектов 8.1-STABLE FreeBSD amd64 в sysctl.conf net.inet.icmp.icmplim=4000 kern.coredump=0 kern.maxfiles=1000000 kern.ipc.nmbclusters=1256000 kern.ipc.maxsockbuf=16384000 net.inet.udp.recvspace=4096000 net.inet.tcp.sendspace=1648576

общаемся с разработчиком - с Павлом Черенковым - та версия которая крутится у меня уже исправлена от ряда проблем - это его слова Спасибо, буду знать Мы udpxy ( версия из портов) для себя немного модифицировали, путем увеличения буферов, поменяли вывод имени в процессах, прикрутил управление доступом. В максимуме пока было 250 коннектов на 1.2Гбит/сек трафика (Бой Кличка с Хейем :-) ) Проблем тоже нет.

Откуда информация на сколько расчитан udpxy ?

Чегото тут не то с "построена очень грамотно", зачем по сети ганять весь малтикаст?, PIM-SM + MVR - и на доступ едет малтикаст в одном экземляре только тех каналов, которые смотрят

Вау, идея классная, но как она реализована, я что-то не представляю. Раздающий сервер никак не может отправить несколько потоков на клиента - он не оперирует адресами клиента, а тупо отправляет поток на мультикастный адрес. К клиенту его направляет коммутатор/маршрутизатор, на которых перехватывается и отсылается клиентский запрос на вступление в группу. Таким образом, для направления к клиенту нескольких потоков, необходимо каким-то образом формировать при поступлении IGMP-запроса ещё несколько IGMP-запросов на "соседние" группы. Хм. Если только действительно, заточить под это STB'шку... И чего тут "вау"?, а если сабскрайбер не последовательно по каналам бегает, то толку от еще 2-х соседних каналов - никакого Реализация: stb - просит 3 канала, показывет - один

127.0.0.1 - это не малтикастовая группа :-)

С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа ) На предидущей версии дров igb (из FreeBSD 8.0) в моем случае нет практически никакой разницы в производительности с родными em, в одинаковых тазиках жуют одинаково трафика 800/400 вход/выход NAT, Netflow, Шейпинг

С igb не все так плохо, а становится еще лучше ... пример 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Aug 10 16:36:02 EEST 2010 igb0: <Intel® PRO/1000 Network Connection version - 1.9.6> port 0xe880-0xe89f mem 0xfbe60000-0xfbe7ffff, 0xfbe40000-0xfbe5ffff,0xfbe98000-0xfbe9bfff irq 16 at device 0.0 on pci10 igb0: Using MSIX interrupts with 10 vectors igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: [iTHREAD] igb0: Ethernet address: 00:30:48:f2:78:7e igb1: <Intel® PRO/1000 Network Connection version - 1.9.6> port 0xec00-0xec1f mem 0xfbee0000-0xfbefffff, 0xfbec0000-0xfbedffff,0xfbe9c000-0xfbe9ffff irq 17 at device 0.1 on pci10 igb1: Using MSIX interrupts with 10 vectors igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: [iTHREAD] igb1: Ethernet address: 00:30:48:f2:78:7f

В начале весны было желание купить, притащили его на тест, тест он не прошел. Смотрели в сторону замены нескольких ma5200g-2 на один большой. Функционал ma5200g-2 перенести на ME60 не удалось, но это даже хорошо :-) Сейчас 2 сервера 1U по 900$ заменяют один ma5200g-2, и железная BRAS-ология нервно курит в сторонке VAS + DAA с NAT-ом одновременно не работают, На vpn-instance-ы хуавей решил забить в этом BRAS-е совсем и у постепенно убирает из прошивок. Нет не MTT - но с дизайном MTT знаком - там все гораздо проще:) Судя по наличию украинских букв, 500 абонентов и 93-й хуавей - это Киев, и с большой долей вероятности это SumTEL :-)

Что именно не справляется? На сколько я помню у 93-х 16к ARP-ов на шасси соответственно на 64к юзеров может двух свитчей и не хватать

исходящий трафик увеличится. плюс - не нужен нат, экономия оборудования. При цене NAT-а 800$ за 2.5Гбит/с суммарного трафика - ну просто супер экономия получается

multicat от vlc, просто складывает ts на диск, умеет малтикаст udp/rtp Мало ресурсов ест, очень компактная по коду