uTP в uTorrent 1.8 и выше: что, зачем, как?

Svartalf писал(а):

никогда не исповедую этот принцип

Я сам участвовал в разработке некоторых вещей, и могу сказать что "зависит от случая" иногда этот принцип оправдан (а иногда и в правду чем новее тем лучше, даже если бета)

Svartalf
хорошая позиция, одобряем-с, нужно из всех бачков отхлебнуть самому и сразу, чтобы не переживать потом, что все без тебя выхлебали пока теплое!

s19 а то ))) за то я точно знаю где косяки и где их лечит если вдруг у старообрядцев будут проблемы... и лучше я буду хлебать время от времени чем полный залп после релиза.... знаешь как в старину.. потихоньку приучали к яду... давали на протяжении всей жизни. так и я .... ну подумаешь баг, подумаешь два зато потом меня не сокрушить даже багопадом ^__________^

ну а я все же предпочту посидеть в багоубежище, пока метеоусловия не стабилизируются

s19 ксттаи я например не могу пользоваца 2.1 торентом по причине его мертвого висяка при моём количестве торентов...100% загрузка проца и ацкое зажэирание оперативы... хотя я бы хотел.. но тут к сожалению объективная причина... если можно так сказать критический баг (для меня критический само собой)

если кто сидит на последних бетах (2.0.1 билд 18408), то имеет смысл выставить в "продвинутых" настройках:

net.utp_dynamic_packets_size = false
net.utp_initial_packet_size = 8

первая отключает динамический размер UDP-пакетов,
второй включает всегда максимальный размер пакета.
там возможные значения 1 - 150 байт, 2 - 300 байт, 4 - 600 байт, 8 - 1200 байт.
естественно, MTU надо выставить на максимум, для LAN подключения это обычно 1480 байт,
для определения/настройки есть разные тулзы, мне нравится TCPOptimizer

зачем всё это надо? новый протокол, uTP, вызвал довольно много дискуссий, в том числе и среди провайдеров. одна из целей его введения была - как раз каналы провайдеров разгрузить. но получилось так, что старый TCP-трафик ходил пакетами максимального размера, а новый, с целью "оптимизации", uTorrent разбивал на крохотные пакеты, в результате количество пакетов в секунду у провайдеров выросло чуть ли не в полтора раза, вместе с этим - и нагрузка на маршрутизаторы.

для нас, простых пользователей, важно другое. какая доля трафика "полезная", а какая - "служебная", т.е. какой % канала тратится на заголовки пакетов, подтверждения доставки, обмен пирами, DHT и всем остальным, что не относится к данным раздачи. на офф. форуме публиковались тесты, что на стандартных настройках "overhead" был 20% а если настроить чтобы всегда использовались UDP-пакеты максимального размера - то он опускался ниже 10%.

сколько уходит впустую в случае только TCP-соединений точно не знаю, что-то порядка 5-10% вроде. стоит ли вообще отключить UDP-протокол - вопрос интересный. с одной стороны, доля полезного трафика там по-прежнему выше, т.е. на одном и том же канале за сутки можно раздать больше. с другой, админы некоторых закрытых трекеров вообще запретили uT 2.0+ т.к. он предпочитает соединяться с себе подобными.

суть такая, что сначала он пытается установить UDP-соединение, и если за несколько секунд не получил ответа - пытается соединиться по TCP. и если сразу получилось установить достаточное количество uTP-соединений, то дальше пытаться он уже и не будет. и получается, что клиенты uT 2.0+ со включенным uTP получают преимущество. и, в результате, раздают больше трафика чем другие клиенты, имеют выше ратио, что некоторые админы считают нечестным конкуретным преимуществом, и поэтому на своих трекерах uT 2.0+ запрещают вообще.

так что стоит ли uTP отключать - это ещё вопрос. да и вообще, этот uTP - штука очень экспериментальная, и, похоже, её ещё долго отлаживать/оптимизировать будут. в версии 2.0.1 изменения существенные. там даже "заголовок" протокола изменился, если bt.transp_disposition ставить не 15 а 31 то раньше все 2.0 соединялись, а теперь только с последними билдами.

Вот наковырял - вполне грамотно написанно я так думаю. Не знаю от чего, но у меня в последнее время маршрутизатор начал падать - Cisco и канал Akado безлимитный. Сделал все как написанно здесь, уже 5 дней без проблем работает.

Проблемы в новых версиях uTorrent 2.0 и 2.1 AlphaЕсли вы задавали себе вопрос:
Почему uTorrent стал плохо качать и раздавать? :demon:
Или скажем так:
Сталкивались вы с со снижением скорости после перехода на версию 2.0?
Или быть может вы заметили что ваш клиент плохо качает у версий uTorrent 2.0? А их с каждым днём всё больше и больше. Что же вы будете делать завтра, если уже сегодня большинство перешли на новую версию и у них плохо качает и плохо раздаёт? :cray:
Тогда эта статья для вас.

