Создал вчера раздачу на 15 Gb и Ростов начал тащить ее со скоростью 50 Кб/s - максимум 100 Кб/s. "Мыши плакать и колоться" не захотели, поэтому полез сегодня "гуглить". Как выяснилось - μTP в utorrent 2.0 это большое зло. Отключил его и: скорость раздачи сразу выросла до 1 Mб/s - до локалки далеко, но хоть что-то. + внешние торренты стали раздавать на весь канал. + субъективно серфить стало приятнее (свой канал теперь не забит этими "мини-пакетами"). Видимо массовое обновление до utorrent 2.0 с μTP внесло свою немалую лепту в текущее "состояние" канала "Рязань-Ростов". Ссылки по теме: Ещё вероятные виновники - μTP и российские провайдеры А торрент ли? Вопрос: Как отключить? Ответ: Настройка\Конфигурация\BitTorrent\ снять галку "Вкл. управление скоростью" Стырил с форума спарка, от юзера spamm (наш или нет не знаю )
Я как только обновился до 2.0 сразу проблемы с серфингом получил, тоже воспользовался подобным советом и все вернулось в норму.
Установил рекомендованное значение несколько дней назад, всё работает. До этого пункт "Вкл. управление скоростью" был и так выключен, но протокол работал (его индикация была рядом с IP пиров, у кого этот протокол работал, присутствовала).
Настройка\Конфигурация\BitTorrent\ снять галку "Вкл. управление скоростью" Спойлер: Картинка и вам необходимо выставить параметр bt.transp_disposition в значение 5 в расширенных настройках клиента. Спойлер: Картинка это одно и то же. после первого надо перезагрузить клиент.
Спойлер: См. картинки Настройка\Конфигурация\BitTorrent\ снять галку "Вкл. управление скоростью" Спойлер: Картинка и вам необходимо выставить параметр bt.transp_disposition в значение 5 в расширенных настройках клиента. Спойлер: Картинка это одно и то же. после первого надо перезагрузить клиент. Да, должна
Еще веселее: Bit-Torrent.Ru - Проблемы в новых версиях uTorrent 2.0 и 2.1 Alpha Спойлер: текст Если вы задавали себе вопрос: Почему uTorrent стал плохо качать и раздавать? Или скажем так: Сталкивались вы с со снижением скорости после перехода на версию 2.0? Или быть может вы заметили что ваш клиент плохо качает у версий uTorrent 2.0? А их с каждым днём всё больше и больше. Что же вы будете делать завтра, если уже сегодня большинство перешли на новую версию и у них плохо качает и плохо раздаёт? Тогда эта статья для вас. В версии uTorrent 2.0 программисты допустили 3 грубые ошибки: [1] net.max_halfopen 100 [2] net.utp_receive_target_delay 100 [3] net.utp_target_delay 100 Потому что иначе это никак назвать нельзя! [2] и [3] выставлены, по заверению программистов, для того, чтобы: - "якобы" предотвратить насыщения вашего канала и дать возможность во время скачивания или раздачи посещать веб страницы, говорить по скайпу и так далее. Все бы хорошо. Только есть одно НО: значение в 100мс слишком маленькое и не годится даже для Японии где чуть ли не каждый клиент грубо говоря: - "скоро будет иметь оптику на дому". И тогда у них по всей стране будут иметь пинги меньше 100мс. Ведь Р2Р рассчитан для всего мира, а не для конкретной страны о чем забыли когда писали uTorrent 2.0!!! Не удивляйтесь если со своим соседом вы будете иметь пинг больше 100мс - такое возможно если у вас разные провайдеры и их каналы не имеют общую точку в вашей стране и сигналы от вас до соседа могут пройти сотни километров и сотни свитчев прежде чем дойдут до вас. Могу привести наглядный пример: пусть у вас 3G модем от провайдера MTC, а у соседа что живёт этажом выше - 3G модем и провайдер Beeline. В этом случае у вас будет запаздывание 200-400 мс в среднем!!! А если только у одного из вас мобильный интернет то ваш пинг будет 100-300 мс. А в часы-пик ещё больше. Приведу усреднённый МИНИМАЛЬНЫЙ пинг ОТ ВАС ДО ВАШЕГО ЖЕ ПРОВАЙДЕРА для некоторых типов интернет с большой латентностью / оптимальное значение net.max_halfopen: 3G HSDPA - 70-110 мс /4-8 (для скоростей 128-512 кбит, для 2Мбит и выше - 8-12) EDGE - 250-350 мс /3-4 GPRS - 350-1000 мс/2-3 Dial-Up - 40-150 мс /4-8 ADSL - 10-65 мс /8-16 (больше 9 можно ставить только если ваша система это позволяет) Приведённые выше цыфры служат для примерной ориентировки, и понятия сути, потому, что с тем же самым провайдером и модемом у разных клиентов разные скорости и пинги Для выше приведённых типов соединений могут различаться. К этим цифрам надо прибавить ещё пинг от вашего провайдера до пиров. Теперь перейдём к net.max_halfopen 100. Нельзя ставить такое большое значение! Из-за такого большого значения [1] как 100 одновременных запросов на соединение или как часто пишут - полуоткрытых (не путать с количеством одновременных соединений) провайдер может "пометить" вас как флудера, а если не он - то его маршрутизатор, если не он - то программа ограничения трафика. В результате у вас возможно снижение скорости! Такое огромное значение годится разве что самому провайдеру (если он будет качать "сидя" на собственном сервере). Такое большое значение ставить нельзя! Во многих форумах это пропагандируется но люди которые пишут такое сами не понимают в этом деле ничего (видимо программисты uTorrent начитались подобных форумов и потеряли мозги) и какие последствия это может иметь. Во первых - почти все провайдеры блокируют: максимальное количество пакетов в единицу времени, максимальное кол-во полуоткрытых соединений, максимальное количество активных соединений, и так далее. (Я работаю главным помощником провайдера у которого 200 клиентов и дежурю сидя на сервере где собственно программа TrafficInspector ограничивает скорость соединения клиентам, поэтому я в курсе). В подобных программах по ограничению трафика видно все, при желании можно даже просмотреть сайты которые вы посещаете и даже видеть ваши пакеты и многое другое. Поэтому большие значения ещё не означает большая скорость, и тут действует "эффект бумеранга" то есть ваши запросы могут ставиться в очередь и вследствии этого, а также учитывая [2] и [3] - пиры uTorrent 2.0 от вас дисконнектятся даже если вы выставили в своём клиенте значение, скажем 500мс (Просто теперь ваш клиент не будет дисконнектить пиры сам если пинг не больше 500мс). Интересно, о чем же думали программисты когда ставили эти цифры? Правильно - не думали, в результате страдаем мы с вами: скорость с версией 2.0 намного меньше чем с 1.8.5, 1.8.4 и ниже, потому, что те пиры с которыми у вас пинг больше 100мс вас "недолюбливают" и стараются вас избегать. Вы сами можете поэкспериментировать с этими [2],[3] значениями и выставить на время скажем 30 мс. И в Logger (Журнал) включить Logger->Peer Traffic Logging->Log Disconnects и Log blocked connections. И увидеть сообщения типа Disconnects: Peer Error: Offline (Time Out). Для тех у кого интернет LAN будет оптимальным выставить значение [2] и [3] выше 400. Так вы сможете раздавать не только на территории России но и в Германию, Америку и так далее. И скорость однозначно возрастёт с клиентами uTorrent 1.8.5 и ниже а также другим клиентам у которых нет подобной "плохой настройки". А с клиентами 2.0 у которых по прежнему будет стоять 100 - к сожалению, они вас будут диссконнектить! Оптимальными [2] [3] будут значения, для: LAN = 400+ 3G = 1200+ GPRS =1000+ ADSL = 700+ Насчёт полуоткрытых соединений, нормальным значением будет для: 4Мбит и ниже - 8 4-10Мбит - 8-16 10-50Мбит - 16-40 50-100Мбит - 40-80 А в версии 2.1 Alpha программисты превзошли самих себя и потеряли ум и разум выставив net.max_halfopen 400!!! Такое значение годится даже не для каждый оптики! Особенно если вы не провайдер и следовательно у вас нет канала, а есть только выход в интернет со скорости до хх Мбит/с. Это совершенно разные вещи - их путать нельзя. То есть это 400 годится только для выделенного канала, а не конечного пользователя интернет. Напомню что в версии 1.8.5 и ниже это значение было равным 8! Если мы не уменьшим это число и у нас в клиенте будет более 30-50 раздач - во время запуска клиента возможны коллизии в сети. Если мы так и ничего не предпримем и каждый в ручную не уменьшит это значение то скоро начнётся настоящий БУМ провайдеров и уж поверьте на слово - никакое шифрование протокола и никакие UDP пакеты нам уже не помогут, а виноваты во всем этом будут глупцы которые выставили это значение при программировании! И начнётся настоящий, круглосуточный шейпинг протокола Р2Р. Во общем, всё что от нас требуется это уменьшить net.max_halfopen и увеличить net.utp_receive_target_delay а также net.utp_target_delay. Надеюсь эта статья многим поможет. И будем надеется что в следующей версии таких банальных дефолтовских ошибок уже не будет! bt.transp_disposition "Кто хочет по-эксперементировать с трафиком вот вам циферки 1 — исх T C P 2 — исх U T P 4 — вхо T C P 8 — вхо U T P 1=(1) исх TCP 2 =(2) исх utp 1+2 =(3) исх TCP - исх utp 4 =(4) вхо TCP 1+4=(5) исх TCP - вхо TCP 2+4=(6) исх utp - исх TCP 1+2+4=(7) исх TCP - исх utp - вхо TCP 8=(8) вхо utp 1+8=(9) исх TCP - вхо utp 2+8=(10) исх utp - вхо utp 1+2+8=(11) исх TCP - исх utp - вхо utp 4+8=(12) вхо TCP - вхо utp 1+4+8=(13) исх TCP - вхо TCP - вхо utp 2+4+8=(14) исх utp - вхо TCP - вхо utp 1+2+4+8=(15) исх TCP - исх utp - вхо TCP - вхо utp клиент придеться перезапускать тоды изменения сразу вступят в силу"
