[^rage^]

100k коннектов на 2 гигабита — это 21 килобит. Видео. 21 килобит. sendfile при раздаче по сети.

Максим, вы взяли одну крайнюю цифру и поделили на другую крайнюю цифру.

100k коннектов для видео битрейтом в 2Mbit/s дадут 195Gbit/s трафика и потребуют наличия 20x10GbE или 5 карточек на 40GbE.

При этом, чтобы "уложить" 2x1GbE достаточно 1k зрителей с таким битрейтом.

 

100k получены так: ~ 35k на один гигабитный интерфейс, 35k - на другой. +35k через loopback.

т.е. по всем этим соединениям бегают данные и клиенты их тянут(пусть и медленно для видео).

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

всё это крутится на 1 ядре и упирается в softirq(~50% soft interrupts на 1 ядре) и context switches.

если бы не упиралось в интерфейсы, то переключений контекста было больше, но тут проще поднять net.core.wmem_max(на linux) и выставить SO_SNDBUF больше, чтобы sendfile реже возвращал EAGAIN.

 

т.е. технически - это всё та же раздача файликов по http, просто вместо закрытия сокета мы шлём следующий по списку файл, а в конец списка постоянно добавляем новые файлы.

[maxlapshin]

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

 

С такой скоростью можно либо слушать радио, либо неделю скачивать фильм на 600 мегабайт что бы посмотреть.

 

sendfile вообще очень сомнительное решение для раздачи видео: асинхронно то оно не может с диска читать.

[vitalyb]

sendfile вообще очень сомнительное решение для раздачи видео: асинхронно то оно не может с диска читать.

Если readahead работает правильно и дисковая не перегружена, то оно вообще читать ничего не будет - напрямую из pagecache'а будет слать и всё. Другой вопрос, что этот процесс просто слабо контролируем, а альтернативу реализовать правильно достаточно сложно.

[^rage^]

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

С такой скоростью можно либо слушать радио, либо неделю скачивать фильм на 600 мегабайт что бы посмотреть.

Максим, это стресс-тест. В реальной жизни канал во внешний мир кончится раньше. Для того же nginx медленные пользовали могут организовать DoS.

Что будет с flussonic если к нему придёт 500k пользователей на 3g за mpeg-ts( ,{"/(?.+)/mpegts", {mpegts, [name]}} ):

1. за live-трансляцией

2. за видеоархивом

 

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

 

 

sendfile вообще очень сомнительное решение для раздачи видео: асинхронно то оно не может с диска читать.

асинхронно читать куда? sendfile перемещает данные между файлом и произвольным fd(в некоторых ОС это должен быть сокет).

если же вы о раздаче VOD, то тут вопрос настройки i/o планировщика и выбора подходящей фс. да, и я отказался от HDS и не храню данные в mp4.

 

а тут sendfile() используется как портабельная реализация zero-copy.

более того, с 2.6.33 через sendfile() можно файлы копировать.

 

Если readahead работает правильно и дисковая не перегружена, то оно вообще читать ничего не будет - напрямую из pagecache'а будет слать и всё.

Всё верно. только тут pagecache используется как большой ядерный буфер, а sendfile - как способ быстро и эффективно отдать из него данные.

Цель была простая - написать proxy 1:n, а не комбайн. Изначально я думал о splice/tee, но там больше сисколлов и возни.

файлики лежат в tmpfs(там не больше 2-3 hls-фрагментов, порезанных на куски, а то лаг в 10с уже как-то неприличен).

[maxlapshin]

Если прийдет 100 000 пользователей за mpegts, то эрливидео начнет их отстреливать, потому что они не в состоянии выгребать буферы.

 

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

 

Что касается sendfile, то он бессмысленный для этой задачи, потому что он блокирует поток либо заставляет хаотично переповторять вызов. Соответственно эффективно обслуживать 10 000 клиентов, которым отдается видео с диска, как это делает эрливидео, с помощью sendfile не получится.

[Ivan_83]

Цель была простая - написать proxy 1:n, а не комбайн.

