Jump to content

Himmler

Forum Members
  • Content Count

    36
  • Joined

  • Last visited

Community Reputation

2 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. Сегодня впервые за годы поймал на удалённом кинетике 2.14 такую же проблему, которая продолжается до настоящего времени. Веб-морда не грузится, CLI работает худо-бедно (system reboot не исполняется). В логах CLI весьма насторожила многократно повторяющаяся строчка: W [Feb 27 20:18:38] ndm: Core::Watchdog: Event sender holds SSL_SERVER (19) lock 15660 seconds acquired Feb 27 15:57:37. Аптайм около 9-10 суток, памяти свободно около 40%, CPU загружен на 1-5 %.
  2. У Вас как-то очень резко растёт среднее время задержки с ростом размера пакета. На моём канале для icmp-пакета с "нагрузкой" в 32 байта среднее время 7 мсек, при 65000 байтах - 22 мсек. А у вас уже на 2500 байт такая задержка, хотя на мелких пакетах она меньше моей. Ну это не очень относится к делу, а вот логи трансляции может что-то и скажут, почему же трансляция не стартует. Они лежат в C:\Program Files (x86)\Steam\logs, файлы: streaming_log.txt StreamVideoTrace.txt StreamAudioTrace.txt Возможно, там будет что-то явно указано, что именно не удалось клиенту steam.
  3. В настройках трансляции можно включить отображение статистики. Расширенное отображение включается/выключается клавишей F6 во время трансляции. Там указана задержка ввода, задержка отображения, текущий реальный битрейт и прочее. Интересно, почему без туннеля клиенты находят друг друга, но трансляция не запускается? Пробовали в таком режиме пинговать пакетами более 1500 байт?
  4. У меня на одной стороне Pentium 4 3,4 Ггц на s478. Даже если там очень-очень оптимизированное шифрование со всякими SSE, для канала в 40 мегабит мой ЦП будет добавлять миллисекунд 10, а может и более. Потому как старичку 15 лет и он примерно в 10 раз менее производителен, чем i7 2700K (который тоже уже немолод) Так что в моём случае время точно увеличится, и заметно. Потому как мой случай близкий к предельному (с точки зрения производительности).
  5. Разве что на каждом из клиентов работает софтварное шифрование, которое сколько-то добавляет к задержке. Очень вероятно, что менее 1 мсек.
  6. Насколько я знаю, сервер hamachi используется при установке соединения, сам же трафик через сервер не проходит, а идёт напрямую от клиента 1 до клиента 2.
  7. Ну, если сарай пустой, то дверь можно в принципе не закрывать. К тому же, для поднятия туннеля, нужно чтобы адрес назначения на обоих концах был верный. А задаётся он из настроек кинетика. Так что для подключения нужно либо угадать и заиметь тот адрес, который я прописал в настройках, либо эти настройки изменить. На мой взгляд, нужно быть чертовски кулхацкером, чтобы проделать первое и/или второе.
  8. Да, безопасности никакой. Так что я заранее озаботился тем, чтобы в домашней сети не было ничего ценного.
  9. У меня один из самых "чахлых" Lite III rev A. EoIP без шифрования выдаёт 86-88 мбит/с. Если не опасаетесь гонять нешифрованный трафик - можно взять keenetic start 2 рублей за 1200. Адрес у меня белый динамический, привязан к KeenDNS. С серым, насколько знаю, EoIP не поднимется. Для вменяемого качества трансляции нужно около 40 мбит/с для fullHD с h264. Если между машинами пинг более 20 мс - то задержка от ввода до отображения кадра будет около 50-60 мсек, в динамичные шутеры уже некомфортно. У меня между машинами пинг через туннель 7 мсек, задержка от ввода до отображения кадра около 40 мсек - вполне играбельно.
  10. У меня домашняя трансляция Steam работает через EoIP-туннель между двумя кинетиками. Вы уверены, что Вам нужен именно VPN? По сути требуется общий L2 сегмент, EoIP - как раз то, что нужно.
  11. Himmler

    Поддержу предыдущего товарища. Конкретно меня интересует возможность приоритезации трафика. На данный момент в сети есть устройство с трафиком примерно в 35-40 мбит/с, чувствительное к задержкам. И есть несколько других, с трафиком 5-10 мбит/с. Непосредственно пропускной способности хватает на всех (она около 85 мбит/с), но при использовании канала другими устройствами, задержка пакетов для первого устройства заметно возрастает. Можно ли сгладить это влияние ограничением полосы либо приоритезацией ?
  12. Уже было. Вот здесь подробности, если коротко - то это работает, но очень неудобно. Я-то для перезапуска туннелей давно написал скрипты, и стартую их, когда надо. Но хотелось бы без этого.
  13. Провайдер время от времени рвёт PPPoE-сессию и выдаёт новые IP-адреса. В туннелях остаются старые (потому как во время создания туннеля к ddns-имени были привязаны старые). Приходится перезапускать.
  14. Мне бы тоже весьма пригодилось. Кроме того, было бы чрезвычайно полезно добавить хоть какую-то возможность самовосстановления туннелей EoIP (сейчас приходится вручную перезапускать через CLI)
×
×
  • Create New...