Перейти к содержимому
Калькуляторы

Наладили вещание по http, на приставке отлично показывает, на компе с vlc "зеленит" и тупит со страшной силой, никто не сталкивался?..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наладили вещание по http, на приставке отлично показывает, на компе с vlc "зеленит" и тупит со страшной силой, никто не сталкивался?..

Приставка и VLC комп в разных сегментах сети?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а причем тут разные сегменты ?? это ж тцп обычный ))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а причем тут разные сегменты ?? это ж тцп обычный ))

При том, что проблема может в маршрутизации, или в l2, если, конечно, тестирование было в разных сегментах. Если в одном - то проблема в источнике вещания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наладили вещание по http, на приставке отлично показывает, на компе с vlc "зеленит" и тупит со страшной силой, никто не сталкивался?..

Приставка и VLC комп в разных сегментах сети?

В одном

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tcp.cc=htcp

sack=1

ecn=1

делали в sysctl?

У нас Линукс. Там sack и ecn по умолчанию=1 и =2. А congestion=cubic.

Установка в приведенные значения ничего не дала.

Увеличение буфера на vlc тоже ниего не дает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наладили вещание по http, на приставке отлично показывает, на компе с vlc "зеленит" и тупит со страшной силой, никто не сталкивался?..

Приставка и VLC комп в разных сегментах сети?

В одном

mpeg2 или 4 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увеличение буфера на vlc тоже ниего не дает.

влц на линуксе или венде?

Что показывает влц в сообщениях с включённым дебагом?

 

Ещё вариант попробовать на другом тазике влц, вдруг дело в дровах/железе тазика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

интересно сколько максимально сессий сможет отстримить астра по http .... кто-то пробовал в бою ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

интересно сколько максимально сессий сможет отстримить астра по http .... кто-то пробовал в бою ?

До 1000 точно без проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На 2 х Intel® Xeon® CPU E5-2630 0 @ 2.30GHz с 10г картами, убунта 12 лтс, тюнингованный:

 

- астра до 1500 (в режиме xudpxy), дальше полка по процу она пока однопоточная.

 

- моей софтиной один канал (одним потоком обрабатывается, чтобы сравнить) 2400 без проблем, 2500 уже сыпется картинка. (3000 - уже полка интерфейса)

Summary

Stream hub count: 2

Sources count: 2

PIDs count: 11

Clients count: 2401

Clients count with POLL state: 1

Rate in: 5 mbps

Rate out: 7219 mbps

Total rate: 7224 mbps

 

 

Res usage

CPU usage system: 52,71%

CPU usage user: 9,22%

CPU usage total: 61,93%

Max resident set size: 71 mb

Integral shared text memory size: 0

Integral unshared data size: 0

Integral unshared stack size: 0

Page reclaims: 51053

Page faults: 0

Swaps: 0

Block input operations: 0

Block output operations: 0

IPC messages sent: 0

IPC messages received: 0

Signals received: 0

Voluntary context switches: 507187

Involuntary context switches: 23102

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

интересно сколько максимально сессий сможет отстримить астра по http .... кто-то пробовал в бою ?

До 1000 точно без проблем.

так это просто прелестно!

спасибо!

 

На 2 х Intel® Xeon® CPU E5-2630 0 @ 2.30GHz с 10г картами, убунта 12 лтс, тюнингованный:

 

- астра до 1500 (в режиме xudpxy), дальше полка по процу она пока однопоточная.

 

- моей софтиной один канал (одним потоком обрабатывается, чтобы сравнить) 2400 без проблем, 2500 уже сыпется картинка. (3000 - уже полка интерфейса)

 

сори за офтоп

да, вы раньше рассказывали о вашем софте

Если уже зашла речь о нем, то в описании, которые вы на форуме давали раньше, (может есть где почитать описание на данный момент? ), я не нашёл есть ли какой-то механизм ограничения доступа? т.е. одним даем этот список каналов, другим другой, этот не заплатил - не даем... и тд,

 

ну и вообще как кто борется с ограничением доступа в тв по http?

 

ну и вопрос вообще уже не в тему - а кто-то пробовал вещать nginx + nginx_rtmp ? там как вроде тоже HLS есть, кроме того есть возможность на лету всякие проверки делать (on_publish, on_play и тд ) ну и вдобавок есть механизмы push и pull для возможности работы с CDN или создания своей системы балансировки

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При стриминге по http проверка авторизации примерно такая же как и при вещании по rtmp: один раз на соединении проверили token, ip, имя стрима и всё хорошо.

 

Тот же эрливидео имеет унифицированный API для авторизации ts http и прочего, причем с регулярной перепроверкой (что бы не было стримов, висящих месяцами).

 

С HLS всё по-другому: там надо поддерживать HTTP сессии. nginx-rtmp это не умеет и ещё очень долго не будет уметь. Эрливидео, конечно, умеет.

 

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

В эрливидео используется другая схема названий для чанков, которая выдает стабильно неповторяющиеся имена.

 

Ну и не забываем, что только эрливидео и вовза — это раздача из памяти. nginx-rtmp, crtmpserver и т.п. — это раздача с _диска_. В итоге эрливидео у кастомеров по 15 000 пользователей обслуживает с лайва.

 

