Про µTP в новых версиях µTorrent: что это, как, зачем?
Автор
Сообщение
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.
Update: Официальная документация на протокол: www.bittorrent.org/beps/bep_0029.html
Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу.
Поскольку торрент-клиент и так этим занимается — это не большая проблема. Дело в том, что посылаемые через TCP-«трубу» данные в процессе разбиваются на куски («пакеты»), каждый из которых отправляется независимо. При этом один пакет может идти одним маршрутом, другой — другим, последний кусок может прийти первым, первый — вообще по дороге потеряться. Поэтому каждый участник «трубы» (от операционной системы до маршрутизаторов) вынужден хранить у себя буфер, в который собирает отдельные пакеты, проверяя целостность и порядок, и требуя перепосылку если часть пакетов не дошла.
При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.
Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:
1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения
Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.
В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP — благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего.
Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.
Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.
Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.
За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrentе начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне
Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.
Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.
Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее».
Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.
С другой стороны, не всё сетевое железо — модемы, марштуризаторы — и не весь софт рассчитывался на такое количество UDP-трафика, поэтому у некоторых пользователей с ним возникают глюки. Например со скоростью — когда периодически она вдруг падает до нуля, потом снова восстанавливается, или плавает от нуля до максимума. Видимо где-то в сетевом окружении переполняется некий связанный с UDP буфер, чёрт знает. Опять же, на официальном форуме можно поискать про совместимость с разным софтом и железом в случае проблем.
Другие «продвинутые» опции, на которые можно обратить внимание:
bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше.
peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.
Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: http://forum.utorrent.com/viewtopic.php?id=60602
По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает.
Взято http://habrahabr.ru/blogs/p2p/68332/
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Не спешите включать эту опцию а если включена то лучше выключить её тобешь поставить параметр bt.transp_disposition 5 так как возможно из за этого новшества понизится скорость скачки и отдачи! Посмотреть клиентов с включеным uTP можно во вкладке пиры скорость скачки с них гораздо ниже у этих пиров присутствует флаг P это означает что скачка идёт по UDP протоколу
Последний раз редактировалось: P_L_A_Y_B_O_Y (2010-02-03 15:38), всего редактировалось 3 раз(а)
Топик был перенесен из форума Общение в форум Вопросы по BitTorrent сети и ее клиентам
MadMaxx
Sunchees
Стаж: 14 лет
Сообщений: 5
Откуда: Стерлитамак
P_L_A_Y_B_O_Y +1 Еще давно заметил, что включив данную опцию скорость теряется довольно сильно, тем более, что почему-то utorrent подцепив пира по TCP переводит на uTP при любой возможности и скачивать становится проблематично. Поэтому - в обязательном порядке меняем параметр bt.transp_disposition на 5. Это касается как версий 1.8, так и тем более - версий 2.0.
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
По идеи должно работать быстрее по UDP т.к. служебных данных в нём меньше, но почемута не хочет, да и не к чему это нам в локале т.к. наш провайдер трафик не режет и поэтому обходить его нет смысла.
Sadrik
Стаж: 14 лет
Сообщений: 37
Откуда: Russia
P_L_A_Y_B_O_Y Sunchees заменил на 5 : скорость отдачи с 1.0мБ/с поднялась до 1.1мБ/с (это в среднем, так как в реальности скорость прыгает)
возник еще вопрос: заметил, что иногда не запускается новая, только что выложенная раздача. ретрекер прописан, IP релизера вписан. Помогает пингование его хоста - раздача запускается после этого. Что это? глюки трекера? таблиц маршрутизации с которыми он работает?
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Я думаю трабла всёже в трекере т.к. маршруты прописываются при подключении к сети и не меняются до следуещего переподключения!
Im Exclusivе
Стаж: 14 лет
Сообщений: 6
Откуда: Уфа
Как мне сделать так чтоб раздовалась одна, из трех раздач и с максимальной скростью...
Подскажите пожалуйста у меня клиент 1.8.5
Sunchees
Стаж: 14 лет
Сообщений: 5
Откуда: Стерлитамак
P_L_A_Y_B_O_Y Цитата:
По идеи должно работать быстрее по UDP т.к. служебных данных в нём меньше, но почемута не хочет, да и не к чему это нам в локале т.к. наш провайдер трафик не режет и поэтому обходить его нет смысла. Это только по идее. Видимо дело в оборудовании. Скорость ниже - это факт. Как бы плохо это не было... Sadrik Цитата:
заменил на 5 : скорость отдачи с 1.0мБ/с поднялась до 1.1мБ/с (это в среднем, так как в реальности скорость прыгает) Ну отдача зависит не только от тебя и максимум что можно выжать - 1,2 мБ/с. Данная опция актуальна больше для скорости загрузки, особенно когда на раздаче не слишком много сидов и у каждого из них не весь канал уходит на данную раздачу. Цитата:
возник еще вопрос: заметил, что иногда не запускается новая, только что выложенная раздача. ретрекер прописан, IP релизера вписан. Помогает пингование его хоста - раздача запускается после этого. Что это? глюки трекера? таблиц маршрутизации с которыми он работает? Однозначно - глюки трекера. Ретрекер это скорее заглушка, которая ни на что не влияет, только поддерживает зеленый (или синий) цвет, чтобы вопросов было поменьше. Ну и иногда бывает, что у релизера проблемы, поэтому даже с прописанным айпи не сразу запускается. Во всяком случае при создании трекерлесс-раздач - таких проблем у меня не было, все всегда запускается на раз-два. Allen Iverson3 Цитата:
Как мне сделать так чтоб раздовалась одна, из трех раздач и с максимальной скростью...
Подскажите пожалуйста у меня клиент 1.8.5 Ограничь скорость остальных до 1 кб/с. Выделяешь все раздачи, кроме нужной (которую хочешь раздавать), затем правой кнопкой мыши. Свойства, максимальная скорость отдачи ставишь значение 1, жмешь ОК.
Trand
Стаж: 14 лет
Сообщений: 235
Откуда: Стерлитамак
полезная штука
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Serega1991 Полезная но только не для сети Уфанет!
Sadrik
Стаж: 14 лет
Сообщений: 37
Откуда: Russia
вот такие пироги
правда надо добавить что стал сидеть с локал+свобода
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Sadrik Это не покозатель и вообще не относится к протоколу uTP, надо смотреть скорость а не сколько у тебя активных раздач или скачек!
Надо это проверить на Yote вот там думаю этот параметр поможет так как думаю что они режут трафик по TCP а этот протокол может обойти это, если кто-то попробует отпишитесь о результатах!
Neptun
Стаж: 15 лет
Сообщений: 130
Откуда: Мидгард
bt.transp_disposition было 255, поменял на 10 - отдача сразу выросла до максимума!
спасибо большое!
з.ы. еще пользуюсь BitTorrent 6.3, там опция bt.transp_disposition по умолчанию = 13, раздает также плохо как и Уторрент(
P_L_A_Y_B_O_Y ®
Стаж: 15 лет
Сообщений: 31
Откуда: Portal [PRO LiVe]
Neptun Тогда уж ставь 15 но не как не 10
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 20-Апр 18:16
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.
Update: Официальная документация на протокол: www.bittorrent.org/beps/bep_0029.html Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу. Поскольку торрент-клиент и так этим занимается — это не большая проблема. Дело в том, что посылаемые через TCP-«трубу» данные в процессе разбиваются на куски («пакеты»), каждый из которых отправляется независимо. При этом один пакет может идти одним маршрутом, другой — другим, последний кусок может прийти первым, первый — вообще по дороге потеряться. Поэтому каждый участник «трубы» (от операционной системы до маршрутизаторов) вынужден хранить у себя буфер, в который собирает отдельные пакеты, проверяя целостность и порядок, и требуя перепосылку если часть пакетов не дошла. При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика. Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах: 1 — разрешить инициировать исходящие TCP-соединения, 2 — разрешить инициировать исходящие uTP-соединения, 4 — разрешить принимать входящие TCP-соединения, 8 — разрешить принимать входящие uTP-соединения Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP. В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP — благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего. Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях. Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает. Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость. За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrentе начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже. Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально. Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее». Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше. С другой стороны, не всё сетевое железо — модемы, марштуризаторы — и не весь софт рассчитывался на такое количество UDP-трафика, поэтому у некоторых пользователей с ним возникают глюки. Например со скоростью — когда периодически она вдруг падает до нуля, потом снова восстанавливается, или плавает от нуля до максимума. Видимо где-то в сетевом окружении переполняется некий связанный с UDP буфер, чёрт знает. Опять же, на официальном форуме можно поискать про совместимость с разным софтом и железом в случае проблем. Другие «продвинутые» опции, на которые можно обратить внимание: bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80), net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно. net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше. peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120. Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: http://forum.utorrent.com/viewtopic.php?id=60602 По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает. Взято http://habrahabr.ru/blogs/p2p/68332/ |
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Не спешите включать эту опцию а если включена то лучше выключить её тобешь поставить параметр bt.transp_disposition 5 так как возможно из за этого новшества понизится скорость скачки и отдачи! Посмотреть клиентов с включеным uTP можно во вкладке пиры скорость скачки с них гораздо ниже у этих пиров присутствует флаг P это означает что скачка идёт по UDP протоколу
Последний раз редактировалось: P_L_A_Y_B_O_Y (2010-02-03 15:38), всего редактировалось 3 раз(а) |
|
|
Топик был перенесен из форума Общение в форум Вопросы по BitTorrent сети и ее клиентам
MadMaxx |
|
|
Sunchees
Стаж: 14 лет |
|
|
P_L_A_Y_B_O_Y +1 Еще давно заметил, что включив данную опцию скорость теряется довольно сильно, тем более, что почему-то utorrent подцепив пира по TCP переводит на uTP при любой возможности и скачивать становится проблематично. Поэтому - в обязательном порядке меняем параметр bt.transp_disposition на 5. Это касается как версий 1.8, так и тем более - версий 2.0.
|
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
По идеи должно работать быстрее по UDP т.к. служебных данных в нём меньше, но почемута не хочет, да и не к чему это нам в локале т.к. наш провайдер трафик не режет и поэтому обходить его нет смысла.
|
|
|
Sadrik
Стаж: 14 лет |
|
|
P_L_A_Y_B_O_Y Sunchees заменил на 5 : скорость отдачи с 1.0мБ/с поднялась до 1.1мБ/с (это в среднем, так как в реальности скорость прыгает)
возник еще вопрос: заметил, что иногда не запускается новая, только что выложенная раздача. ретрекер прописан, IP релизера вписан. Помогает пингование его хоста - раздача запускается после этого. Что это? глюки трекера? таблиц маршрутизации с которыми он работает? |
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Я думаю трабла всёже в трекере т.к. маршруты прописываются при подключении к сети и не меняются до следуещего переподключения!
|
|
|
Im Exclusivе
Стаж: 14 лет |
|
|
Как мне сделать так чтоб раздовалась одна, из трех раздач и с максимальной скростью...
Подскажите пожалуйста у меня клиент 1.8.5 |
|
|
Sunchees
Стаж: 14 лет |
|
|
P_L_A_Y_B_O_Y
Цитата: По идеи должно работать быстрее по UDP т.к. служебных данных в нём меньше, но почемута не хочет, да и не к чему это нам в локале т.к. наш провайдер трафик не режет и поэтому обходить его нет смысла. Цитата: заменил на 5 : скорость отдачи с 1.0мБ/с поднялась до 1.1мБ/с (это в среднем, так как в реальности скорость прыгает) Цитата: возник еще вопрос: заметил, что иногда не запускается новая, только что выложенная раздача. ретрекер прописан, IP релизера вписан. Помогает пингование его хоста - раздача запускается после этого. Что это? глюки трекера? таблиц маршрутизации с которыми он работает? Цитата: Как мне сделать так чтоб раздовалась одна, из трех раздач и с максимальной скростью... Подскажите пожалуйста у меня клиент 1.8.5 |
|
|
Trand
Стаж: 14 лет |
|
|
полезная штука
|
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Serega1991 Полезная но только не для сети Уфанет!
|
|
|
Sadrik
Стаж: 14 лет |
|
|
вот такие пироги
|
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Sadrik Это не покозатель и вообще не относится к протоколу uTP, надо смотреть скорость а не сколько у тебя активных раздач или скачек!
Надо это проверить на Yote вот там думаю этот параметр поможет так как думаю что они режут трафик по TCP а этот протокол может обойти это, если кто-то попробует отпишитесь о результатах! |
|
|
Neptun
Стаж: 15 лет |
|
|
bt.transp_disposition было 255, поменял на 10 - отдача сразу выросла до максимума!
спасибо большое! з.ы. еще пользуюсь BitTorrent 6.3, там опция bt.transp_disposition по умолчанию = 13, раздает также плохо как и Уторрент( |
|
|
P_L_A_Y_B_O_Y ®
Стаж: 15 лет |
|
|
Neptun Тогда уж ставь 15 но не как не 10
|
|
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 20-Апр 18:16
Часовой пояс: UTC + 5