Jump to content

Himmler

Forum Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Himmler

  • Rank
    Member

Equipment

  • Keenetic
    Lite III

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. У Вас как-то очень резко растёт среднее время задержки с ростом размера пакета. На моём канале для icmp-пакета с "нагрузкой" в 32 байта среднее время 7 мсек, при 65000 байтах - 22 мсек. А у вас уже на 2500 байт такая задержка, хотя на мелких пакетах она меньше моей. Ну это не очень относится к делу, а вот логи трансляции может что-то и скажут, почему же трансляция не стартует. Они лежат в C:\Program Files (x86)\Steam\logs, файлы: streaming_log.txt StreamVideoTrace.txt StreamAudioTrace.txt Возможно, там будет что-то явно указано, что именно не удалось клиенту steam.
  2. В настройках трансляции можно включить отображение статистики. Расширенное отображение включается/выключается клавишей F6 во время трансляции. Там указана задержка ввода, задержка отображения, текущий реальный битрейт и прочее. Интересно, почему без туннеля клиенты находят друг друга, но трансляция не запускается? Пробовали в таком режиме пинговать пакетами более 1500 байт?
  3. У меня на одной стороне Pentium 4 3,4 Ггц на s478. Даже если там очень-очень оптимизированное шифрование со всякими SSE, для канала в 40 мегабит мой ЦП будет добавлять миллисекунд 10, а может и более. Потому как старичку 15 лет и он примерно в 10 раз менее производителен, чем i7 2700K (который тоже уже немолод) Так что в моём случае время точно увеличится, и заметно. Потому как мой случай близкий к предельному (с точки зрения производительности).
  4. Разве что на каждом из клиентов работает софтварное шифрование, которое сколько-то добавляет к задержке. Очень вероятно, что менее 1 мсек.
  5. Насколько я знаю, сервер hamachi используется при установке соединения, сам же трафик через сервер не проходит, а идёт напрямую от клиента 1 до клиента 2.
  6. Ну, если сарай пустой, то дверь можно в принципе не закрывать. К тому же, для поднятия туннеля, нужно чтобы адрес назначения на обоих концах был верный. А задаётся он из настроек кинетика. Так что для подключения нужно либо угадать и заиметь тот адрес, который я прописал в настройках, либо эти настройки изменить. На мой взгляд, нужно быть чертовски кулхацкером, чтобы проделать первое и/или второе.
  7. Да, безопасности никакой. Так что я заранее озаботился тем, чтобы в домашней сети не было ничего ценного.
  8. У меня один из самых "чахлых" Lite III rev A. EoIP без шифрования выдаёт 86-88 мбит/с. Если не опасаетесь гонять нешифрованный трафик - можно взять keenetic start 2 рублей за 1200. Адрес у меня белый динамический, привязан к KeenDNS. С серым, насколько знаю, EoIP не поднимется. Для вменяемого качества трансляции нужно около 40 мбит/с для fullHD с h264. Если между машинами пинг более 20 мс - то задержка от ввода до отображения кадра будет около 50-60 мсек, в динамичные шутеры уже некомфортно. У меня между машинами пинг через туннель 7 мсек, задержка от ввода до отображения кадра около 40 мсек - вполне играбельно.
  9. У меня домашняя трансляция Steam работает через EoIP-туннель между двумя кинетиками. Вы уверены, что Вам нужен именно VPN? По сути требуется общий L2 сегмент, EoIP - как раз то, что нужно.
  10. Himmler

    Поддержу предыдущего товарища. Конкретно меня интересует возможность приоритезации трафика. На данный момент в сети есть устройство с трафиком примерно в 35-40 мбит/с, чувствительное к задержкам. И есть несколько других, с трафиком 5-10 мбит/с. Непосредственно пропускной способности хватает на всех (она около 85 мбит/с), но при использовании канала другими устройствами, задержка пакетов для первого устройства заметно возрастает. Можно ли сгладить это влияние ограничением полосы либо приоритезацией ?
  11. Уже было. Вот здесь подробности, если коротко - то это работает, но очень неудобно. Я-то для перезапуска туннелей давно написал скрипты, и стартую их, когда надо. Но хотелось бы без этого.
  12. Провайдер время от времени рвёт PPPoE-сессию и выдаёт новые IP-адреса. В туннелях остаются старые (потому как во время создания туннеля к ddns-имени были привязаны старые). Приходится перезапускать.
  13. Мне бы тоже весьма пригодилось. Кроме того, было бы чрезвычайно полезно добавить хоть какую-то возможность самовосстановления туннелей EoIP (сейчас приходится вручную перезапускать через CLI)
  14. Если кому-то вдруг нужно для статистики - добрались руки до iperf, проверил свой EoIP. Итак, имеется два Keenetic Lite III rev A (без криптомодуля) в сети одного провайдера на расстоянии около 50 километров (один через FTTx , другой через GPON). Туннель безо всякого шифрования, голый EoIP. Выдаёт 86-88 Мегабит при теоретическом потолке в 100. Задержки на маленьких пакетах (до 1500 байт) что внутри туннеля, что вне туннеля - 6-8 мсек. То есть EoIP-туннель не увеличил задержку (по крайней мере сколь-нибудь видимо), и выдал практически 90% от теоретической пропускной способности для идеальных условий. И это на одних из самых "хилых" устройств (насколько знаю, самый бюджетный Keenetic Start II имеет такую же аппаратную платформу, кроме обвязки физики eth) Шифрование, думаю, заметно повлияет на результат, но для моего случая оно не требуется. Вопрос вдогонку: У провайдера есть пул белых динамических адресов, но он частенько заканчивается. Тогда провайдер выдаёт серый адрес. Я решаю это перезапуском PPPoE, и раза с 3-4 мне таки-достаётся белый адрес. Что делать, если со временем получить белый адрес будет всё сложнее и сложнее ? Как наиболее просто в таком случае поднимать EoIP ?
×