Ещё вопрос про архив. Чего будете делать, когда захочется давать смотреть записанные передачи? =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а в чем проблема у nginx-rtmp чанки складывать в память ?? работает прелестно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не знаю, в чём проблема у nginx-rtmp с работой в памяти, возможно это очень сложно на C управлять данными в памяти, но nginx-rtmp задрачивает диск:

 

https://github.com/arut/nginx-rtmp-module/blob/master/hls/ngx_rtmp_hls_module.c#L481

 

Может это поменяют, но работает это не прелестно. Либо впустую расходуется ресурс диска, либо нужна возня с tmpfs. У rtmpd такая же проблема.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если уже зашла речь о нем, то в описании, которые вы на форуме давали раньше, (может есть где почитать описание на данный момент? ), я не нашёл есть ли какой-то механизм ограничения доступа?

Будет RAIDUS, пока ничего нет.

 

Я не знаю, в чём проблема у nginx-rtmp с работой в памяти, возможно это очень сложно на C управлять данными в памяти, но nginx-rtmp задрачивает диск: https://github.com/a...s_module.c#L481 Может это поменяют, но работает это не прелестно. Либо впустую расходуется ресурс диска, либо нужна возня с tmpfs. У rtmpd такая же проблема.

Нет никаких проблем с памятью в С, на это намекают все работающие операционки :)

md / tmpfs штатное средство, потому его и не стали пихать в тот модуль.

Проще заюзать их и получить zero_copy благодаря senfile() вообще ничего не делая, чем возится и с диском и с памятью по отдельности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К сожалению, sendfile — это наколеночное решение для 100-200 онлайн пользователей.

 

Дело в том, что в юниксе sendfile блокирует целый тред под себя, что крайне расточительно, если мы говорим про больше чем гигабит.

 

Нужен нормальный event loop с управлением памятью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это смотря как его вызывать.

Для sendfile() управление памятью (такое страшное и ужасное) не нужно вовсе, там управление оффсетом из файла.

Линуксовому варианту sendfile() даже указатель на память с данными для отправки передать некуда :)

 

Применительно к nginx - там уже все это сделано, только в конфиге прописать нюансы использования.

 

PS: в 10 фре sendfile() умеет zero_copy и кто юзает для проксирования/раздачи из памяти может неожиданно заметить падение нагрузки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

sendfile понятно что zerocopy. Проблема в том, что это блокирующий вызов и пока он не вернется, весь тред будет заблокирован.

 

Заводить под каждого пользователя тред — это означает ограничить себя тысячей пользователей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

sendfile умеет O_NONBLOCK на дескрипторах, только модель приложения надо перестроить на async io

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и не забываем, что только эрливидео и вовза — это раздача из памяти. nginx-rtmp, crtmpserver и т.п. — это раздача с _диска_.

Ещё вопрос про архив. Чего будете делать, когда захочется давать смотреть записанные передачи? =)

Максим, архив - эта та же раздача с диска и проблемы там как раз описываемые вами.

Если же речь про лайв и все клиенты смотрят, допустим, тнт - первое же обращение к сегменту приведет к тому что он осядет в vfs cache. А если так страшно заблокироваться, можно через POSIX_FADV_WILLNEED делать префетч.

 

К сожалению, sendfile — это наколеночное решение для 100-200 онлайн пользователей.

 

sendfile - это единственно верное решение и относительно портабельный вариант zero-copy.

 

Дело в том, что в юниксе sendfile блокирует целый тред под себя, что крайне расточительно, если мы говорим про больше чем гигабит.

O_NONBLOCK, же. 5-6Гбит/с с одного ядра, написано на python.

 

Нужен нормальный event loop с управлением памятью.

event loop - да. и sendfile в блокирующем режиме никто не использует.

 

sendfile умеет O_NONBLOCK на дескрипторах, только модель приложения надо перестроить на async io

вы путаете асинхронный и неблокирующий ввод/вывод.

кроме того, O_NONBLOCK вам ничем не помогут на обычных файлах и ваш процесс легко может уйти в D-state.

чтобы такого не было, надо данные раздавать либо из tmpfs, либо через fincore узнавать наличие региона файла в vfs cache и если его нет, то через posix_fadvise просить ядро закешировать.

Изменено пользователем ^rage^

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Архив — да, запись и чтение с диска. Причём тут решения есть разные, например при рестриминге для мигрантов в штатах часто используется режим таймшифта, когда поток считывается с диска один раз и дальше уже раздается из памяти.

 

 

Вы говорите про 5 гбит/с с одного ядра. В каких условиях? Локальная сеть?

 

Плюс у меня всё таки есть серьезные вопросы насчёт того, как же sendfile может разблокироваться если нет данных в vfs cache. Вы про какую ОС говорите?

Изменено пользователем maxlapshin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вы путаете асинхронный и неблокирующий ввод/вывод.

модель поведения loop, при не блокирующих выводах - называется async io

 

про sendfile хорошо обьясняли и дискутировали, пришли к заключениям в меил листах nginx, на линуксах он не заработает, только freebsd и только с ее AIO

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А, ну вот, прояснилось.

 

Да, во freebsd aio есть, в линуксе всё очень и очень сыро.

 

В эрланге с его полной внутренней неблокируемостью выбрана модель с пулом тредов. Я долго экспериментировал, остановился примерно на 160 тредах которые отводятся под блокирующие синхронные запросы к диску.

 

Оставшиеся 8 тредов (по количеству ядер) заняты тем временем чем-то более полезным.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.