Спутниковая рыбалка!

На 31,5 также обнаружил замеревшие закачки, которые 20а довел до конца : HTTP_404_..159a_Revolutions-In-Sound-Warner-Bros.-Records-The-First-Fifty-Years-10CD-2008.rar (1гб)
Файл mkv "Соседка 2004" также закачан на разную величину в %, хотя закачки не остановились пока.
Это то что попалось на глаза, специально не искал. И опять интересный момент - через стримсплиттер разбежалось число дисконтов: 25 в 20а и 171 в 9С1. Это случилось на 3-и сутки работы.
То что дисконты были не виртуальные, говорит файл 1936_..1d59_5x09_-_The_Ascent.part2.rar, который в 20а в ОК, а в 9С1 бит на 1кб.
По этой причине прерываю тест и на Астре, чтобы попробовать другую версию бетаская. Заодно и улов разгребу :).

Автор внимание обратил тестирую, но проблема в том, что ситуация с файлами замершими на 20% на маке ..e57a пока не повторяется. Зато появились другие проблемы, которые решить пока не удается.

Плавно переходим от сравнения двух версий бетаская к сравнению скайнета 20а и бетаская 9С1 (слегка подправленного).
Отработали они у меня в паре, точней в двух парах - на Астре 31,5Е (12380) и 53Е планетскае - полтора суток и надвигается жестокая необходимость сортировать улов. Перед этим и хочу высказать несколько замечаний.
Настройки програм на 53Е у меня стоят достаточно мягкие, поскольку ранее были замечены попытки грузить процессор до отказа при работе скайсортера. Уже об этой особенности как то говорил, теперь она закрепилась еще несколькими наблюдениями. Даже если нагрузка от бетаская малозаметна, при появлении некоторых процессов с большим уровнем загрузки процессора, бетаскай будто просыпается и начинает рвать ресурсы на себя. Кончается дело тем, что процессор грузится по полной и массово сыпятся дисконты. А дальше или жор памяти и вылет, или отключение процесса скайнета вручную (что иногда бывает сделать сложно если скайнет уже "закусил удила" и не слушает команд).

Это было небольшое лирическое отступление, а теперь конкретно к сравнению поведения двух скайнетов.
По общему итогу в ОК далеко вперед ушел бетаскай 9С1. В первую очередь причиной этому послужило странное отношение 20а к файлам HTTP_549_..f709_зеркальная маска.mkv (2гб) и трем его близнецам с различным содержимым. Скайнет 20а их подхватил, но вскоре бросил, самый успешный "проект" он дотянул на 50%, остальные стали много раньше. Бетаскай довел все 4 файла до ОК. Итого 8гб, что и двинуло бетаскай сразу далеко вперед. Замечу еще, что виной этому не сравнительно мягкие настройки таймаутов в 20а и не совместная работа через стримсплиттер (вдруг влияет! :)). Эти же результаты были зафиксированы на других компьютерах. Один из них ловил 20а, другой - старой версией бетаская 9В5. Старый бетаскай так же успешно дотянул мкв файлы до ОК.
О причинах можно только догадываться.
Но продолжим. Бетаскай на этом не остановился и закрепил свой успех на rar архивах.32,629гб против 28,721гб, то есть еще 4гб (и это не GL и не FTP). Эту разницу я склонен в отнести к разным настройкам скайнетов, хотя утверждать точно не берусь. Не старался в этот раз сравнить "кто больше ловит" и не выравнивал настройки специально. Мне было важно определить число брошенных закачек нового бетаская против 20а при средних настройках для обеих програм и насколько два скайнета устойчиво подхватывают одинаковые закачки. Заинтересовало это потому, что первая версия 9С1 показала себя в этом не лучшим образом даже против 9В6-911.
Автор отозвался очень быстро, поэтому и было устроено это сравнение.
Далее, 20а у меня (за всех не скажу ) пропустил (или бросил - не разбирался) несколько томов HTTP_547_..7bf5_DSRP_Epidem.ru.part18.rar.iso.rar (200мб). Но с этими файлами в 9С1 тоже странная ситуация,например 07 том записан дважды в 04:23 и 04:12. Ну может перекачивали, но в 20а только 1 копия в 4:23. Других 4-х его "братьев" нет совсем, что и дает бетке еще 800мб.
Дальше можно не разбирать разницу в улове, но есть интересный момент. 9С1 не заметил несколько файлов в протоколе GRE2, которого на 53Е достаточно много. Например 559_iIPxGRE2xIPxTCPxHTTP_..690c__.rar (89мб), 554_iIPxGRE2xIPxTCPxHTTP_..3b88_Morfiy.2008.O.DVDRip_INTERFILM.part13.rar (96мб) и другими, всего их собралось в 20а 970мб за эти 1 сутки и 12 часов.
Но как мы уже видели по цифрам, на их место бетаскай нашел что собрать с лихвой.
И по поводу подхвата закачек, утром 9С1 поставил в очередь еще один mkv все с того же мака, но не качает пока. Зато 20а поставил в очередь оттуда же целых 11 таких же файлов-близнецов. Посмотрим что будет дальше...

