Надеюсь, не побьют за некоторый оффтопик. В части производительности DSL-500G с прошивкой B9 я (по крайней мере, для себя) считаю его относительно реабилитированным. Попробую изложить историю вопроса и свои выводы - вдруг кому-то поможет?
С ноября я пользовался Стрим Нео+ - 160/128. Настройки осла по скорости - 14/10 Кб/с Down/Up приводили к средней скорости передачи данных 13.5/10 Кб/с Down/Up. Осёл работал стабильно и уверенно, если не считать периодической проблемы подвисания сессий со стороны DLink'а.
С 1-го марта в Стриме начал действовать новый тарифный план Стрим Нео 25 - 256/128. При этом где-то с конца февраля многие пользователи Стрим стали жаловаться на плохую работу осла ещё по старым ТП (Стрим Нео/Нео+). И, что характерно, в это же время я перепрошил свой DSL-500G с B15 на B9, чтобы, наконец, решить проблему подвисания сессий.
Решив одну проблему, получил другую - сессии стали рваться раз в полчаса - час. На разборку с этой проблемой ушло несколько дней - наступил март. Наконец, с помощью умных людей удалось увеличить Max LCP Echo Requests и всё стало тип-топ. Но скорость не увеличилась - наоборот, оставалась на катастрофически низком уровне, причём не только в прямом, но и в обратном направлении - 10 Кб/с исходящего трафика осёл отказывался держать категорически. В последнюю неделю средняя скорость стабилизировалась на уровне 9.3/8.2 Кб/с Down/Up. Да, лимит трафика в осле стоял 24/10.
Первым делом заподозрил, понятно, новую прошивку. После многочисленных экспериментов (отключение IP Filters, уменьшение таймаутов в NAT'е, ограничение кол-ва сессий в осле и т.п.) пришлось признать - DLink, похоже, не причём, или, по крайней мере, виноват не он один. Что характерно, скорость скачивания Web/FTP была нормальной - с рабочего сервера сутки качал файл со средней скоростью 27-29 Кб/с, что соответствовало ожиданиям.
При этом график скорости в осле был сильно рваным, что не давало заподозрить простую нехватку полосы пропускания в ту или иную сторону. Более того, вначале показалось, что экспериментально не подтверждается гипотеза о том, что на новом тарифном плане заужена (по сравнению со Стрим Нео) исходящая полоса - снижение лимита исходящего трафика до 5 Кб/с к улучшению (в т.ч. и по ровности графика исходящего трафика) не привели.
Почитал, что пишут люди на
СтримКлубе. Там некоторые товарищи выдвинули гипотезу, что проблема в том, что Стрим шейпит трафик на основных ословых портах (4662, 4672). Зачем - непонятно, но, тем не менее, решил проверить эту гипотезу. Поставил два случайных пятизначных порта, проткнул дырки на DLink'е, как надо - и был поражён открывшейся скоростью. Сразу появились соединения на скорости в 15-20 Кб/с, чего раньше я не видел просто никогда. Однако скорость что вниз, что вверх всё равно очень сильно плавала, а 500G регулярно писал в логи, что ATM VC Congested - я так понимаю, намекал мне, что не успевает проталкивать данные в обратный канал.
Ну что ж, намёки я ловить научился - стал снижать скорость upload'a в осле... 9, 8, 7... О, вот оно, счастье!!! При лимите 24/7 Кб/с в обратном канале установилась ровная скорость, с незначительными периодическими провалами (были и раньше), закачка - 20-22 Кб/с, что близко к теоретическому пределу. Надписи про ATM VC Congested в логах DLink'а исчезли - по крайней мере, за последние 12 часов не появилось ни одной (раньше - раз в полчаса-час).
Последние 12 часов ослик работает как часы. Правда, почему-то снова пару раз разорвалось соединение, но осёл восстанавливал скорость буквально за 10-15 минут. Если разрывы будут повторяться, буду разбираться дальше, но пока спишу на случайность.
Итак, что имеем в сухом остатке.
1. Очень похоже, что Стрим шейпит трафик на стандартных ословых портах - иначе простое уменьшение скорости в обратном канале принесло бы удачу :-). Для однозначной проверки хотелось бы скачать какой-нибудь большой файл по HTTP или FTP с сервера на порту 4662 или, наоборот, залить такой файл на машину, где работает мой осёл, на порт 4662. К сожалению, у меня такого сервера нет - если кто-то предоставит сервер на тестирование, я готов продолжить сбор доказательной базы ;-). Дополнительно можно было бы попробовать померять скорость передачи сообщений по UDP с фиксированным на уровне 2-3% процентом потерь - это сымитирует полную загрузку канала для осла (хотя, конечно, доля UDP-трафика в осле невелика, зато он наиболее критичен по времени ответа).
2. Неизвестно достоверно, проблема ли это Стрима, новой прошивки к 500G или какой-то неочевидной несовместимости между двумя - но 500G явно стал хуже держать скорость в обратном канале. В "пользу" Стрима - фокусы в прямом и обратном канале на штатных портах. В "пользу" DLink'а - надписи типа ATM VC Congested даже при использовании нестандартных портов, исчезающие при уменьшении загрузки канала. Я пока не могу придумать способа это проверить - если кто сообразит как - давайте попробуем :-).
Вот, собственно.
Вход
Регистрация
FAQ
Поиск
