Архив-2: qBittorrent на Windows [4162937]

Я видел как кто-то жаловался на uTP в libtorrent, и не один раз, сейчас не могу найти. Там пользователь сравнивал с uTP в uTorrent. Надо будет ещё в нём потестить и найти те комменты пользователя, там тоже была интересная инфа.

Poor uTP performance #3542

Биомеханик, да, вроде бы оно. И да, пользователь это Seeker2.

Решил все же потестить 1.2. А вот это у меня не подтверждается. С кэшем даже наоборот медленнее.

Сдается мне все же у тебя с дисками что-то не то, либо таки виндовое окружение гадит

---

Вот еще до кучи результаты с 2.0. Относительно 1 версии печальные, хоть и более чем достаточные для гигабита конечно.
На скриншотах MMAP и POSIX соответственно.

Особенно радует "стабильность" графиков

Такие результаты можно получить в пределах одного SSD, и все равно с кэшем лучше, вряд ли это SSD или система влияют (SSD с DRAM кэшем). Мне не удалось сравнять скорость с кэшем и без, сразу видно, где на графике без кэша.

ps. в клиентах одинаковые настройки, то бишь кэш отключается в обоих клиентах.

У меня на принимающей стороне рамдиск использовался, чтобы точно не портить результаты скоростью записи. Так как мы здесь сидирование тестируем.

Я их больше никогда юзать не буду)

Вот еще чтение с внешнего HDD потестил. Скрины 0 и 512 кэша соответственно.

Тут как ни странно разницы нет вообще никакой можно сказать, вопреки моему ожиданию.
Возможно HDD просядет без кэша в ситуации когда одновременно раздается сразу много раздач. Но такой сценарий сложно протестить искусственно.

---

Ну в линуксах это сводится просто к закачке в /tmp, так как она почти везде в оперативу смонтирована по дефолту.

Что вы имеете в виду под "просядет"?

Упадет скорость из-за большой очереди запросов. По идее график будет напоминать пилу из-за задержек в чтении. Вопрос - помогает ли кэш клиента сгладить ситуацию.

Hanabishi, помогает, я как нибудь на сервере с популярной раздачей проведу тест, при скорости 100МБ/с отключу кэш.

С чего бы ей упасть? HDD как отдавал на максимуме своих возможностей, так и будет отдавать.

GCRaistlin, с HDD можно легко раздавать на скорости 100МБ/с, но небольшому количеству пиров.

Почитайте о принципах работы HDD и почему им нужна дефрагментация. И в чем их отличие от SSD, которым дефрагментация не нужна.

Спасибо, я в курсе их. 25 лет на этом специализируюсь.
Задайтесь вопросом: что обеспечивает кеш чтения?

Тогда вроде и вопросов быть не должно. Больше пиров качает разные файлы => больше времени тратится на позиционирование головок => ниже скорость.
Тут есть люди, у которых и 1000 пиров одновременно бывает. На таких сценариях уже даже SSD (нижнего ценового сегмента) начинают упираться в IOPS. Мы этим как раз и занимаемся.

А если пиры качают один и тот же файл размером в десятки гигабайт, времени на позиционирование головок тратится меньше?

GCRaistlin, столько же, усугубит ситуацию сильная фрагментация файла.

stаlkerok
Фрагментация - это, конечно, плохо. Но как тут поможет кеш чтения?

Нет. Подразумевалось "разные места на диске". Разные это файлы или части одного большого, при условии случайного доступа, особо значения не имеет.
Опять же, раз на этом специализируетесь, то должны знать, что на уровне диска нет никаких файлов, а есть только сектора (блоки) данных. В этом как раз весь вопрос. Как минимум кэш дает вероятность, что если разные пиры захотят один и тот же блок, его не придется читать с диска снова. Собственно в кубите в окошке статистики есть процент попаданий в кэш чтения.
С другой стороны, кэш ОС тоже без дела не сидит и держит в памяти все прочитанное насколько это возможно. Поэтому в принципе я и ставлю полезность клиентского кэша под вопрос.
Плюс еще есть такая интересная опция как "Отправлять предложения частей отдачи". С ней клиент пытается предлагать пирам скачать имеющиеся в кэше части вместо рандомного выбора. И вот это уже без клиентского кэша не реализовать.
И еще libtorrent 1.2 читает данные на упреждение. Хотя он это делает даже если кэш отключен, так как у него буфер чтения и кэш частей это две отдельные вещи. При чем в буфер попадания тоже могут быть.
Отсутствие буфера кстати тоже один из бичей libtorrent 2.0, отчего его производительность заметно хуже даже на SSD, что показано в тестах выше.