Надо были писать, или у меня купить :)

 

Изначально я думал о splice/tee, но там больше сисколлов и возни. файлики лежат в tmpfs(там не больше 2-3 hls-фрагментов, порезанных на куски, а то лаг в 10с уже как-то неприличен).

Это всё поиски готовых максимально больших кусков головоломки, вместо её сбора обычным способом: общий буфер + send() + kqueue/epoll.

Профит на отдачу вроде как есть, на практике же он не сильно и нужен, ибо "буфер + send() + kqueue/epoll" без особых проблем раздаст с одного ядра современного проца пару гигов минимум.

Пользователи nginx на таких нагрузках в кач прокси/балансера подтвердят.

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

 

Если прийдет 100 000 пользователей за mpegts, то эрливидео начнет их отстреливать, потому что они не в состоянии выгребать буферы.

Как он это определяет?

[vitalyb]

 

Как он это определяет?

send() все время отдает EAGAIN?..

[maxlapshin]

Определить, что клиент не может выгребать HTTP MPEG-TS можно по его отставанию (росту его личного буфера) от риалтайма. Если больше определенного порога — отстреливаем его.

 

send отдавать EAGAIN в evented архитектуре вообще говоря не должен, потому что в сокет пишут только когда он сам сообщает, что готов к записи.

 

Схема с хранением файлов в tmpfs и использование sendfile имеет такую массу проблем, что даже не хочется вникать в них =)

[Ivan_83]

Определить, что клиент не может выгребать HTTP MPEG-TS можно по его отставанию (росту его личного буфера) от риалтайма. Если больше определенного порога — отстреливаем его.

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

 

Схема с хранением файлов в tmpfs и использование sendfile имеет такую массу проблем, что даже не хочется вникать в них =)

Проблем там не много, хотя весьма концептуальные: зависший клиент заблокирует удаление файла - могут весьма всё попортить.

А вот с точки зрения производительности трудно придумать аналоги, если только ZeroCopy сокеты...

[^rage^]

send отдавать EAGAIN в evented архитектуре вообще говоря не должен, потому что в сокет пишут только когда он сам сообщает, что готов к записи.

нет, это не так. в буфере сокета освободилось 4096 байт, вы пытаетесь записать 8192. запишется 4096 и будет EAGAIN.

 

Схема с хранением файлов в tmpfs и использование sendfile имеет такую массу проблем, что даже не хочется вникать в них =)

 

например?

это ж фактически стриминг на уровне ядра. если NIC умеет scatter/gather(а это почти все современные сетевые карточки), то почти вся работа будет выполнена без привлечения cpu.

[maxlapshin]

Непускание новых клиентов — это конечно есть (не забываем, что эрливидео это не только mpegts, а ещё и HDS, HLS, где клиенты меряются гораздо хитрее), но лимит на количество клиентов — это опция настройки.

 

Поставили общий лимит или лимит на стрим и ограничиваем.

 

Однако это не решает вопрос, чего делать с клиентом, который выгребает слегка медленнее чем мы ему откладываем данные. Тут надо либо отключать, либо дропать кадры. С VLC практика показывает, что лучше отключать.

 

 

В случае с evented-системами ядро оповещает, что сокет готов к записи (или чтению). Это означает что он _гарантированно_ не заблокируется на вызове write или read. Соответственно, не обязательно писать в сокет, пока он не станет возвращать EAGAIN, можно добавить его обратно в реактор и опять получить его как готовый к записи.

[vitalyb]

В случае с evented-системами ядро оповещает, что сокет готов к записи (или чтению). Это означает что он _гарантированно_ не заблокируется на вызове write или read. Соответственно, не обязательно писать в сокет, пока он не станет возвращать EAGAIN, можно добавить его обратно в реактор и опять получить его как готовый к записи.

Речь о том, что если клиент не выгребает, то данные где-то накапливаются, в частности, в send буфере сокета, в котором как только освободится 1 байт - придет event, что туда можно уже писать, хотя толку от такого разрешения мало.

[^rage^]