А дальше, вскоре после сортировки, вперед рванул 20а на 350мб. Но пока за счет все того же GRE2. Есть еще пара небольших файлов в GL, но как раз это не удивительно, таймаут для GL в ини файле 20а 30 минут, а в 9С1 - всего 5.

А проблема с GRE2 - это баг, работало по словам автора, но отключилось при переработке ядра ТСР.
Я точно помню что проверял на 9В6, но запамятовал 1 или 2.
Так что подправят скоро и это.

11:21 01.01.2009

Четверо с половиной суток работы. С GRE можно считать разобрались, это нечаянный баг и в следующей версии его исправят. Пока обе пары скайнетов работают вполне стабильно, правда пару на Астре я отключал... из любопытства. У меня стоит фильтр по пидам так как с универсальным пидом 8192 бетаскай показывает завышенный поток и счетчик дисконтов не останавливается. Это происходит на BDA драйверах карты ТТ1401. На карте Red Prof 7300 этого не наблюдается, но там используется другой streamreader, специально написанный для этой карты. Да и BDA драйвера у нее (как и положено ) оригинальные. К сожалению склонность к дисконтам - также является "оригинальностью" этой карты. Во всяком случае моего экземпляра и на моих двух компьютерах . Так вот, возвращаемся к Астре , у сатгейта там появился новый рабочий пид 777 и из любопытства я добавил его в список фильтрующихся пидов. Но добавки к улову это не принесло, новый пид хоть и занимает 2-е место по прокачиваему объему, в закачках за прошедшие сутки не отметился.
По объему записанному в ОК эта пара сильно не отличается (настройки в ини у них примерно одинаковые), но легкое опережение 9С1 есть почти всегда. Есть и попеременный успех/пропуск отдельных файлов - куда ж без этого . Но по показателю written разница заметна. В 20а 9,85гб за новогодние сутки, в 9С1 - 11,15гб. И это вполне справедливо, несмотря на почти одинаковый ОК 9,188Гб в 20а и 9,245Гб в 9С1 (напомню еще раз у меня версия 9С1 с исправлениями для многопоточных закачек). Почему тогда отличается written? Потому что не все закачки дошли до финала. Но если раньше, до исправления, 9С1 оставляла много файлов в бесконечном таймауте, то сейчас этим отличается 20а. Нет, версия скайнета 20а не стала работать хуже! Просто бетаскай чуть более цепко держит некоторые закачки. За эти сутки могу в пример авишку привести без названия HTTP_404_..119c3_19__.avi (739,37мб).Если в 20а она замерла на 0,07%, то 9С1 дотянул ее до 88,9%. Потом правда все равно о ней "забыл" уже 18 часов назад. так и набегает разница между показаниями програм. Нельзя сказать что это наблюдается очень часто, большая часть брошенных закачек замирают абсолютно одинаково. Но есть и такие случаи, которые при желании можно легко заметить. Пока писал, поглядывая на скайнеты, заметил еще одну такую же авишку с того же мака. В 20а она стала на 0,12%; 9С1 тянет ее уже на 49,64%. Скорость 30кб/с, в закачке пять секций, объем 1,37мб, названия не вижу. Несмотря на хорошую скорость, закачка часто останавливается.
Такой способ закачивания (как у этого мака) дает мало шансов довести крупный файл до ОК любому скайнету. Но этот повторяющийся факт никак не могу не отметить. 9С1 лучше держит закачки на и 31,5 и
на 53Е.
Ну а на PlanetSky 53E все по прежнему. Такого превышения в улове как на вторые сутки больше не было, но чаще всего впереди бетаскай, несмотря на отсутствие в этой версии GRE2 и по непонятной причине пропущенный образ (512_iIPxTCPxHTTP_..6787_Freelancer-iMMERSiON.iso).
Но это просто обмен пропущенными файлами, другой образ появился в 9С1 (правда изрядно битый) и отсутствует вообще в списках 20а (HTTP_522_..4844_ХР_2008.iso).
Если посмотреть что попало в ОК по различным протоколам, то окажется:
ZIP: 20а 39 файлов (2,370гб), из них 3 файла GRE (245мб), 3 в GL (184мб),4 FTP (221мб)
9С1 32 файла (2,290мб). Из них 2 в GL (109мб) и 2 FTP (102мб)
С GL понятно, настройки таймаута в ини у меня слабоваты против 20а, а вот FTP настораживает. Тем не менее общий объем зазипованных файлов отличается всего на 80мб, опять бетаскай нашел чем компенсировать пропущенные файлы. Посмотрим более объемные папки RAR.
20а 516 файлов (46,121гб). Из них GRE всего 2 файла (45мб) - отдыхали "GRE-шники" на Новый Год :).
FTP 12 файлов (133мб) - часть совсем мелкие, до 5мб пролезли.
GL 41 файл (3,454гб)
Тепрерь 9С1 - 498 файлов (46,242гб). Из них GRE как сами понимаете 0, FTP 3 файла (51мб) - но каждый больше 10мб в отличии от 20а, GL 39 файлов (3,571гб). Получается число файлов в GL меньше, а объем больше почти на 120мб. И это при таймауте 5 минут (gl_session_timeout=300000) в 9С1 и 30 (gl_session_timeout=1800000) в 20а. Блоков правда в 20а (gl_max_blocks_wait=512) меньше чем в 9С1. Всего в ОК сейчас почти равные цифры 49,003гб и 49,045гб. Несколько часов назад впереди на 200мб был бетаскай. Сейчас 20а его догонит и перегонит, поскольку нашелся архив с ХР-2009 (751мб), который в число закачек 9С1 не попал.
По поводу отдельных файлов пропавших в отдельной программе, надо сказать еще об одной возможной причине, которая полностью зависит от моей внимательности. Бывают случаи при "ручной чистке" закачек, когда я для полной симетрии открываю оба окна скайнетов и удаляю лишние файлы в обеих программах по очереди. Причина этого - желание продлить время до очередного разбора улова скайсортером. Больше времени перед очисткой рабочих папок - точней статистика. Ну и бывают случаи (увы мне ), когда смотришь в одно окно нажимая del, а активно при этом другое... Исчезает закачка и что там удалил уже не узнать. А если это файл объемный - он может стать решающим при подсчете улова. Поэтому я стараюсь после таких случаев искать повторные подтверждения этому. В конкретном этом отсчете (напомню за 4,5 суток) пока 20а не вел счет и отметился только одним образом в ОК. Что будет дальше - увидим. 2009 год только начался, вся рыбалка еще впереди...
Пора разбирать первый новогодний улов и к столу :).
С наступившим Новым 2009 годом!

