Sergey Zozulya

Keenetic Ultra II, v2.09(AAUX.2)A1 Помогите, пожалуйста, разобраться в работе IntelliQoS и/или dpi white-list/black-list. Основной вопрос в том, работает ли шейпинг для встроенного клиента Transmission или только для устройств из домашней сети. Сейчас в конфиге включено dpi black-list (service dpi и dpi shaping, разумеется, тоже), т. е., насколько я понимаю, при недостаточной полосе пропускания, torrent-трафик должен резаться для освобождения канала любому другому трафику. Но не похоже, что сейчас это работает, т. к. при активных закачках встроенного клиента Transmission посмотреть, к примеру, YouTube на TV или смартфоне не получается по причине загруженности канала. Интернет получаю по ADSL очень слабый - 4 Mbit downstream / 0.5 Mbit upstream, поэтому постоянно приходится выбирать между закачками в Transmission и всем остальным. Сейчас настроено расписание, и Transmission работает в полную силу только ночью, в остальное время с сильно зарезанной скоростью, чтобы можно было пользоваться интернетом днем. Либо приходится постоянно дергать черепаший режим, если есть необходимость скачать что-то на полной скорости днем. Пробовал включать IntelliQoS и выставлять Internet connection speed в его настройках в соответствии со своей downstream скоростью, результат тот же. При включении dpi shaping, судя по логам, настройки IntelliQoS отключаются и начинает действовать политика white-list/black-list. Возможно, есть какие-то тонкости в настройке шейпера, о которых я не знаю. В идеале хотелось бы настроить шейпинг таким образом, чтобы при свободном канале встроенный клиент Transmission качал на всю ширину канала, но в случае появления другого трафика принудительно резался, освобождая канал. Такое возможно? Если не с помощью шейпинга, то какие еще могут быть варианты? Спасибо.

Встречный вопрос - почему не рассматривается вариант того, что проблема в раздающем ZTE?

Действительно отличная идея!

Потому и вывод сразу был, что баг. Chrome, в данный момент v55.0.2883.75 (64-bit), OS Linux. Сейчас повторить не удается.

Тоже повторил. Вряд ли это фига) Учитывая внешний вид, похоже на баг.

Я как бы не с претензией, на iOS оно мне не нужно. Просто интересно узнать, что такое страшное нарушается с точки зрения Apple, если в приложении есть функция управления торрентами.

Как раз хотел задать вопрос, почему этого нет в приложении для iOS. Какие политики Apple при этом нарушаются?

Насколько я понимаю, сейчас, если приложение было сопряжено с роутером в одной WiFi сети, то устройство, с которого это было сделано, становится cloud client (о чем есть информация в веб-конфигураторе - Applications > Cloud clients). После этого роутер доступен с помощью приложения с этого устройства из любого места, где есть выход в интернет. Однако, подключиться к роутеру, с которым не было сопряжения в одной WiFi сети, сейчас нельзя. Также, после полного сброса и восстановления настроек необходимо повторное сопряжение с помощью приложения, т. к. cloud clients не восстанавливаются из файла настроек.

Как памятка можно всегда посмотреть здесь: System > Settings > Web interface port. В выпадающем списке есть все эти порты.

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

Не знаю, будет ли еще кому-то это нужно, но мне с ADSL-интернетом очень полезна была бы индикация режима "черепаха" в торрент-клиенте. Довольно часто приходится этот режим включать/выключать, и так же часто забывать, какой именно режим сейчас.

Думаю, наиболее полную информацию можно будет узнать именно от разработчиков на этом форуме, потому как бОльших подробностей, чем от @ndm в теме из цитаты выше, мне не удалось по всему Интернету найти. Уж если кто и скажет нам правду (насколько это возможно), то это местная дрим-тим! Остается следить за новостями.

Ситуация с Plus DSL более прозаичная, но и более обнадеживающая: Остается надеятся, что все проблемы скоро разрешатся и эти устройства поступят таки в продажу.

Тесты-то на стоковой прошивке проведены.

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

Мерять не меряю, конечно, но что мешает разделить объем большого файла на время его передачи для общей оценки скорости. Тем более, когда скорость отличается в 3-10 раз в худшую сторону от ожидаемой. Гугл это хорошо, но, к примеру, управлять ни мощностью, ни Jumbo фреймами на таких клиентах, как смартфон, телевизор и др. чисто пользовательских устройствах штатно нет никакой возможности. Ведь, по крайней мере в моем случае, вопрос скорости WiFi между кинетиком и домашними устройствами имеет не принципиальный (заставить WiFi работать "как надо" во что бы то ни стало), а исключительно бытовой, потребительский смысл. Банально перекинуть кино с/на HDD, подключенного к кинетику, с помощью различных устройств в домашней сети - планшетов, смартфонов, ноутбуков. Главный вопрос здесь скорее такой - почему для FTP 30-35 MB/s это не проблема (скорость линка WiFi AC 877 Mbps ), несмотря на мощность сигнала (впрочем, не знаю, что повлияло конкретно, но скорость удалось поднять с 20 MB/s до 30-35 MB/s снижением мощности со 100% до 10%), Jumbo фреймы и прочее, тогда как для SMB максимум, чего удалось добиться, это 10-12 MB/s?

@zyxmon не то чтобы стыдливо, просто, к примеру, я не знаю, как регулировать мощность WiFi сигнала на Android-смартфоне или ноутбуке с Linux. Вообще не предполагал, что есть такая необходимость. Разве клиенты не управляют мощностью сигнала автоматически? Подскажите, как это сделать.

В упомянутой в первом посте теме писал, что мощность сигнала никак не влияет на результат. no ppe software надо попробовать, такой рекомендации еще не видел. Стоит добавить, что включение tx-burst, как советовали в той теме, также вообще не влияет на результат.

К слову, включение tx-burst вообще ничего не меняет.

@Padavan tx-burst так включается? interface WifiMaster1 tx-burst system configuration save

Разве tx-burst не для b/g клиентов только? Работает ли этот режим с n/ac?

@Proximus а на Linux машине и на Android есть возможность проверить?

@ndm, @Le ecureuil, не могли бы вы высказать свое мнение по этому вопросу? Возможно, есть место для маневров, и мы могли бы помочь разобраться в проблеме. Знать бы, куда копать.

На Android у меня вообще в районе 4MB/s при линке 877Mbps. Описанная выше ситуация у меня на ноутбуке с Linux. Машин с Windows нет, чтобы проверить.

@Proximus ситуация в точности такая же. Один в один. Даже HDD точно такой же. Разве что прошивка последняя тестовая 2.08.A.10.0-0, но так же было и на предыдущих. По SMB скорость 10 Мб/с +- 3, по FTP достигает 35 Мб/с (аплоад на HDD по FTP ровно 20 Мб/с). Загрузка CPU также минимальна. Перепробовал все, что в голову пришло - мощность WiFi, ширина канала, страна, разные порты и режимы USB. Что еще можно попробовать, не знаю. Ввиду недостатка знаний, пришел к выводу, что так работает SMB. Сейчас пользуюсь FTP, благо необходимость в этом возникает редко, копать дальше не стал. У знакомого на Giga III так же. Готов присоединиться к тестированию и проверке этой багофичи, если потребуется.