Однако это не решает вопрос, чего делать с клиентом, который выгребает слегка медленнее чем мы ему откладываем данные. Тут надо либо отключать, либо дропать кадры. С VLC практика показывает, что лучше отключать.

тут вопрос размера буфера под клиента.

 

Это означает что он _гарантированно_ не заблокируется на вызове write или read.

только для read. пока у вас нет механизма узнать сколько данных освободилось в буфере сокета избавиться от EAGAIN при write невозможно.

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

 

Соответственно, не обязательно писать в сокет, пока он не станет возвращать EAGAIN, можно добавить его обратно в реактор и опять получить его как готовый к записи.

зачем? если в буфере сокета есть место, вы всегда будете получать его готовым к записи.

[vitalyb]

тут вопрос размера буфера под клиента.

При прямом софте так и было бы, но дело в том, что VLC кривое. При "бесконечном HTTP стриминге" в половине случаев так же понадобится и "бесконечный" буфер. VLC вычитывает данные из сокета не по мере их прихода, а так как хочется ему (а в половине случаев ему будет хотется медленней, чем надо) и в результате имеем, что сначала забивается буфер приема на клиенте, а за ним и буфер передачи на сервере, это не лечится без изменения модели поведения и ошибки в потоке ситуацию резко усугубляют. HLS я не проверял, но если VLC ведет себя так же, то проблема только перемещается из буфера сокета в "всё более поздний номер файла".

[Ivan_83]

Однако это не решает вопрос, чего делать с клиентом, который выгребает слегка медленнее чем мы ему откладываем данные. Тут надо либо отключать, либо дропать кадры. С VLC практика показывает, что лучше отключать.

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

 

 

Речь о том, что если клиент не выгребает, то данные где-то накапливаются, в частности, в send буфере сокета, в котором как только освободится 1 байт - придет event, что туда можно уже писать, хотя толку от такого разрешения мало.

low_watermark есть, устанавливаем в 64к и пока не будет свободно 64к в буфере нас не дёрнут.

 

При прямом софте так и было бы, но дело в том, что VLC кривое. При "бесконечном HTTP стриминге" в половине случаев так же понадобится и "бесконечный" буфер. VLC вычитывает данные из сокета не по мере их прихода, а так как хочется ему (а в половине случаев ему будет хотется медленней, чем надо) и в результате имеем, что сначала забивается буфер приема на клиенте, а за ним и буфер передачи на сервере, это не лечится без изменения модели поведения и ошибки в потоке ситуацию резко усугубляют. HLS я не проверял, но если VLC ведет себя так же, то проблема только перемещается из буфера сокета в "всё более поздний номер файла".

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

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

 

 

нет, это не так. в буфере сокета освободилось 4096 байт, вы пытаетесь записать 8192. запишется 4096 и будет EAGAIN.

Читайте справку.

На блокирующем оно не отпустит пока всё не отправит.

На не блокирующем запишет сколько влезло и вернёт ОК + размер сколько записало.

еген - только если вообще не записало.

 

тут вопрос размера буфера под клиента.

пейсатели влц сделали бы всем большое одолжение, добавив крутилку размера буфера сокета, но они садисты-мазохисты.

 

только для read. пока у вас нет механизма узнать сколько данных освободилось в буфере сокета избавиться от EAGAIN при write невозможно.

1. Фря сообщает (kqueue) сколько можно записать, в линуксах вроде есть дрочилки только для tcp. (Я их не стал юзать чтобы производительность в линуксе ещё больше не упала, так бы ещё два сискола на каждый write эвент добавилось :) )

2. EAGAIN у меня их не возникает :)

 

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

SO_RCVLOWAT, SO_SNDLOWAT.

Правда: /* Linux allways fail on set SO_SNDLOWAT. */. На то он и линукс :)

С другой стороны, там обычно не меньше mtu места освобождается.

Чтобы уменьшить нагрузку на проц, если клиент не сильно отстал, то я его не пихаю в kqueue/epoll - ибо всё равно слать нечего, а после получения очередного куска сразу пробегаю по всем клиентам кто не в kqueue/epoll и рассылаю свежие данные.