В версии uTorrent 2.0 программисты допустили 3 грубые ошибки:
[1] net.max_halfopen 100
[2] net.utp_receive_target_delay 100
[3] net.utp_target_delay 100
Потому что иначе это никак назвать нельзя!
[2] и [3] выставлены, по заверению программистов-:fool:, для того, чтобы:
- "якобы" предотвратить насыщения вашего канала и дать возможность во время скачивания или раздачи посещать веб страницы, говорить по скайпу и так далее.
Все бы хорошо. Только есть одно НО: значение в 100мс слишком маленькое и не годится даже для Японии где чуть ли не каждый клиент грубо говоря:
- "скоро будет иметь оптику на дому". И тогда у них по всей стране будут иметь пинги меньше 100мс. Ведь Р2Р расчитан для всего мира, а не для конкретной страны о чем забыли когда писали uTorrent 2.0!!!
Не удивляйтесь если со своим соседом вы будете иметь пинг больше 100мс :rolf: - такое возможно если у вас разные провайдеры и их каналы не имеют общую точку в вашей стране и сигналы от вас до соседа могут пройти сотни километров и сотни свитчев прежде чем дойдут до вас.
Могу привести наглядный пример: пусть у вас 3G модем от провайдера MTC, а у соседа что живёт этажём выше - 3G модем и провайдер Beeline. В этом случае у вас будет запаздывание 200-400 мс в среднем!!!:megashok: А если только у одного из вас мобильный интернет то ваш пинг будет 100-300 мс. А в часы-пик ещё больше.:megashok:
Приведу усреднённый МИНИМАЛЬНЫЙ пинг ОТ ВАС ДО ВАШЕГО ЖЕ ПРОВАЙДЕРА для некоторых типов интернет с большой латентностью / оптимальное значение 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 раздач - во время запуска клиента возможны коллизии в сети.
Если мы так и ничего не предпринем и каждый в ручную не уменьшит это значение то скоро начнётся настроящий БУМ провайдеров :bomb: и уж поверьте на слово - никакое шифрование протокола и никакие UDP пакеты нам уже не помогут, а виноваты во всем этом будут глупцы которые выставили это значение при программировании!
И начнётся настоящий, кругласуточный шейпинг протокола Р2Р.
Вообщем, всё что от нас требуется это уменьшить
net.max_halfopen
и увеличить
net.utp_receive_target_delay а также net.utp_target_delay.
Надеюсь эта статья многим поможет.
И будем надеется что в следующей версии таких банальных дефолтовских ошибок уже не будет!

И еще выставить значение bt.transp_disposition=5

Alex Walex писал(а):

Вот наковырял - вполне грамотно написанно я так думаю...

Много написано и возможно технически правильно. Но, как бы не хулили ветку 2.0, у нее есть несомненный жирный плюс.

anonymous писал(а):

Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.

В качестве примера скриншот Ранее при таком раскладе пиры не находили друг друга, сейчас коннект возможен.

Alex Walex
Сделал всё как описано и вот что вышло: 1 — это я приостановил закачки и сменил мои настройки на предложенные;
2 — восстановил свои настройки (без приостановления).
Кроме указанных параметров больше ничего не менялось.

µTorrent 2.1 alpha 18683.

P.S. До 1 точки можно не смотреть — там я всячески экспериментировал с настройками.

Cama писал(а):

Ранее при таком раскладе пиры не находили друг друга, сейчас коннект возможен.

не совсем понятно из скриншота, почему ранее они друг друга не находили...

Скриншот показывает что сейчас идет обмен между пирами (необходимые пункты выделены). На пред. версиях клиента пиры отображались в таблице, но обмена не было - клиент их не связывал. Тот пир (лич), у которого порт помечен красным значком находится за NAT`ом, и таких в рунете очень много...

А тот пир у которого зеленый значек - может принимать входящие соединения, и к нему любой желающий может подключиться - хоть с красным, хоть с каким значком...

Не всегда, если "зеленый" сид использует локальную маршрутизацию (что по сути ранвно как за натом), красный лич до него недостучится. Если сид отключит маршрутизацию, тогда коннект пойдет. Сейчас на v.2.0 эта проблемма коннекта осталась позади.

Не знаю, поможет или нет, но у мну конкретные настройки таковы:

bt.tcp_rate_control = false
bt.transp_disposition=5
net.max_halfopen = 4
net.utp_target_delay = 1000
net.utp_receive_target_delay = 1000

Версия 2.0.1 b.18758

P/S/ Научите картинки в спойлер вставлять плиз....

Alex Walex писал(а):

P/S/ Научите картинки в спойлер вставлять плиз....

FAQ BBCode
Добавлю, аналогично работает тег hide. Разница что информация заключенная в hide, доступна гостям.