Sonne

Все равно нельзя преодолеть ограничение канала. К этой величине любой нормальный тест будет стремиться. У провайдеров есть нужда знать реальную производительность канала, например, для контроля того что в сети нормально. Для этого нужен эталонный элемент на своем сервере. Задача никогда не устаревает, чего не скажешь об инструментах, которые жиреют и дряхлеют. Кстати, вот на сладкое. Бонусом думаю прикрутить к демону поддержку Микротикова btest: https://github.com/samm-git/btest-opensource

Забавно , тестировал speedtest на гигабите, показал 900+ мбит в тесте, тестировал в flash. Кстати а вы уже видели html5 speedtest ? Speedtest на флеше и у него не было проблемы гигабита. Html5 версию они громко объявили и тихо свернули. Видимо столкнулись с непреодалимыми техническими проблемами. Мерить можешь хоть от нуля, но сверху у тебя лимит мегабит в 500 в лучшем случае. А касательно скорости - дай определение что считать скоростью передачи в сети. Интересный вопрос. Давай так - будем считать скорость передачи tcp потока на системе оттюненой на максимальную производительность. Я выступаю именно за TCP в силу его приближенности к живому трафику.

Там библиотека упирается в возможности бразуеров. Вроде как сошлись на том, что браузеры не могут вытянуть скорости близкие к гигабиту. Кстати, если кто знает какие нибудь другие попытки написать html5 тест - накидайте линков.

По всем гайдам для запуска ffmpeg из nginx используется команда exec ffmpeg Сколько я не пробовал - так и не смог запустить. Однако, как только я сделал команду exec_static ffmpeg Все чудесным образом заработало.

Коллеги, если написать заново свою версию speedtest mini на базе html5, то какие хотелки требуются? То что у меня есть. 1. Максимально точное измерение скорости в максимально широком диапазоне. От 1 Мбита до 10 Гбит. 2. Коректная работа со скоростями 1 ... 10 гбит. 3. Возможность быть встроенным как виджет на сайт. 4. Современный дизайн на базе html5. Нужен ли лог тестов? Подразумевает необходимость настройки приложения и реализации протокола обмена между клиентом и сервером. Что еще?

Про wesrwood есть например здесь: http://androidmodguide.blogspot.com/p/tcp-algorithms.html Особенно актуально для меня то, что тестовый клиент - Андроид. Потому что у нас приставки на Андроиде. Использование ffmpeg + nginx вместе с тюнингом стека дало очень хорошие результаты - мы реально добились стабильной и качественной картинки! Однако там есть свои грабли. У меня не получилось пока даже тупо запустить ffmpeg из nginx. Делаю по гайдам, которые написаны как под копирку. Вижу как nginx запускает процессы, а видео не идет. При запуске в шелле - все ОК.

Я на свой вопрос отвечу. Очень не люблю, когда другие так не поступают. Когда на ресивере с DVB картами Астра раздавала поток udp/мультикаст, нагрузка на процессор была в несколько раз выше по сравнению с http mpeg-ts. Сейчас на дешевенькой MOI Pro c ARM процессором при трафике 30 Мбит, загрузка CPU составляет 10%, из которых 5% на Астру и 5% на систему. Честно говоря порадовался, что на коробочке Гигабитный порт эзернет :) Для раздачи udp/multicast был запущен штатный dvblast. После его замены на астру и переход на http/mpeg-ts качество картинки визуально выросло. На данный момент Астра стоит и делает то, для чего была предназначено изначально - принимает DVB сигналы и раздает их по http mpeg-ts. Вопрос о стримминге HLS пока остается открытым. На тесте три сервера: astra 5.63-test, nimble strimer, ffmpeg + nginx Пока что первые два кандидата просто обосрались перед третьим вариантом :) Если говорить про мультикаст, то для Астры его использовать не нужно. Если мы принимаем 20-30 потоков, то отдать их даже дважды на 2 сервера не составит труда даже для такой слабой железки как MOI PRO. Судя по всему тренд индустрии - полные переход на HTTP.

Потому что ты в сетях не разбираешься :) Нужно же тюнить систему а не просто так чего то поставил и дальше оно само. Начни хотя бы с замены cubic на htcp или hybla, отключению delayask, включению sack и увеличению буферов сокетов. Да вот ладно прямо так сурово. Sack - включен, за подсказку по замене алгоритма tcp - спасибо. После изучения различных алгоритмов решил включить westwood. Буфера и тюнинг OS будем делать под нагрузкой.

Мы решили сделать так. В бесплатном пакете даем Free to Air каналы, закодированные в SD качестве. Архива нет. EPG нужно обязательно! Задача состоит в том, что бы клиент купил коробочку с "бесплатным" телевидением. Много ресурсов на вещание не требуется. Можно собрать все из бесплатных или дешевых программ и приборов. Потом на коробочке уже есть возможность включить платные тарифы, где есть интересные каналы, HD качество и тематические пакеты. Платный пакет мы берем у профессионального поставщика по модели разделения доходов. Обязательно при отключении интернета - выключать телевидение. В наших условиях это основная причина внедрения ТВ. Телевизор люди смотрят постоянно, а без интернета, увы, могут прожить. Для этого нужно сформировать в биллинге пакет, где деньги в первую очередь списываются за Интернет, а потом уже за ТВ. Оставлять возможность использования ТВ при отключенном интернете - чистая благотворительность, особенно если есть беплатный ТВ пакет.