---

stаlkerok, кстати, может у нас еще разные результаты из-за размеров буфера?
У меня стоит
Send buffer watermark: 1024 KiB
Send buffer low watermark: 128 KiB
Send buffer watermark factor: 100%

Доступ, с точки зрения диска/ОС, как раз случайный. И "места на диске" будут все время разные. Эта вероятность при эффективном алгоритме файлообмена стремится к нулю. Не удивлюсь, если пиры посылают клиента с такими предложениями куда подальше. Допустим, это так (я не знаю). Но это бессмысленно: клиент не знает, какой следующий кусок у него попросят. По размышлении я пришел к выводу, что не особо. Это при линейном чтении критично.

Можно и линейно читать. Просто торрент-клиенты как правило так не делают (если не стоит опция "загружать последовательно"). Нет, вероятность есть и неплохая. Вкладка статистики в помощь опять же, можно и у народа поспрашивать. Обычно в переделах 20-30% колеблется. Некоторые и 50% показывали. Но тут опять же от количества, размера, популярности раздач зависит итд. Сложно проверить. Вроде как в клиентах нет опции типа "отказываться от предлагаемых частей". Но в том же uTorrent-е например код закрыт и что он там делает сказать наверняка нельзя. Это упреждающее чтение в рамках одной части. Если размер части в торренте например 1 МБ, пиры не могут попросить только кусок от нее, часть всегда будет выкачана целиком. Чтение в торренте не супер рандомно. Части в торрентах как правило измеряются мегабайтами и в рамках такой части чтение идет линейно. А фрагментация может файлы размазать хоть по 1 кластеру (то есть по 4 КБ в общем случае).
Плюс чем ближе части располагаются на диске, тем быстрее позиционирование. Это тоже влияет и потому дефрагментация нужна.

И это еще я qB использую только для вытягивания сложных раздач - что иногда как раз предполагает многократную отдачу одного и того же (нет полного сида => куча народу хочет одних и тех же кусков).
Покажите, пож., вашу. Это где? Предположу (опять-таки не знаю), что BitTorrent реализован наоборот: клиент сообщает, что есть в наличии, и отдает то, что попросили. Может, опционально фича "возьмите лучше это" и реализована, но право выбора куска должно оставаться за личером. Какое же это упреждающее чтение? Это просто чтение. Чтение кусков - рандомно. Теоретически да, но это сферический конь в вакууме.
Ближайший реальный сценарий - использование NTFS-сжатия. Я одно время этим баловался: на 2 TB позволяет выиграть 10-20 GB. Но взамен получаем тормоза даже при просмотре фильмов. Как только я осознал их причину, баловаться перестал. Только в отдельных сценариях, например при раздаче BDRemux.
Если раздача состоит из нескольких файлов, то никакой дефрагментацией вы их лечь рядышком не заставите, а значит, головки могут гоняться туда-сюда, даже если она состоит из совершенно нефрагментированных файлов.

Не могу, у меня клиент с libtorrent 2.0. А даже когда пользовался 1.2, кэш в клиенте отключал. При добавлении торрента галка. Или ПКМ по существующему торренту, там она тоже есть. Это уже бесполезный спор о терминах. Там размер буфера расчитывается из текущей скорости пира и данные читаются на некоторое время вперед. Как это называть не суть важно. Только куски эти здоровые в несколько мегабайт, что уже вполне можно относить в разряд линейного чтения. Тру рандом это чтение по 4 КБ.
Хаос начинается когда нужно несколько частей параллельно читать, вот тогда да, начинаются скачки головки туда-сюда. Так мы про общую теорию и разговариваем. Надо или не надо проводить дефрагментацию можно смотреть по факту.
Собственно в винде например автоматическая дефрагментация на определенном пороге фрагментации запускается. Опять же мы общий случай обсуждаем. Если такие сценарии есть, то значит их нужно учитывать. Кстати есть утилиты, которые позволяют это сделать.

