С доводами согласился, попробовал на практике, но особых качественных изменений не произошло. Видимо, в моём случае дело в чём-то другом.Originally Posted by Oleg
Administrator
Ошибаетесь, может быть лучше, здесь нужно найти баланс между скоростью и количеством ошибок. Чем больше скорость, тем больше вероятность ошибок. Чем ниже рейт мультикаста, тем меньше ошибок, но при этом он начинает забивать Wifi и работать будет невозможно.
Member
С доводами согласился, попробовал на практике, но особых качественных изменений не произошло. Видимо, в моём случае дело в чём-то другом.
Senior Member
Интересно, ресурсов роутера хватит на преобразование UDP multicast в TCP unicast?
На форуме стримовцев обсуждался такой вариант - на компьютере подключенным проводом запускается VLC, которая принимает мультикаст и вещает его в юникасте через wi-fi. На ноутбуке в этом случае никаких рассыпаний картинки - скорости беспроводного канала хватает.
Administrator
Технически это можно реализовать гораздо проще: достаточно заменять МАК адрес с мультикастного на адрес клиента. При этом vlc даже ничего не заметит, а трафик будет сыпаться только куда надо... Только это требует глубоких разбирательств...
Senior Member
Основная проблема, как мне кажется, в UDP т.е. пропущенный пакет теряется безвозвратно. Кроме преобразования в юникаси нужен буфер, чтобы можно было отправить повторно.
Member
согласен, причем при потоке ~8мбит для 1 секунды нужен 1 мбайт, что в общем-то реально, но вот для этого в роутере придется организовать какой-либо медиа сервер, возможно ли это сделать средствами железки?
Member
У меня если ставлю на 54 вообще умирает, поэтому мой диапазон с 12 до 36, тогда ничего не рассыпается
Member
а можно увидеть вашу таблицу маршрутизации, igmpproxy.conf, и iptables?
Member
Ну igmpproxy.conf и iptables мои выложены тут в самом начале поста, как впрочем и все остальные настройки
Senior Member
Размер окна TCP, насколько я знаю, значительно меньше, точных цифр не помню. Соотв. буфер потребуется меньшего объема.
Member
на сколько язнаю, как раз наоборот, но не в этом суть, т.к. логично хранить как раз то что получили, а на отдачу формировать на лету tcp пакеты, и чистить буфер по подтверждению
Member
Наступил на странные грабли..
На этапе отладки, так уж получилось, запускал igmpproxy из post-mount.
Тут сегодня решил сделать окончательную версию, перенёс конфиг с харда, чтобы во флэше сохранялся, запуск прописал, как Олег, в post-boot.
И не работает..
Если из post-boot запускать - после загрузки даже нет этого процесса.
Пробовал из post-firewall - процесс есть, но не работает. В логе сплошь одни "kernel: mroute: pending queue full, dropping entries". Из post-mount - всё отлично запускается и показывает.
Попробовал сделать скрипт который запускает igmpproxy после минутной паузы. Скрипт запускал из post-boot. Сдвиги есть, процесс в памяти виден, но все тот же mroute: pending queue full.
У меня выход в инет через vpn. Попробовал переключил роутер из режима PPTP в Static IP (т.е. только локалка, без инета) - igmpproxy отлично запускается из post-boot и отлично работает..
Где копать?
Конечно, у меня хард почти всегда включён, каких-то особых проблем нет, могу запускать из post-mount.. но хочется чтобы тв работал и в том случае если хард выключен, когда post-mount не запускается.
Member
Мда.. всё ещё хуже.. но уже с другой стороны.
Где-то уже читал об этом.. В момент когда у меня на основном компе идёт приём тв, у жены инет идущий через wifi отрубается на ноуте, её локальный ip даже не пингуется. Стоит тв выключить - сразу всё начинает работать и пинговаться.
Чуть позже:
Пинговал ноут с роутера в момент просмотра, показывает всё же что контакт есть, но пинг 2000-3000..
Ещё чуть позже:
Мне пожалуйста приз как самому бестолковому юзеру wl500gP.
В пылу борьбы с первой проблемой, из автозапуска исчезла строчка wl rate 36. Оказывается дело было в этом. Причем, что удивительно (для меня по крайней мере), что если эта строчка отсутствует, то идут подобные провалы, если же присутствует (даже с любым значением, пробовал 24 36 54) то всё ок..
Last edited by Speedy Gonzalez; 21-11-2006 at 20:14.
Administrator
Насчёт post-boot. Есть такая фигня: igmpproxy сносит крышу при каких-то обстоятельствах и он начинает не переставая слать мультикаст во внешнюю сеть. Бум посмотреть.
Administrator
А сносит ему крышу при синхронизации времени. Т.е. если время перескакивает вперёд, то он пытается видимо отработать все "пропущенные" события. Будем искать и править.
Posting Permissions