Не надо его шейпить! Если использовать юникаст и MPEG-TS или RTMP у вас будет идти равномерный поток 2-3 мбита для SD канала и 4-8 Мбита для HD канала. Если использовать HLS, то раз в 10 секунд у вас будет подгружаться чанки на максимальной скорости, в остальное время - пусто. Если вы, скажем поставиьте ограничение, допустим до 3 Мбит, то чанки у вас обрежутся вместо пика, будет поток как в обычном стримминге. Только поток этот будет построен на дропах TCP пакетов. Итого - поточные протоколы шейпить бессмысленно, ибо они идут непрерывно с постоянным битрейтом. HLS/DASH протоколы шейпить вредно, ибо это лишь увеличивает нагрузку на сеть из-за переповторов и дропов. Рулить нагрузкой надо выбором кодеков и битрейта на стороне сервера.

Очень, очень странный вопрос! Основная проблема при подаче IPTV - обеспечить качество передачи, уменьшить потери пакетов. А вы спрашиваете, как испортить услугу. Поверьте, для того чтобы она испортилась - делать ничего не нужно, она сама будет ловить проблемы.

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

Кстати, замороче с VLAN больше нет начиная с версии софта 1.8 UBNT наконец добавили возможность поменять Native VLAN.

В силу того что пока не удается добиться приемлемого качества и стабильной работы продолжаем эксперименты. 1. HLS на астре 5.63 работает плохо, изображение дергается, скачет темп и теряется синхронизация. Вобще непригодно. HTTP/Mpeg-http работает ровно 2. Убрали dvblast, поставили астру на ресивер. Визуально без объяснений качество отдельно Астры выглядит лучше, чем Dvblast + Astra. К сожалению, для ресивера MOI не выпущена версия с поддержкой HLS, так что опять гоняем HTTP. 3. Лишний раз убедились, что для радиосети - HTTP категорически не подходит. Нужен только HLS! И одна нерешенная проблема - все потоки хоть в связке Dvblast+Astra, хоть Astra standalone идут упорно в формате 4:3, хотя вес контент естественно 16:9. На VLC отображается все корректно, на наших кривых китайских приставках - сплюстнуто. Кто знает, может быть, возможно ли эту проблему решить на Астре?

Глупости. Основная мысль статьи - планшеты настолько хороши, что нет смысла менять на новые. с компами ситуация такая же, произошла, только 10 лет назад. У меня комп 2008 года, прекрасно работает. Если он сломается, то я просто не куплю больше такой минитауэр. Он дома как медиацентр сейчас используется. Работаем на ноутбуках, форумы читаем на планшетах. А телефон - для мессенджеров, ну ещи и звоним в него иногда :) Есть места для всех форматов, кроме десктопа :) Но не выкидывать же рабочее?

О добро пожаловать в мир DevOps! Гуглите по этому слову, читайте, смотрите что рекомендуют.

Вот посмотрите тут: https://tools.netsa.cert.org/silk/docs.html Я не встретил ни одной статьи с описанием этого чуда.

Вы разницу между netflow9 и netflow5 знаете? Второй вопрос какую задачу пытаетесь решить? Pmacct понимает Nf9, это один из редких продуктов корректно это делающий. Но он экспортирует в несколько вариантов текстовых логов.

Нет никаих проблем BGP и загрузкой одного ядра 100% год как уже! С вирсии около 6.14 все нормально работает! Говорю постоянно всяким идиотам - ставьте на бордер отдельную железку ВСЕГДА! Нет денег на Cisco ASR или Juniper MX80, так хоть купите железку CCR1009 за 500 баксов. Просто Микротик - реально дешевое железо, во всяких навороченных конфигурациях его мало кто использует. Критерии разработчика - побыстрее и подешевле. Когда на него пытаются навернуть навороты, начинаются проблемы. На эти проблемы - всем насрать.

Туда не ходи! Сюда ходи: https://telegram.me/MikrotikRu

Можно вопросы по возможностям? Протокол трансляции только MPEG-TS over HTTP? Планируется ли поддержка HLS? Авторизация абонентов есть? Увидел, что упомянут Radius, это как то связано? Очень хотелось бы найти стриммер, который работает по радиусу. Что то типа приходит запрос от клиента, сервер дергает Радиус и разрешает доступ. В случае реджекта, клиенту крутится записанный рекламный ролик. Я, случаем, не хочу чего то странного?

Какие еще контроллеры баз? Я не понимаю! Единственный критичный элемент этой системы - поставить реле с нормально замкнутыми контактами, тогда если платка сойдет с ума и отключится - питание не прервется.

Смысл использовать мультикаст в вашей схеме, я так понимаю основные его преимущества тут не нужны, можете http гонять. Речь скорее не про преимущества, а про надежность и удобство. Есть ли отличия в качестве приема в случае мультикаст/юникаст и http/udp? Например, dvblast умеет только по мультикасту но позволяет выбрать rtp/udp. Он бесплатный и совершенно не грузит систему.

Увы, для раздачи нужен только HLS, там уже коммерческие потоки HLS из интернета, нужно подмешать бесплатные FTA каналы в виде готовых HLS ссылок. С ресивера на стриминг сервер каким протоколом лучше потоки отадвать при условии, что соединение прямым VLAN по Ethernet ? UDP/TCP, RTMP? Мультикаст включить или выключить?

Мы поставили TBS MOI Pro принимаем два DVB-S и два DVB-T потока. Железка стоит под крышей, рядом с антеннами в небольшом ящике. Изначально планировали ставить ее только на прием потоков. Дальше уже поставим стримминг сервер. На ресивере курутится dvblast. Кандидаты на стримминг обычные: 1. Nginx 2. Wowza 3. Flussonic И вот, внезапно, увидили что во-первых, Астра хорошо работает и как ресивер на MOI Pro, а так же в новой версии пилят HLS. Почему бы не попробовать этот продукт, учитывая что мы запускаем свою станцию с нуля? Кстати, кто использует бесплатные версии Астры - как она справляется с задачей принять DVB поток и отправить его на стримминг сервер?