Вышла первая бета-версия bittorrent-клиента Transmission - 2.30b1 (http://www.transmissionbt.com/). Transmission - это относительно легкий и не требовательный к ресурсам torrent-клиент, написанный на языке Cи и поддерживающий разнообразные интерфейсы пользователя: GTK, Qt, native Mac, Web-интерфейс, daemon, command-line.
В новой версии было реализовано довольно много изменений по сравнению с версиями семейства 2.20. Заинтересованным лицам предлагается протестировать данную версию чтобы избежать попадания возможных ошибок в релиз.
Наиболее заметные изменения в этой версии:
- Все платформы:
- Поддержка протокола µTP (реализовано через официальную библиотеку libutp)
- Поддержка UDP трекеров.
- Поддержка Multiscrape.
- Самые редкие части торрента теперь по возможности скачиваются раньше всех остальных.
- Функциональность "lazy bitfield" была заменена на более новое расширение протокола "Fast Extension" (BEP6).
- Скриптам теперь передаются переменные окруж...URL: http://www.transmissionbt.com/
Новость: http://www.opennet.me/opennews/art.shtml?num=30111
> Добавлен значок 256 x 256 пикселейЭто самое главное.
+1 :), а зачем такой большой, где он появляется?
ну может у кого-то ярлыки на пол-экрана)
> ну может у кого-то ярлыки на пол-экрана)Бывают еще экраны с высоким DPI, где какойнить 32x32 под микроскопом разглядывать разве что :). Как значок для более-менее крупного ярлыка в который можно допустим пальцем ткнуть - вполне нормально. Собссно много не мало. Downscale картинки сделать всегда можно, а вот наоборот...
>> ну может у кого-то ярлыки на пол-экрана)
> Бывают еще экраны с высоким DPI, где какойнить 32x32 под микроскопом разглядывать разве что :).Так есть же SVG — векторный формат, одинаково хорошо растрируется на любое разрешение, хоть под 50 dpi, хоть под 150 dpi. А эти лепят значки, что называется, с запасом. :))
> Так есть же SVG — векторный формат, одинаково хорошо растрируется на любое разрешениеУгу, только проц раком встает на рендеринг в нормальном качестве на приличное время - чудес не бывает. Зарендерить картинку - сложнее чем тупо распаковать ее. Кэп намекает: экраны с высоким DPI часто бывают у всяких там мобильных девайсов, зачастую не страдающих избытком мощности CPU, зато страдающих батарейным вопросом.
svg рендерится моментально, кроме того можно кэширование приделать.
На мобильных устройствах даже флеш нынче обычное дело, и всякие анимированные банеры на сайтах показываются.
>> Так есть же SVG — векторный формат, одинаково хорошо растрируется на любое разрешение
> Угу, только проц раком встает на рендеринг в нормальном качестве на приличное
> время - чудес не бывает. Зарендерить картинку - сложнее чем тупо распаковать ее.То есть тебе легче держать в ресурсах десяток PNG-картинок (8x8, 12x12, 16x16,..., 256x256) одного и того же изображения под различные разрешения, чем воспользоваться средствами динамического рендеринга (частично аппаратно-ускоренного) векторного представления в растр? Ну, я даже не знаю, что сказать. На телефонах в Java ME уже можно использовать интерфейсы на основе SVG (JSR 226 SVG API, не говоря про десктопы — там векторный Nimbus L&F рисуется с 2009 года), и они не тормозят, в отличие от C/C++ поделок, выжирающих полосу пропускания дочиста. :))
Если зайти на сайт transmission в раздел download: http://www.transmissionbt.com/download/ то внизу можно увидеть кучу систем куда он встроен. Не думаю что они умеют SVG.
А большие значки там как раз в тему, потому что там весь интерфейс из рабочего стола состоит и значков программ на нем.
Как вариант - поставить как аватарку.
> а зачем такой большой, где он появляется?GNOME'овский загон, наверное, готовят 3.x к (свех)новому поколению мониторов
для желающих потестировать:
sudo apt-add-repository ppa:transmissionbt/beta
Это для дебиана работает?
Нет, это только в убунте и производных.
Кстати, для 10.10 в этом PPA пакетов нет, только для 10.04 и будущей 11.04.
к дебиан sid большинство убунтовских ppa репов цепляется без проблем.
добавляешь sources.list что-то наподобие этого,deb http://ppa.launchpad.net/transmissionbt/beta/ubuntu/ lucid main
пользоваться им невозможно, если торрентов больше 20. Уже давно перешел на qbittorent он тоже не без проблем, но там можно хоть назначить торрентам метки. да и сериалы им удобней качать, есть функция скачивания по порядку.
Сейчас 71 торент. Доходило до 180. Проблем нет.
как ты в них ориентируешься?
а зачем в них ориентироваться?
> а зачем в них ориентироваться?Вот поэтому так и не могу бросить uT через wine. Аплоад-канал худой, вот и нужна гибкая система приоритетов.
Там фильтр есть, например.
+ всякие сортировки по возрасту/оставшемуся времени/рейтингу. Но от категорий или тегов я бы не отказался, тем более что реализуется это элементарно
У меня ровно 100 торрентов на данный момент.
Никаких проблем.
Transmission 2.13, торрентов 210, старт затяжной ~10-20 сек, при добавлении новых .torrent делает вид что вешается - по времени пропорционально количеству ранее добавленных.
Заключение: пользоваться можно, если использовать эту программу как качалку, а не писькомерку
> при добавлении новых .torrent делает вид что вешается -Преаллокация места на диске, имхо. К сожалению пока не асинхронная, ну вот и ...
> по времени пропорционально количеству ранее добавленных.
По идее преаллокация по времени пропорциональна размеру файлов торента oO. Кстати преаллокация настраивается - если не ошибаюсь, есть 3 режима: никакой, быстрая, полная.
> пользоваться им невозможно, если торрентов больше 20.Uh-oh, как же я им тогда пользуюсь с ~200 торрентами? oO
Что до qbittorrent - он привязан к куте и потому почти не пригоден для headless режима (например на сервере или мелкой девайсине столько говна вдувать - извините). Во вторых, если вдруг захочется самому пересобрать самую-самую версию - libtorrent во многих системах имеет свойство быть устаревшим, а собирать актуальную версию весьма геморройно т.к. зависимостей масса. Ну и сам qbittorrent собирать достаточно геморно. В общем, это для тех кто перся от мюторента а что-то сверх того не хотел. Из плюсов оного - вполне адекватный автор, не забивающий на баги и здрвавые хотелки.
> пользоваться им невозможно, если торрентов больше 20. Уже давно перешел на qbittorent он тоже не без проблем,Руки?
У меня на NAS (QNap) порою крутится 200-300+. И ничего.
> Уже давно перешел на qbittorentКлючевое слово ДАВНО =)
У самого сейчас Transmission 2.22 со стоящими на раздаче 55 торентами, одновременно активных торентов больше 15 не бывает... в общем выходит 3% занятого CPU и 1.8% занятой RAM. Чего вы там нашли невозможного мне не понятно. Скачивание происходит со скоростью моей безлимитки.
Очереди закачек? Опять нет?
Напишите громкое требование в тикет https://trac.transmissionbt.com/ticket/671.
Пользуйтесь скриптами.
Ставьте МакОсь.Вот какой большой выбор.
Интересно, когда до любителей очередей допрет, что в багтрекер срать коментами - в 100500 раз эффективнее? Если разработчики увидят что фичу желает орава народа - они ее постепенно сделают, куда ж они денутся? Никто не хочет постоянно баги от юзеров разгребать :))). А там вдруг фигакс и последняя активность - 5 месяцев назад. Знаете, если фича кому-то нужна раз в полгода - может и фиг с ней, с этой фичой то? :)
Отличный битторент клиент, никогда с ним проблем не возникало
> Отличный битторент клиент, никогда с ним проблем не возникало1) Скачайте 5-10ГБ торрент.
2) Запустите его верификацию ("Проверить локальные данные").
3) Сразу, как только началась проверка, попробуйте запустить какое-нибудь приложение.
4) Что наблюдаете, рассказываете.
>> Отличный битторент клиент, никогда с ним проблем не возникало
> 1) Скачайте 5-10ГБ торрент.Скачал 20Гб торрент (lossless версия Elephant Dreams для тестов сжатия разных кодеков). Пойдет? :)
> 2) Запустите его верификацию ("Проверить локальные данные").
Запустил. Верифицируется себе. Клиент продолжает работать - это у них все-таки сделали асинхронным :)
> 3) Сразу, как только началась проверка, попробуйте запустить какое-нибудь приложение.
Запустил. И?
> 4) Что наблюдаете, рассказываете.Наблюдаю запустившийся SMplayer и трансмиссию которая верифицирует торент. Что-то не так?
Если ты хотел сказать что у тебя приложение медленно стартует - ну так это, надеюсь у тебя хватило ума вынести торенты на отдельный диск? Иначе система, читая файлы приложения и библ, делит доступный бандвиз диска с торентом, который начитывает во всю. Да еще и головы гоняет туда-сюда, разрываясь между верификацией торента и чтением файлов приложения (если это не SSD, SSD такое более-менее пофигу, а вот механика сильно проседает на параллельных запросах, особенно всякие низкооборотистые диски, например ноутбучные). Ессно скорость старта приложений упадет, может быть довольно существенно. С таким же успехом можешь просто читать/писать/копировать свой слитый торентом ...цатигиговый файл файлменеджером или скриптом, например. Думаешь, будет сильно лучше? Агащаз. Трансмиссия вообще ничего такого особого не делает. Она тупо читает файл с диска и считает хеш (а что еще можно сделать то? :D). Оно ничем принципиально не отличается от того что остальные программы делают с файлами. Ну разве что читает довольно быстро (на моей системе верификация идет со скоростью ~65Мб/sec). Но файлманагер при копировании еще быстрее.
Хинт: в идеале, в нормальной многозадачной системе, с вменяемыми планировщиками CPU и IO и более-менее честной многозадачностью user-mode программа не должна быть способна вызвать крупные проблемы у операционки и остальных программ вообще. Если это не так - лечить надо систему/конфигурацию. Ну а то что ты такой use case привел - намекает на то что ты причкадятел и не в состоянии отличить проблемы операционки от проблем программ. Я бы понял наезд на блокирующую преаллокацию или move торента :). Но верификация асинхронная, в этом плане к трансмиссионщикам не придерешься, они в этом месте не халтурили - к своей операционке, конфигурации железа и рукам придирайся.
>> 4) Что наблюдаете, рассказываете.
> Наблюдаю запустившийся SMplayer и трансмиссию которая верифицирует торент. Что-то не так?
> Если ты хотел сказать что у тебя приложение медленно стартует - ну
> так это, надеюсь у тебя хватило ума вынести торенты на отдельный
> диск? Иначе система, читая файлы приложения и библ, делит доступный бандвиз
> диска с торентом, который начитывает во всю.Нет, не хватило. Представь, что у "обчного пользователя" ноутбук. (Ноутбуки сейчас по статистике составляют 50% парка от всех персоналок и продолжают вытеснять десктопы). И?
> Хинт: в идеале, в нормальной многозадачной системе, с вменяемыми планировщиками CPU и
> IO и более-менее честной многозадачностью user-mode программа не должна быть способна
> вызвать крупные проблемы у операционки и остальных программ вообще. Если это
> не так - лечить надо систему/конфигурацию.
> Ну а то что ты такой use case привел - намекает на то что ты причкадятел
> и не в состоянии отличить проблемы операционки от проблем программ.Я привёл use case для типичной конфигурации домашнего компьютера с одним винчестером и ноутбука.
> Я бы понял наезд на блокирующую преаллокацию или move торента :). Но верификация асинхронная,
И что? Какой смысл ты вложил в слово "асинхронная", если на САМОМ_ДЕЛЕ запуск любой программы во время выполнения верификации сопряжён с заметной задержкой в лучшем случае на полминуты, в худшем — до конца проверки торрента. Кстати, тут говорят, что это только Gtk-версия Transmission на такое способна, почему так?
А что какой-то другой торрент клиент меньше грузит диск?
Имхо, этот можно хотя бы вынести на отдельную машину и управлять через веб-интерфейс.
> Нет, не хватило. Представь, что у "обчного пользователя" ноутбук. (Ноутбуки сейчас по
> статистике составляют 50% парка от всех персоналок и продолжают вытеснять десктопы).
> И?Это что-то типа "я надеялся, что мои неудачи вызваны глобальными проблемами, а не моей локальной ситуацией". Впредь будьте конкретнее. У обычного пользователя, кстати, ноутбук + раздавалка торрентов и вайфая в прихожей/на антресолях, опять-таки вашей проблемы нет, если уж на то пошло.
У обычного пользователя-не-админа? Oo
У 50%% школьников, затрудняюсь уточнить с какого класса. Другие 50%% тоже смогли бы настроить, при помощи одноклассника в аське, да РОДАКИ ЗАЖАЛИ БАБКИ!
> У 50%% школьников, затрудняюсь уточнить с какого класса. Другие 50%% тоже смогли
> бы настроить, при помощи одноклассника в аське, да РОДАКИ ЗАЖАЛИ БАБКИ!дополню - причём аська была б запущена под андроидом, самой свежей прошивки от тех же одноклассников с нескучными обоями. 2011 год на дворе, парни.
> Нет, не хватило. Представь, что у "обчного пользователя" ноутбук. (Ноутбуки сейчас по
> статистике составляют 50% парка от всех персоналок и продолжают вытеснять десктопы).
> И?Представил. У ноутбука тормозной диск. Один. Как правило 2.5" и не более 5400RPM. На последовательное чтение может выжать мегов 50-60 в секунду. При множественных параллельных запросах - полнейший обсирон (скорость падает до нескольких мб/сек). Не является ноут крутым сервером, да. И имеет свои ограничения. Сюрприз?
Как лечить?
1) Попробовать уменьшить фрагментацию в надежде что головы будут меньше елозить и больше - читать данные, так что скорость подрастет. Отдефрагать ФС (if possible). Юзать полную преаллокацию, чтобы доступ к файлу был более последовательным. Юзать ФС стойкую к фрагментации, типа XFS, который упирается рогами и копытами по части фрагментации и хорошо работает с большими файлами.
2) Можно попробовать разные планировщики I/O и тюнинг параметров. Насколько оно там в бсде катит - да хз. Это тебе и прочим бсдунам виднее. Тем не менее, наивно ожидать что 8088 путем выбора шедулера вдруг резко станет "крутейшим пентиумом", то же самое относится и к ноутбучному диску. Ну не бывать ему крутым сервером вытягивающим массовый параллельный доступ на культурной скорости, извини :)
3) Поставить SSD, наконец. Круто. Дорого. И у него нет голов. Гонять нечего. Поэтому seek в разные стороны его мало смущает. Кардинально и проблема отвалится как класс. Как минимум, ос сможет более-менее вменяемо его шедулить и если шедулер не полное дерьмо, тормозов станет намного меньше. В случае механики проблема в том что заранее вообще толком неизвестно насколько там винт заткнется при выполнении запроса. Проблема только в том что пока еще емкие и быстрые SSD стоят совершенно дико для обычного хомяка с ноутом :).Но через несколько лет и ноут запросто станет крутейшим серваком если SSD поюзать :))
4) Мля. Можно вынести скачку торентов на отдельный внешний девайс :))). От юсб-диска до самостоятельной качалки в роутере, NAS или где там блин еще :). Решает проблему на корню - тормозить если кто и будет, то не диск с системой и значит не система :)> Я привёл use case для типичной конфигурации домашнего компьютера с одним винчестером
> и ноутбука.Чувак, ты положил хилый ноутбучный винт (5400RPM?) параллельными запросами. С которыми он справляется из рук вон плохо (seek у него медленный чтопипецъ). И поимел то что должен был поиметь. Что тебе не нравится? Возьми файлманагер, начни копировать 10-гиговый файл того же торента по системному разделу без всякой трансмиссии. И попробуй запустить программу. Что, запуск программ притормозился? Так это потому что винч разрывается между чтением файлов программы и ее либ и параллельным выполнением попрошенного тобой копирования файлов. Ноутбучный диск на этом сливается на раз :). При том сомнительно что даже самый лучший шедулер много выжмет. Если пытаться что-то улучшить - надо постараться сделать чтение более-менее последовательным, но в упомянутой ситуации это не так то просто. SSD тебе в руки с таким use case :). Или отдельный диск под торенты, если жаба протестует.
>> Я бы понял наезд на блокирующую преаллокацию или move торента :). Но верификация асинхронная,
> И что? Какой смысл ты вложил в слово "асинхронная", если на САМОМ_ДЕЛЕ
> запуск любой программы во время выполнения верификации сопряжён с заметной задержкой
> в лучшем случае на полминуты,Программа делает вполне валидную для программы операцию - читает данные с диска. Довольно быстро. И даже более-менее последовательно (если преаллокация юзалась). Файлманагер читает их еще быстрее (хешировать не надо и потому даже теоретически оно в проц не упрется). Давай теперь еще и все файлманагеры обругаем? А то что торент чаще ворочает ...цатигиговые чушки чем файлманагер и потому попал под твое наивное внимание - кто ж виноват? Я вижу лишь 1 случай когда диску может полегчать: тормозной торент-клиент, который настолько медленно считает хэш, что даже ноутбучный диск успевает отдохнуть немного :). Но это похоже на выигрыш соревнования путем укорачивания ног "вражеского" бегуна чтобы он медленнее бегал в случае когда по другому выиграть не получается :)
> в худшем — до конца проверки торрента.
Настолько засран обмен с диском + планировщик жидко сдристывает, позволяя одной программе узурпировать диск?
> Кстати, тут говорят, что это только Gtk-версия Transmission на такое
> способна, почему так?Не знаю что там говорят, но я могу создать и ощутимые тормоза в T с вембордой, если это зачем-то надо :)). С учетом асинхронности данной операции могу сказать что гуй у T не клинит, поэтому даже списать на внутренние заморочки гнома или графической подсистемы сложно. Я думаю что просто тормозит диск, меееееееедленно читая файло запускаемой программы и всякие там библы. Когда торент перестает верифицироваться - процесс чтения остальных файлов ессно намного ускоряется, т.к. доступ уже куда менее параллельный и диск менее озадачен.
Есть торрент 7ГБ.
transmission-gtk как обычно подвесило всё загрузив процессор на 100%. Давно от этой версии отказался из-за постоянных подобных проблем, хоть и использую Gnome.
transmission-qt совершенно не напрягаясь отработало проверку торрента.
> transmission-gtk как обычно подвесило всё загрузив процессор на 100%.
> transmission-qt совершенно не напрягаясь отработало проверку торрента.Это всего лишь "морды". Не они "Нагружают" процессор.
Тем не менее, в моем окружении, воспроизводится только с gtk мордой. Ни с qt мордой, ни демоном тормоза не воспроизвелись.
Отказался от gtk морды когда оказалось, что от числа торрентов в открытом окне росла загрузка процессора.
Поставлю после обеда себе эту бету и если воспроизведется полезу с этим в их багзиллу. Давно собираюсь...
> Отказался от gtk морды когда оказалось, что от числа торрентов в открытом
> окне росла загрузка процессора.Может какой-то баг в гноме? Я у себя не вижу особых тормозов с 200 торрентами. Еще может вы в GTKшной морде врубили что-то типа сортировки по активности, которая постоянно пересортировывает большой список?
Кажется нашел косяк. Вешается gtk морда на некорректных черных списках. Тикет 4168.
А в итоге проблема подвисания из-за видеодрайвера от nVidia.
> Кажется нашел косяк. Вешается gtk морда на некорректных черных списках. Тикет 4168.Так держать! Правда, увы, ваш тикет закрыли как неправильный - там после анализа бектрейса было высказано мнение что поблагодарить вам следует нвидию и руки судя по бэктрейсу. Неожиданная развязка :). Однако попытка хорошая.
http://www.nvnews.net/vbulletin/showpost.php?p=2412480&postc...
Руки благодарили товарищу, который сумел (благодаря ручкам) воспроизвести баг и на nouveau :)
>transmission-gtk как обычно подвесило всё загрузив процессор на 100% использую Gnome.transmission-gtk + fluxbox на 4-х ядерном проце и подобной проблемы не возникало. transmission-qt не проверял, а вот qbittorent лажал...
>>transmission-gtk как обычно подвесило всё загрузив процессор на 100% использую Gnome.
> transmission-gtk + fluxbox на 4-х ядерном проце и подобной проблемы не возникало.Вопрос к вам обоим: напишите, пожалуйста, используемую аппаратную конфигурацию: названия CPU, тип и частоту памяти, чипсет.
>>>transmission-gtk как обычно подвесило всё загрузив процессор на 100% использую Gnome.
>> transmission-gtk + fluxbox на 4-х ядерном проце и подобной проблемы не возникало.
> Вопрос к вам обоим: напишите, пожалуйста, используемую аппаратную конфигурацию: названия
> CPU, тип и частоту памяти, чипсет.ололо, а тебе на кажется что тут больше дело в версиях библиотек, настройках ядра и планировщика IO?
>>>>transmission-gtk как обычно подвесило всё загрузив процессор на 100% использую Gnome.
>>> transmission-gtk + fluxbox на 4-х ядерном проце и подобной проблемы не возникало.
>> Вопрос к вам обоим: напишите, пожалуйста, используемую аппаратную конфигурацию: названия
>> CPU, тип и частоту памяти, чипсет.
> ололо, а тебе на кажется что тут больше дело в версиях библиотек, настройках ядра и планировщика IO?Ололо, нет, не кажется. Я предполагаю, что лаги связаны с интегрированным в многоядерный CPU контроллёром RAM. Причём неважно, AMD это или Intel. Такая шняга наблюдается у обоих на разных операционках.
> Ололо, нет, не кажется. Я предполагаю, что лаги связаны с интегрированным в
> многоядерный CPU контроллёром RAM.Откуда вы настолько идиотские гипотезы берете? В трансмиссии нечему нагрузить контроллер памяти настолько чтобы появились какие-то лаги.
12309 в FreeBSD? ;)
> 1) Скачайте 5-10ГБ торрент.
> 2) Запустите его верификацию ("Проверить локальные данные").
> 3) Сразу, как только началась проверка, попробуйте запустить какое-нибудь приложение.
> 4) Что наблюдаете, рассказываете.недавно на одном из домашних компьютеров перешёл с deluge на transmission -- добавил 100+ торрент файлов(около 300гб файлов на диске, жёсткий диск один) в transmission и соответственно эти файлы скачанные старым клиентом верифицировались. верифицировалось долго, но особых проблем с производительностью не заметил. и не думаю что будет существенная разница если вместо transmission взять какой-нибудь qtorrent.
> недавно на одном из домашних компьютеров перешёл с deluge на transmission --
> добавил 100+ торрент файлов(около 300гб файлов на диске, жёсткий диск один)
> в transmission и соответственно эти файлы скачанные старым клиентом верифицировались.
> верифицировалось долго, но особых проблем с производительностью не заметил.Средний размер файлов ~3ГБ, а если считать не по среднему, а фактически, то 30МБ-1ГБ на файл. К тому же, Transmission верифицирует файлы, нуждающиеся в проверке, не все сразу, а по-одному (в очереди на проверку). Поэтому описанный твой случай не подпадает под заявленный use case.
когда уже добавят упорядочное скачивание, чтобы можно было сразу смотреть
Это же ломает логику максимальной децентрализованной отдачи. Так получится, что все тянут начало с одного, вместо того чтобы тянуть разные участки и потом их же раздавать. От этого наоборот нужно держаться подальше, иначе скорость закачки упадет.А вто это
> Самые редкие части торрента теперь по возможности скачиваются раньше всех остальных.
логично.
> логично.Не то слово :). Торрент-клиенты в режиме личера в общем случае занимаются бартером по принципу "ты мне - я тебе", откровенно предпочитая аплоадить тем кто им что-то льет взамен. Скачка самой редкой части приводит к возможности залить ее максимальному числу желающих, получая от них в результате возможность скачки взамен. Такой подход позволяет ускорить "вступление в игру" сделав старт закачки более эффективным. Потому что если скачать часть которая у всех и так есть - личерам она не нужна, аплоад не состоится, бартер не получится и соответственно дальнейший прогресс закачки может быть только за счет сидеров и optimistic unchoke, а в итоге получится наихучшая скорость закачки из всех возможных, как для тех кто ничего не хочет аплоадить.
>> Самые редкие части торрента теперь по возможности скачиваются раньше всех остальных.
> логично.И это только сейчас добавили!? Я наивно полагал, что эта "фича" - неотъемлемая часть самого протокола.
Чтобы не тормозило весь комп при верификации - хорошим вариантом было бы сделать в Transmission ограничение скорости проверки. При этом скорость проверки (в Мб в секунду) выставлял бы пользователь.
> Чтобы не тормозило весь комп при верификации - хорошим вариантом было бы
> сделать в Transmission ограничение скорости проверки.А знаете, неплохая идея, пожалуй - "фоновая проверка". Лимитирующая скорость работы. Хотя там скорее не столько мегабайты в секунду важны, сколько промежуток времени между операциями, чтобы диск доставался и другим, оно с мегабайтами конечно коррелирует но не так уж и влобовую. Вообще, по хорошему ОС сама не должна давать узурпировать диск одной программе, но программа дружественная к пользователю и горбатому железу/ос/... - вполне может и подыграть немного.
>> сделать в Transmission ограничение скорости проверки.
> А знаете, неплохая идея, пожалуй - "фоновая проверка". Лимитирующая скорость работы.оставили на багтреккере заявочку? присоединился бы к запросу...
> оставили на багтреккере заявочку? присоединился бы к запросу...Хм. Так всем и лень написать баг :). Ну черт с вами, написал, присоединяйтесь где-нибудь здесь: https://trac.transmissionbt.com/ticket/4169 - хоть лично мне и не слишком нужна фича, т.к. у меня и так работает, мне она кажется вполне разумной и я вижу вполне разумные сценарии, например, смотрение HD мувика в ущерб скорости верификации по-моему вполне валидно.
> написал, присоединяйтесь где-нибудь здесь: https://trac.transmissionbt.com/ticket/4169Вроде как и по-английски написали, но там, похоже, на нём не понимают и снова, и снова повторяют, что он и так уже в потоке (ну и что?), и предложенная ОПЦИЯ не сделает всех счастливыми. Да...
>Это же ломает логику максимальной децентрализованной отдачи...Никто не просит включать эту опцию по умолчанию.
> Никто не просит включать эту опцию по умолчанию.Ну так какая разница, по-умолчанию или нет. Она не нужна, так как её можно будет влючить, а это вред. Результат, повышенная нагрузка на раздающего и увеличение времени закачки.
Какая еще нагрузка на раздающего, это не отменяет скачивание с тебя. Заместо того чтобы сидеть и "дрочить" на полосу загрузки, когда можно уже начать смотреть. Те кто захочет ограничить раздачу им без разницы как будешь качать. Можно сделать тогда до определенного процента от начала а потом уже рандомно скачивать.
> Можно сделать тогда до определенного процента от начала а потом уже рандомно скачивать.Проблема в том что если все так будут делать, начальные части будут у почти всех, а вот остальных частей будет сильно меньше. Более того. Пусть все пиры ведут себя вот так.
Приходит в стаю новый пир. Пустой. Качает первые части кое-как с сидеров или оптимистов. Дальше надо бы раздать что-то, чтобы показать что ты не вампир и существенно ускорить свой даунлоад за счет тех кому аплоадим. А тут вдруг бац! Опа! Скачаные части и так у всех уже есть. И поэтому никому нафиг не нужны. Аплоадить их не получается. Далее, для защиты от тех кто качает но ничего не отдает, вступает в игру протокольная логика которая ценит тех кто ничего не аплоадит ниже всех остальных. И ... правильно, скорость скачки получается жопная. Даунлоад будет идти только за счет сидеров и optimistic unchoke, как на старте "пустым", т.е. весьма неторопливо. Просто потому что с глобальной точки зрения вы - паразит. Который качает, но ничего не отдает. При этом не так уж важно, "не отдает потому что никому не нужно" или "не отдает потому что такой вот козел". Различить это невозможно, поэтому "непоощрение" такого поведения применяется универсально и ко всем. То что предлагается - клещится с этой логикой и делает более доступными одни части и менее доступными другие, так что общая скорость закачки неизбежно упадет. На скачке частей которые у всех есть - она упадет потому что мы не можем аплоадить, так что все личеры предпочитают аплоадить кому угодно, но только не нам. На скачке остальных частей она упадет потому что части редкие, мля, и мало кто может их аплоадить. В глобальном плане эта логика ведет к некоей деградации состояния стаи.
Собрал 2.30b1, работает, пока багов не встречалось.
как встретишь, отпишись разрабам... чтоб не пропадал зря полученный опыт... а я уж потом посмотрю чего там наисправляли к релизу :)