И снова утренний (праздничный ) обзор "новостей".
Меня всегда удивляли заявления вроде подобного: "Я для пробы на несколько часов (на ночь) включал другую версию скайнета и никакой разницы с первой не заметил". И чуть более корректные: "Включал через сплиттер два скайнета и гонял сутки, но разницы в улове нет".
Вот вчерашнее мое сообщение - улов был примерно равен и 20а пытался обогнать бетаскай образом в архиве 559_iIPxTCPxHTTP_..4176_Loner_XP_2009.rar (751мб). Да, образ есть. Да есть еще файлы GRE, например, 559_iIPxGRE2xIPxTCPxHTTP_..690c_Adobe Photoshop CS3 Extended 10_0.rar (475мб), все GRE2 считать не буду. Опять у 20а есть почти пятикратное превышение по FTP (240мб против 53мб).
И все равно бетаскай нашел чем сегодня ответить . 20а (возможно только у меня, не знаю как у остальных, сейчас и проверим) решил полностью игнорировать HTTP_566_..e57a_Rammstein-2.iso.rar (iso 4,5гб томами по 900мб), которые и были к 9 утра успешно закачаны в колличестве 5 штук. А в закачки на их место встали такие же тома с Rammstein-3. Для 20а все они опять остались невидимы. Повторилась та же история, что была с mkv. А может глюк "стримсплиттера", потому что regex одинаковые.
Как итог, 9С1 сегодня опять ведет 27,971гб против 24,536гб. Можно и скрин посмотреть, где разница в записанном достаточно впечатляет.