Не вижу. Клиент не способен ни принять, ни отдать данные размером меньше куска. У него его попросили - он его считывает. Что тут упреждающего? Линейное чтение характеризуется условным отсутствием затрат времени на позиционирование голов. Когда вы после чтения каждых нескольких МБ перепозиционируете головы, это уже никакое не линейное чтение: затраты времени на позиционирование будут относительно велики. Можно априори утверждать, что если не используется NTFS-сжатие, то фрагментация никогда не достигнет чувствительных для раздач торрентов значений. Например? Есть в том смысле, что разница в этом сценарии при раздаче фрагментированного/нефрагментированного файла есть хотя бы формальная и рационально обоснованная. По факту, естественно, гораздо важнее (затратнее по времени) сам факт движения голов, чем расстояние, на которое они движутся. А при других сценариях и этого нет.

я думаю в разрезе линуксов-докеров, и вот что выходит: hdd(кэш 512мб) -> ОС Линукс (просто юзает всю память что не занята под Кэш Диска) -> Докер (тот же ОС Линукс, так же юзает свою всю память под кэш Диска что выделила ему ОС-мать) -> Кэш в Кубите.
Не много ли кэшей по пути к диску? ) Стойкое ощущение, что где-то идет задвоение, затроение, а может даже зачетверение информации! )
не знаю, как в Винде. Но наблюдая за тем, как ОС и Докер заполняют остатки памяти кэшем под "что-то свое", ну наверняка это дисковый ввод-вывод, т.к. больше в эксперименте-наблюдении у меня нету процессов, кроме кубита - невольно думаешь, дак может имеет смысл и отключить кэш в Кубите.

Может версия клиента древняя? В текущей так
Да, это называется буферизованное чтение, а не упреждающее. По ночам голова не всегда варит. Вот именно. Но кто определяет границу? Затраты "относительно велики" довольно размытая величина. Какой объем тогда можно считать за линейное? 100 МБ - линейное? 1 ГБ - линейное?
Или может линейное это только когда читаешь диск целиком от начала до конца без единого перепозиционирования? NTFS не единственная фс в природе. Да и заниматься предсказыванием таких вещей я бы не стал, здесь лучше всегда предполагать наихудший сценарий, по моему мнению. Дерагментатор от Auslogics вроде такое когда-то мог, емнип. Какие-то другие может тоже. Во времена хардов такие функции были популярны, например важные и системные файлы сдвигались в начало диска, так как там быстрая зона.
Сейчас уже не помню точно, давно не пользуюсь ни хардами (как активным хранилищем), ни виндой. Это да, не спорю. Упомянуто было как дополнительный фактор.

---

Такого не должно быть вроде как. Докер это не виртуалка, он крутится на том же ядре. У них VFS кэш один общий по идее должен быть, без дублирования.
Но прямо сейчас не возьмусь утверждать. Кэш ОС + кэш клиента это точно задвоение. Опять же почему я его считаю не особо полезным. Результаты моих тестов есть выше.
Но у stаlkerok вон результаты без кэша плохие, так что лучше проводить собственные тесты. Так же. ОС кэшит файлы по максимуму, насколько есть свободной памяти.

в докере выглядит как, убрал кэш кубиту, он жрет 43 Мб ОЗУ, а в докере лимит 1 Гб сделал. И вот при запуске докер показывает что постепенно память сжирается системой докера до 1Гб, а кубит в процессах все еще на 43Мб. В этом докере естественно сидит кубит как самый жирный гусь.
Ну я так и оставил, и еще сделал only TCP, на роутере тоже оставил проброс только TCP.
Т.к. все это на SSD, в целом мне главное чтобы ЦПУ не жрало и память особо.
В итоге с такой конфой пока оставлю кубит работать, раздача легко все 500Мб канал забивает. Больше мне и не надо. Теперь главное, чтобы было стабильно. А, ну и да - по температуре ССД на 38 градусах, это косвенное мое наблюдение, как часто оно без кэша туда ходит. Если б ССД стал нагреваться побольше, значит нагрузка на него пошла больше. А так-то все тихо и спокойно, что с кэшем, что без (я про кубитный если что).
Продолжаем наблюдать, но похоже это последние мои потуги с настройкой кубита и переезда с трансмиссии ) надеюсь.

А родительская ось что показывает? Эта память считается как использованная (колонка used в команде free -wh)?
Если не идет в использованную, то может лучше вообще ограничение снять. Пусть кэшит на всю доступную оперативу.

wincontig (при явном указании зоны диска, где должен находиться каталог)