Обработка UDP MPEG-TS
Max Lapshin
мегабита шлют MPEG-TS пакеты по UDP.
Надо превратить это в HTTP на одного клиента.
Мегабит — это порядка 125 килобайт в секунду. Пакет MPEG-TS — ровно
188 байт. Это порядка 700 пакетов в секунду.
50 потоков — 35000 пакетов в секунду.
Дальше симптомы такие:
если UDP включать в режиме {active,once}, то через небольшое время
данные начинают теряться.
Если включать в режиме {active,true}, то очень скоро (сейчас уточняю
конкретные цифры) начинает линейно расти потребление памяти. Скорее
всего просто забивается очередь сообщений.
Надо отметить, что 50 HTTP MPEG-TS потоков erlyvideo переживает без проблем.
На основании этих данных я сделал вывод, что erlang просто не успевает
шедулить столько пакетов. Беда в том, что на каждый MPEG-TS пакет
приходит отдельное сообщение. Думаю, что если бы ядро или кто-то ещё
сам бы группировал данные, было бы сильно проще.
Пока остается очень неприятный вариант: писать свой драйвер, который
будет открывать сокет, подписываться на него, аккумулировать данные и
слать дальше.
Вопросы такие:
1) убедительно ли звучат мои предположения о том, что беда в количестве пакетов?
2) можно ли заставить слать мне сообщения, склеенные в пачки, а не
кусочками по 188 байт?
3) есть ли шанс обойтись без собственного драйвера?
Дмитрий Омелечко
у меня вот на таком адекватно началась работа с UDP
## common
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 65536
net.core.rmem_default = 65536
## tune TCP
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
## tune UDP
net.ipv4.udp_mem = 8388608 8388608 8388608
net.ipv4.udp_rmem_min = 1024000
net.ipv4.udp_wmem_min = 1024000
3 декабря 2010 г. 0:00 пользователь Max Lapshin <max.l...@gmail.com> написал:
> Исходные данные: есть около 50 потоков, которые на скорости около
> мегабита шлют MPEG-TS пакеты по UDP.
> Надо превратить это в HTTP на одного клиента.
>
> Мегабит -- это порядка 125 килобайт в секунду. Пакет MPEG-TS -- ровно
> 188 байт. Это порядка 700 пакетов в секунду.
> 50 потоков -- 35000 пакетов в секунду.
>
> Дальше симптомы такие:
> если UDP включать в режиме {active,once}, то через небольшое время
> данные начинают теряться.
> Если включать в режиме {active,true}, то очень скоро (сейчас уточняю
> конкретные цифры) начинает линейно расти потребление памяти. Скорее
> всего просто забивается очередь сообщений.
>
> Надо отметить, что 50 HTTP MPEG-TS потоков erlyvideo переживает без проблем.
>
> На основании этих данных я сделал вывод, что erlang просто не успевает
> шедулить столько пакетов. Беда в том, что на каждый MPEG-TS пакет
> приходит отдельное сообщение. Думаю, что если бы ядро или кто-то ещё
> сам бы группировал данные, было бы сильно проще.
>
> Пока остается очень неприятный вариант: писать свой драйвер, который
> будет открывать сокет, подписываться на него, аккумулировать данные и
> слать дальше.
>
>
> Вопросы такие:
> 1) убедительно ли звучат мои предположения о том, что беда в количестве пакетов?
> 2) можно ли заставить слать мне сообщения, склеенные в пачки, а не
> кусочками по 188 байт?
> 3) есть ли шанс обойтись без собственного драйвера?
>
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Jabber-конференция: erl...@conference.jabber.ru
> Новости: http://erlanger.ru
> Написать письмо: erlang-...@googlegroups.com
> Отписаться: erlang-russia...@googlegroups.com
>
Max Lapshin
пакеты невозможно: он такой by design пакетный.
Andrey Nikolaev
pps. Есть возможность замерить сеть с помощью netperf?
2010/12/3 Max Lapshin <max.l...@gmail.com>:
> Исходные данные: есть около 50 потоков, которые на скорости около
> мегабита шлют MPEG-TS пакеты по UDP.
> Надо превратить это в HTTP на одного клиента.
>
> Мегабит -- это порядка 125 килобайт в секунду. Пакет MPEG-TS -- ровно
> 188 байт. Это порядка 700 пакетов в секунду.
> 50 потоков -- 35000 пакетов в секунду.
>
> Дальше симптомы такие:
> если UDP включать в режиме {active,once}, то через небольшое время
> данные начинают теряться.
> Если включать в режиме {active,true}, то очень скоро (сейчас уточняю
> конкретные цифры) начинает линейно расти потребление памяти. Скорее
> всего просто забивается очередь сообщений.
>
> Надо отметить, что 50 HTTP MPEG-TS потоков erlyvideo переживает без проблем.
>
> На основании этих данных я сделал вывод, что erlang просто не успевает
> шедулить столько пакетов. Беда в том, что на каждый MPEG-TS пакет
> приходит отдельное сообщение. Думаю, что если бы ядро или кто-то ещё
> сам бы группировал данные, было бы сильно проще.
>
> Пока остается очень неприятный вариант: писать свой драйвер, который
> будет открывать сокет, подписываться на него, аккумулировать данные и
> слать дальше.
>
>
> Вопросы такие:
> 1) убедительно ли звучат мои предположения о том, что беда в количестве пакетов?
> 2) можно ли заставить слать мне сообщения, склеенные в пачки, а не
> кусочками по 188 байт?
> 3) есть ли шанс обойтись без собственного драйвера?
>
Max Lapshin
порт, подписывается на его события и внутри себя буферизует до 1500
байт.
Joel Reymont
Max Lapshin
> А чем этот подход отличается от встроенного linked-in драйвера?
>
От драйвера prim_inet он отличается тем, что я буферизую несколько UDP
пакетов в один.
Max Lapshin
> А чем этот подход отличается от встроенного linked-in драйвера?
>
Я сейчас как раз на продуктиве делаю замеры, но пока ситуация такая:
после написания собственного linked-in драйвера,
данные перестали теряться, но начала расти память.
Я сделал вывод, что linked-in драйвер начал успевать считывать пакеты,
но теперь не успевает отдавать HTTP клиентам.
Загрузка в пике 300 mbit/s
twin
--
Страница рассылки: http://groups.google.com/group/erlang-russian
Jabber-конференция: erl...@conference.jabber.ru
Новости: http://erlanger.ru
Написать письмо: erlang-...@googlegroups.com
Отписаться: erlang-russia...@googlegroups.com
--
С уважением, Алексей.
г.Екатеринбург.
тел. +73433451059
ICQ 301833245
Max Lapshin
TCP прекрасно справляется с 950 мбит/с, вопрос только в том, что я
что-то делаю не так =(