Так что даже многосуточное сравнение может иметь неожиданный, случайный итог.
А что происходит на Астре? Там тоже ведет в объеме пойманного улова 9С1. Немного, на 200мб, но это же за сутки... И вот пример как иногда ведут себя скайнеты (не могу сказать по какой причине) с отдельными закачками на примере авишки. Это очередная иллюстрация к примерам, которые я уже приводил, объясняющим почему параметр written так сильно расходится. 9С1 тянет несколько потоков, а 20а только один. Файл один и тот же, результат в объеме записанного разный.

Забегая вперед, скажу что 9С1 авишку докачал.
И неожиданный для меня самого вывод напрашивается. Плохо предсказуемое это дело - сравнение разных програм.

PS
Так и есть, подтвердили что 20а Рамштейна закачал, а у меня не захотел.

По поводу пропуска файлов iso.rar 20а - Рамштайн и сегодня на Астре точно такой же случай с Loner-XP-2009.iso в многотомнике rar. Это уже другая пара тоже через свой сплиттер.
Есть два варианта, или обе программы по разному относятся к одинаковому regex`у. Но как в любом случае можно пропустить RAR! ? А ВСЕ rar у меня включены с 10мб.
Или это результат работы сплиттера. Но он (как я понимаю) просто раздает один и тот же поток всем желающим.
Какой вариант правильный - затрудняюсь пока ответить.
Но для начала включил в фильтрах еще и iso.rar Хотя не пойму как это может влиять, если не нужно из всех rar`ов выбирать строго определенные. Но может как раз это и влияет.

***
Включение в фильтрах iso.rar вроде бы помогло, теперь в 20 а стали на закачку многотомники rar по 900мб с LACRIMOSA.iso Не совсем понятно мне почему, но теперь отрыва на гигабайты уже не будет и улов выровняется (за исключением GRE).

PS
Дальнейшее сравнение потеряло смысл и становится технически достаточно сложной для меня задачей. Итог все равно уже ясен. Добавить в 9С1 GRE и по улову она обойдет на этом прове 20а за счет отдельных, доведенных до конца авишек и других больших файлов. Останется вопрос стабильности и предсказуемости долговременной работы 9С1.
Выше сказанное относится и к Астре, где GRE очень мало. Там улов практически равен (но все же на 100-200мб в сутки больше у 9С1 за счет отдельных не самых больших файлов). Но отдельных авишек в 9С1 ловилось больше чем в 20а, хотя надо отметить, что и в 20а были крупные файлы из тех, что 9С1 не заметила. О стабильности на этом провайдере можно не переживать, не та здесь нагрузка чтоб бетка вылетала.
Если соберусь еще сравнивать, возможно попробую радугу 60Е, где глобакс грузит до предела оба скайнета. Правда на качестве и количестве улова это никак не отражается. 10- суточный скрин-итог скайнетов смотрите в теме о betasky. И если тест по улову этих версий практически осмтановлен, то тест по стабильности еще продолжается.

Всех с праздником Рождества Христова!