[Alex_P89]

Подскажите решение для преобразования HTTP в Milticast.

Из входящего потока от AceStream (P2P вещание) через AceProxy получаем mpegts по HTTP. Надо это вещать в мультикаст.

Проблема в том, что я не могу найти нормального решения для этого. Astra 4 с HTTP input работать не умеет нормально и теряет входящий поток уже через несколько минут, восстанавливается только после перезапуска. VLC держится чуть дольше, но через некоторое время также внезапно затыкается. Лучше всех показывает себя ffmpeg, но и он тоже внезапно может прекратить работать через несколько часов.

Проблема скорее всего в HTTP потоке, в каких-то микро-затыках. По http с AceProxy канал продолжает показывать, а ретрансляция в мультикаст виснет.

[maxlapshin]

В flussonic достаточно неплохо сделана эта фича.

 

Поток выравнивается по таймстемпам (не по битрейту) и шлется по 7 пакетов в сеть.

[Alex_P89]

В flussonic достаточно неплохо сделана эта фича.

 

Поток выравнивается по таймстемпам (не по битрейту) и шлется по 7 пакетов в сеть.

Платный софт для этой задачи не рассматриваю, оно того не стоит.

[^rage^]

В flussonic достаточно неплохо сделана эта фича.

вот только плохо ему становится, когда рядом появляется кто-то cpu-bound :)

[maxlapshin]

UDP вообще штука такая — капризная до доступности ресурсов.

[radist2013]

Суть проблемы:

У нас в области есть база отдыха, на которой недавно был развернут сервис цифрового TV вещания (от Ростелекома). Провайдер "гонит" поток на 200 каналов, из которых мы берем только интересующих нас 30 (все групповые ip адреса у нас есть). На границе сети с провайдером стоит их управляемый коммутатор huawei, один порт которого они настроили под это самое цифровое телевидение, другой - для канала обычного интернет (делят они vlan-ами или еще как мы не знаем).

 

Схематично топологию сети нарисовал в mspaint (см. вложение).

 

Далее в сети установлен управляемый коммутатор от d-link (но включен и работает как "тупой"), который с одной стороны подключен к huawei коммутатору, а с другой - к цифровой платформе sumavision EMR 3.0 (кратко о ней здесь http://www.sumavision.tv/products/EMR_3_0/), которая раздает поток уже непосредственно клиентам в номера и домики по коаксиалу. Из настроек на ней - изменен только ip адрес (для удаленного доступа) и прописаны все групповые ip адреса каналов вещания.

Изначально коммутатора d-link и вовсе не было за ненадобностью, sumavision emr 3.0 непосредственно подключался к huawei.

 

Сейчас возникла необходимость добавить к обычным каналам вещания телевидения собственные промо ролики (реклама в рамках турбазы), для чего был поднят сервер на базе ОС UBuntu и ПО VLC, куда и были загружены эти ролики (4 шт.).

 

При одновременной работе обычного TV и сервера с роликами картинка с любым каналом или роликом на стороне клиента начинает сразу разваливаться, в то время как поочередное включение телевидения от провайдера или нашего собственного сервера к такой проблеме не приводит и все работает как надо

[Ivan_83]

Хватит как кролик писать во все топики одно и тоже.

Я вам уже где то написал: включите игмп снупинг на коммутаторе, и фильтред анрегистред групс.

[olafff]

Люди добрые!

 

Где скачать этот гребанный Relaying?

По этой ссыле http://deineka.net/2010/12/06/relaying-multicast-v-http-i-obratno/ только бла-бла, а линк то на скачку где?

Кто может расшарить или дать ссылочку на скачивание?

[maxim1]

Люди добрые!

 

Где скачать этот гребанный Relaying?

По этой ссыле http://deineka.net/2010/12/06/relaying-multicast-v-http-i-obratno/ только бла-бла, а линк то на скачку где?

Кто может расшарить или дать ссылочку на скачивание?

смотри в л.с.

[olafff]

А линуксовая версия есть?