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

Может несколько поздновато, но необходимо все же внести ясность в некоторые важные (для провайдера «Радуга» на 60Е во всяком случае) настройки программы. По умолчанию в ini файле 9В6 параметр gl_timeout=180000. Он нормально работал на 53Е Planetsky и SkyDSL. Но для 60Е такой таймаут оказался тяжеловат. В первую попытку с таким параметром бетаскай отработал четверо суток и вылетел. В паре с 20а он продержался чуть более суток, видимо сказалась дополнительная немалая нагрузка или повышенный уровень глобакса в эти дни. Автор бетаская S0RRY порекомендовал для «Радуги» 60Е применить gl_timeout=120000 или 150000. Так низко сразу я не стал падать , ограничился величиной 160000, которая неплохо показала себя с BDA драйверами. Все описанное в предыдущей части работало именно с таким параметром. Вылетов за неделю не было, нагрузка небольшая, а улов больше чем в 20а. Эту же величину оставляем и для 9В6 на WDM драйверах.
Попутно, чтобы внести разнообразие в «тест», пробуем использовать для 20а и 9В6 абсолютно одинаковые regex. Для этого в файле от 20а были закомментированы верхние строки, пример одной из которых есть в первой части (полностью эти строки дам ниже).
Секцию глобакса в ini 20а не трогаем, хотя здесь тоже есть настройки (их даже больше), поскольку увеличивать таймаут для GL в 20а - значит увеличивать и так достаточно большую нагрузку на систему.
С одним скайнетом ещё можно себе такое позволить, но если их работает 5? По моим наблюдениям часто (но далеко не всегда) «жор» и вылет «бетки» случается как раз в момент большой и длительной нагрузки. Это было с разными версиями и на разных провайдерах. Самое интересное, что 20а нагрузивший процессор до 40-50 % и память до 600-700 Мб, продолжает цепко, до последнего ( камнем на шее), держаться за систему. А бетаскай великодушно «отпускает» её, уходя на дно в одиночестве. Что лучше – зависит от того, чем это «приключение» заканчивается. За время «тестов» я наблюдал как один скайнет, по ошибке включенный с фильтром «+ALL от 0» и нагрузивший систему «до полного», привел к «жору» второго работающего скайнета. Первый еще минут 20 после снятия «плюса» бомбардировал диск всякой мелочью (при этом в окне ская ни одной закачки не было видно). Второй – все это время пытался выйти из процесса «жора», видимо принимая его на свой адрес. Первый пришлось отключить (что помогло снять нагрузку далеко не сразу), а второй все же восстановился и после этого отработал еще 12 суток, пока у наших электриков не зачесались руки «поработать» .

Итак, вот что получилось с WDM драйверами на карте SS3.
1 сутки и 8 часов
Как и в прошлый раз закачек в 20а больше - 247, против 216 у 9В6. Нагрузки на систему с вдм драйверами ниже: 20а - процессор 10%, память - 118/141 Мб; 9В6 - 6%, память - 38/42 Мб.
Общие данные:
in=379,72 Гб ТСР=227,85 Гб UDP=188,43 Гб GL=101,11 Гб
По внутреннему счетчику записано: в 20а=25,94 Гб в 9В6=25,58 Гб
Поскольку проскочило около 400 дисконтов, мы заглянем и в папку incomplete, где находятся файлы от 98%. Они точно отловились бы, не будь дисконтов. Суммировать мы их не будем к общему улову, просто примем к сведению.
ОК 20а=10,139 Гб incomplete=1,379 Гб temp=12,056 Гб
ОК 9В6=9,685 Гб incomplete=1,407 Гб temp=14,092 Гб
Заглянем в OK:
avi - по одной общей авишке.
Из мелочи:
djvu - на один файл больше у 9В6
mp3 - общий файл на 73 Мб
pdf - файлов поровну - 32, но в 20а на 5 Мб больше.
В 20а появилась мелочевка (может после удаления первых строк от regex 20а?) - gif, jpg, htm и bin внутри которых файлы с названиями: Poslednii.Dozor.MP3.32kbs.part1.rar.bin Poslednii.Dozor.MP3.32kbs.part1.rar.gif до 3 кб.
Это не дело, восстанавливаем закомментированные строки regex (хотя полной уверенности что это их работа у меня нет).
ok\rar
20a - 246 файлов на 7,065 Гб, размером >50 Мб - 50 файлов на 4,732 Гб
9В6 - 232 файла на 6,236 Гб, размером >50 Мб - 44 файла на 3,798 Гб
Основная разница в файле 4359_iIPxTCPxHTTP_SPEEDxp-NOXCHi.rar (с образом iso внутри) на 446 Мб у 20а, которого нет в 9В6.
zip 20a 183 файла 1,982 Гб, >30 Мб 20 файлов на 833 Мб
zip 9B6 187 файлов 2,238 Гб, >30 Мб 20 файлов на 1,143 Мб
Основная разница в 2-х файлах на 260 и 108 Мб, которых нет в 20а.
Как видим, 20а в rar обогнал 9В6 на один «решающий» файл, не связанный с GL. И только zip архивы betasky по прежнему ловит лучше. Какое отношение это имеет к смене драйверов – непонятно. Относим это к случайности.

Без малого 2 суток (1 сутки и 21 час).
ОК 20а - 13,432 Гб
ОК 9В6 - 13,383 Гб с учетом содержания incomplete ситуация равная.
Боюсь только за счет zip . Проверяем.
rar 20а - 370 файлов 9,746 Гб ; >50 Мб - 63 файла 6,203 Гб
rar 9В6 - 349 файлов 9,352 Гб ; >50 Мб - 65 файлов 5,731 Гб
zip 20a - 333 файла 3,170 Гб; >50 Мб - 3 файла 248 Мб
zip 9B6 - 338 файлов 3,516 Гб; >50 Мб - 5 файлов 617 Мб
Что сказать, за это же время на BDA драйверах бетаскай опережал по объему ОК уже на 2,5 Гб . А здесь в лучшем случае «всеобщее равенство» . Случайность? Может быть, может быть…
Но мы волевым решением тормозим обе программы и пробуем добавить в 9В6 больше GL, вначале до значения по умолчанию 180000. А вдруг будет работать? Нагрузка же меньше на wdm драйверах!
И вот через 10 часов предварительный итог (больше электрики не дали ):
ОК 20а - 8,804 гб
ОК 9В6 - 9,915 Гб
rar 20а - 218 файлов 6,520 Гб; >50 Мб - 41 файла 4,379 Гб
rar 9В6 - 287 файлов 6,870 Гб; >50 Мб - 43 файлов 4,530 Гб
В 9В6 есть дополнительно образ HTTP_4175_GL_ZverCD.com-v8.3.3.iso на 700 Мб, который и дает вместе с мелочью выигрыш в 1 гиг.
Совсем другое дело! Неплохо за 10 часов. Опять случайность? Или все же результат увеличенного параметра GL на этом провайдере? Посмотрим что даст более длительный тест.
Но с параметром gl_timeout=180000 длительного теста не получилось. Через 20 часов, бетаскай вылетел с «жором» памяти и сообщением об ошибке (в это время работал смартсортер, обрабатывая улов с 53Е). Поскольку бетаскай был «ведущим» скаем, то вслед за ним потерял поток и 20а. За это время они успели записать:

ОК 20а - 11,152 гб
ОК 9В6 -13,175 Гб
ТЕМР 20а - 13,569 Гб
ТЕМР 9В6 -13,416 Гб
По два образа iso на 2,056 Гб
И вдруг 20а удивил, следите за цифрами!
rar 20а - 1729 файлов на 6,547 Гб; >80 Мб 32 файла на 3,210 Гб
Причем 1488 файлов в 20а размером не более 4 Кб с содержимым архива - update.ver. Признаюсь, это необычно для 20а. Бетаскай эту мелочь ловить отказался.
rar 9В6 - 257 файлов 7,939 Гб >80 Мб 37 файлов 3,995 Гб
zip 20a - 183 файла 2,285 Гб
zip 9В6 - 211 файлов 2,831 Гб
Ну что сказать, за 20 часов прибавка к улову 2 Гб - хорошая заявка, но вылет при этом сводит её к нулю. Пробуем найти оптимальный вариант параметра gl_timeout и возьмем его для начала 170000.
Первый замер делаем через 2 суток.
На вторые сутки появились дисконты и часть файлов побилась, в обоих скаях поровну, около 2,5 Гб битых файлов. Кстати, периодические дисконты могут быть косвенным признаком проявления «жора» памяти бетаская, а значит сигналом работы в критических условиях.
in – 548 Gb; TCP – 326,4 Gb; UDP – 298 Gb; GL – 172,3 Gb
Закачек в 20а – 400 с небольшим, в 9В6 чуть меньше. Без особых торможений и миганий экрана их число уменьшаем до 250.
ТЕМР 20а - 20,496 Гб
ТЕМР 9В6 - 22,596 Гб
ОК 20а - 24,400 Гб
ОК 9В6 - 27,054 Гб
Разница в 2,5 Гб, посмотрим где она просочилась. Забегая вперед, скажу что это точно не zip.
rar 20а - 667 файлов 18,306 Гб >80 Мб 65 файла 8,924 Гб
rar 9В6 - 670 файлов 20,243 Гб >80 Мб 76 файлов 10,243 Гбъ
На этот раз с большими файлами по 600-700 Мб паритет, а разница пришлась на многотомники в районе 100 Мб.
А вот в zip большой разницы не оказалось
20а – 4,950 Гб – 473 файла.
9В6 – 5,685 Гб – 502 файла.
И только по pdf скайнет 20а почему то попытался уйти в отрыв на 100 Мб.
Авишек по одной, по одному общему образу тоже нашлось.
Заглянув в лог 9В6, вижу что ночью у этого скайнета дважды просыпался и угасал «жор». Похоже на 60Е таймаут 170000 близок к критическому и чреват вылетом. 2 суток работы не так много, чтобы это проявить, но скорее всего причина ночных дисконтов – этот самый «жор». Попробуем в следующий раз поставить промежуточное значение в 165000.
И действительно, после 4-х суток 9В6 вылетает, увы. Промежуточный параметр также не помог «долгожительству» программы в системе. Пришлось вернуться к значению 160000, которое показало терпимость к потоку GL на этом провайдере.
И что удивительно, второй «забег» двух скайнетов с этим таймаутом показал безоговорочное превосходство бетаская.
Через сутки работы:
20а ОК - 15,123 Гб; rar - 11,759 Гб; zip – 2,923 Гб
9В6 ОК – 16,053 Гб; rar – 12,340 Гб; zip – 3,058 Гб
И более того! Установленный таймаут в 155000 также дал через сутки превышение улова бетаская:
По 3 авишки, одна в глобе – полное равенство.
20а ОК - 19,063 Гб 9В6 ОК - 20,680 Гб
rar 20a - 14,404 Гб zip 20a - 2,564 Гб
rar 9B6 - 15,714 Гб zip 9В6 - 2,473 Гб
Каждый новый старт проходит с переменным успехом по объему улова и только вылеты бетаская периодически повторяются. Чем это объяснить? Видимо тем, что в каждом «забеге» была разная интенсивность перехватываемого потока. От этого зависит нагрузка на скайнеты и их эффективность. Можно предположить, что при скудном потоке мы наблюдаем примерное равенство (как на сатгейте 42е), а при насыщенном – одна из программ вырывается вперед.
Меньше ли стал улов скайнета 9В6 на wdm драйверах при равном таймауте GL? Чтобы это подтвердить или опровергнуть нужно включить два бетаская на разных картах и драйверах. Пока такой возможности нет. У меня остались скриншоты работы 2-х 9В5 на планетскае 53Е, не столь длительные чтоб делать выводы, но 4 часа тогда дали полное равенство в улове. А скриншоты 2-х 20а там же, показывают разницу уже через полтора часа. Но не будем делать скоропалительные выводы, просто примем полученные результаты к размышлению.
Случайности случайностями, но кардинального отставания 9В6 пока не было. В худшем случае равенство. За сутки – двое один из скайнетов вполне может «случайно» пропустить 1-2 файла критического размера (критического для подобного краткосрочного «теста»). Но более длительные тесты на 60Е мне не позволяет проводить ограниченное дисковое пространство. Записываемый поток здесь может временами превышать поток с планеты 53Е. К тому же у меня остаются вопросы по долговременной стабильности бетаская на этом провайдере, более 4-х суток пробовать два ская у меня не было возможности. Потому следующая цель – определить с каким параметром бетаскай будет работать здесь стабильно и долговременно на wdm и bda драйверах, а потом уже сравнивать 9В6 и 20а в парной работе.

Совсем другое дело неторопливый Сатгейт на 42Е. Сделаем еще одну попытку провести там сравнение. В regex 20а убираем верхние строки (о которых я уже не раз писал и обещал дать полностью). Вот они:
8080C0 n \.iso$ iso;CD;ALL
FF0080 n \.rar$ rar;ARCHIVE;ALL
008000 n \.zip$ zip;ARCHIVE;ALL
C0C099 n \.avi$ avi;VIDEO;ALL
80C000 n \.wmv$ wmv;VIDEO;ALL
80C000 n \.mpg$ mpg;VIDEO;ALL
80C000 n \.mpeg$ mpg;VIDEO;ALL
Это делает файл полностью одинаковыми с тем, что в 9В6.
И как это сказалось? Напомню, здесь работает SS2 и до этого скайнеты давали примерно равный улов:
1 сутки и 13 часов
ОК 20а 9,035 Гб
Ок 9В6 12,173 Гб
rar 20a 133 файла 8,551 Гб
rar 9B6 180 файлов 11,713 Гб
zip мало и разница незначительная.
Весь прирост 9В6 в 3 Гб дали многотомники: HTTP_454_The.Scorpion.5.part0х.rar.iso
и HTTP_454_SamAndMax.part0х.rar.iso
В 20а их нет. Обращаю внимание – это не GL.
Ставим убранные строки regex на место, и сразу в 20а появляются среди закачек парты с "царем скорпионов". Значит они все же имеют отношение к отлову многотомников.
После этого, еще через 3 суток оба ская снова показывают минимальную разницу в улове:
20а ОК - 23,433 Гб
9В6 ОК - 23,479 Гб
И только в ТЕМР у бетаская преимущество в 4 Гб. Но от ТЕМР-а до ОК путь неблизкий, через болото таймаутов . Видимо разница там и вязнет...
Если кому интересна нагрузка на систему, то от 20а процессор грузится (при очень скромном потоке 2 Мб/с) до 9% в пике, ОЗУ 32 Мб, подкачка 53 Мб.
9В6 - процессор до 4%, ОЗУ 11 Мб, подкачка 13 Мб.
Вот где, есть возможность поиграть настройками GL в ини файлах обоих скаев (а может не только GL). Но надо думать такая "игра" может привести к краху скайнета в момент неожиданной прибавки по GL. И самое главное, а нужно ли это на 42Е? Что может дать увеличение таймаута для глобакса, которого на этом спутнике очень мало? Наверное, ничего. Здесь и так таймаут по умолчанию 180000 не дает никакой дополнительной нагрузки.
Обычно на 42Е при in=267Gb GL=5,3Gb, а на 60Е при in=272 Gb GL=90,5 Gb. Одна треть входящего потока – или одна 50-я часть! Как говорится «думайте сами, решайте сами...»
Но периодически и здесь появляются "качки" с глобаксом и также неожиданно пропадают. Однажды был очень удивлен, увидев в улове несколько полновесных СD с аудиокнигами и пометкой GL.
Например, за последние сутки на 42Е пришло в GL:
20а – 14 файлов на 219 Мб из 171 файла общим объемом 7,471 Гб
9В6 – 14 файлов на 246 Мб из 180 файлов объемом 7,300 Гб
Всего то… одна тридцатая часть из записанного на диск. Но забегая вперед, скажу что попробовал установить gl_timeout=600000. Нагрузки заметной это не добавило для Сатгейта, но дополнительную авишку в глобе принесло через сутки.

Всё… приостанавливаем «тесты-измерения», выключаем skynet20а на 60Е. На что система с облегчением вздыхает , уменьшая файл подкачки с 1,1 Гб до 600 Мб. График нагрузки процессора из «психованной» синусоиды становится похож на мелкие зубчики пилки лобзика , вентилятор процессора в августовскую жару перестает переходить на повышенные обороты и становится практически неслышным... Все отдыхают… Можно посмотреть пойманный фильм, записать болванку.
…И только бетаскай на 53Е пыхтит без остановки двенадцатые сутки. До этого он с честью отработал 14 суток на BDA драйверах, теперь наматывает часы на WDM. От него не отстает бетка на 42Е. И только на 60Е с этими тестами получается сутки через трое. Займемся всерьез тестом «на долговременность».

Alex G.
Сентябрь 2008 г.

2-й 20а
gl_max_blocks_wait=1024
gl_session_timeout=3600000
gl_channel_timeout=300000

То есть, число блоков одинаково - 1024, это больше чем по умолчанию (256), а таймаут отличается, в первом случае пол часа, во втором, как и по умолчанию - 1 час.
Нагрузка уже через 2 часа работы начинает расти. На CPU разница не очень велика и пока находится в районе 12-14 % от каждого скайнета на собственное ядро, а на память (ОЗУ/подкачка) 121/228 Мб и 147/371 Мб. Закачек всего пока поровну.

На этот раз у нас задача не только найти разницу в улове от настроек, но и определить тяжесть этих настроек для системы.
Как раз тяжесть на этом провайдере проявляется очень быстро. Еще через полтора часа 1-20а занимает - 201/239 Мб, 2-20а - 276/391 Мб и медленный рост не прекращается.
Поскольку 20а позволяет взглянуть на процесс обработки глоба, мы и эти цифры приведем.
1-й скай по глобаксу: каналов 61000, сессий 3200, блоков 39000, памяти 35 Мб.
2-й скай по глобаксу: каналов 66000, сессий 5930, блоков 49000, 49 Мб памяти.

Прошло 6 часов, уж и не знаю, хватит ли ресурсов по памяти до утра :), 304/346 Мб и 459/564 Мб и рост постоянный. Активных закачек при этом всего-то по 4 в каждой программе. Записано по 2,54 Гб, in=88,4 Гб, ТСР=48 Гб, UDP=53 Гб, GL=28,17 Гб.
В ОК по 1,152907013 Гб - копейка в копейку равные числа. По одной авишке фривольного содержания в ТСР есть в incomplete. И тоже байт в байт все совпадает.

Для сравнения бетаскай на 53Е с планеты записал уже вдвое больше за то же время и занимает 43/46 Мб на бда драйверах. Здесь in=92 Гб, записано 5,52 Гб, в ОК всего (за вычетом nntp) 4,385 Гб. Правда, GL из них всего 0,5 Гб. (На 60Е примерно 0,9 Гб из 1,1 Гб.)

И еще одно интересное явление, в 1-м 20а в логе масса записей вроде:
213100.00 hserv_thread: bind error
Лог практически весь из них состоит и вырос уже за мегабайт. В логе второго ская их не видно, он 55 кб, в нем другие записи встречаются достаточно часто
214600.04 unpack error -3, ses id 762857AA
Но, несмотря на разницу в логах, улов пока совпадает идеально.

Смотрим через 16 часов. По утрам замечено, нагрузка падает довольно значительно. Общий файл подкачки у меня уменьшился за ночь с 1,3 Гб до 655 Мб. Скаи занимают 108/118 и 144/163 Мб, нагрузка на процессор до 10-12%.
in=206 Gb; TCP=114,66 Gb; UDP=118,6 Gb; GL=67,7 Gb; written=10,16 Gb.
Наконец появилась разница в числе закачек, но всего на 1 файл: 146 в первом и 147 во втором. Активных закачек поровну - по 7.
В ОК тоже разница, которую можно было бы и не заметить: 7,081 и 7,102 Гб. В чем она заключается? В одном zip архиве с Iron Maiden - The Trooper.avi в 21 Мб в GL. В папке zip в ТСР всего 4 файла из 32 (240 Мб из 1,2Гб).
В rar и djvu полная идентичность, других файлов нет.
По GL содержание следующее: 2,981 Гб в 93 файлах, из всего 5,998 Гб в 133 файлах. Практически 50%, меньше чем обычно, но если добавить zip, то процент глоба идет на рост - 56%. Время для замера было не особенно удачное по активности, посмотрим что даст день сегодняшний. Похоже что разница не проявится с этими установками (в улове, конечно, в ресурсе разница достаточно заметна), поэтому будем думать что изменить и в какую сторону в следующем замере.

Прошли сутки и 2 часа. in=342,3 Gb; TCP= 202,3 Gb; UDP=185,30 Gb; GL=105,5 Gb GRE=11,7 Gb; written=16,57 Gb.
Сейчас как раз пик нагрузки на скайнеты. К сожалению, определить это можно только по нагрузке на систему, то есть косвенно. Напомню, что в бетаскае есть более понятный индикатор - скорость записи на диск.
Добавлю еще один показатель по индикатору скайнетов, касающийся глоба, - сессий 7445, ошибок 1676 в одном скае; и сессий 3840, ошибок 1188 в другом.
Можно подвести суточный итог по улову.
Итак, 1-й скай - память 253/307 Мб, второй - 408/510 Мб. Нагрузка на процессор неравномерная и прыгает от 11 до 23% в обеих копиях программы, не совсем синхронно. Напомню, каждый скай грузит собственное ядро процессора.
Число закачек после удаления 99%-ных 223 и 224. Разница не увеличилась, значит случайность. Первым делом смотрим incomplete, проскочило 287 дисконтов по неизвестной мне причине.
Там находим по второй авишке с тем же контентом что и в первой и тоже вне GL, по 12 файлов в rar на 1,314 Гб. В GL ни одного: 4 файла в ТСР на 1,079 Гб и два в GRE. Размер содержимого совпадает байт в байт.
Переходим в ОК. Общий объем записанного 10,720 и 10,740 Гб. Разница та же в один файл 20 Мб. Дальше можно и не считать, просто посмотрим что из этого качалось через GL. 3,717 Гб в 126 файлах из 8,753 Гб в 207 файлах. Это по rar.
Теперь zip. 1,284 Гб в 42 файлах из 2,174 Гб в 59 файлах. (Странная статистика :), через GL в процентном отношении больше качают zip архивов на этом провайдере). Итого из 10,927 Гб в GL качалось 5,001 Гб. Если прибавить и две авишки в ТСП по 700 Мб, то за прошедшие сутки процент GL ниже чем обычно - менее 50%.

Еще пару слов о логе скаев, сохранилась тенденция роста одного лога до 3,9 Мб все с той же записью
hserv_thread: bind error
Что она означает, не знаю, но влияния на улов она не оказала. Второй лог вырос до 200 Кб, что нормально для 20а за сутки.
Вывод.
Разный таймаут 1 час против 30 минут не дал практически никакой разницы в улове 20А, но заметно увеличил требования к ресурсам. Видимо критически важное время ожидания будет меньше 30 минут. Может позже попробуем точней определить его.

А пока пробуем менять число блоков глоба на сессию.
Оставим таймаут в пол часа (нагрузка меньше при равном улове), а блоки поставим 256 (как по умолчанию) и 1024, что бы не напрягать излишне систему. Максимум в 3000 блоков (как в бетаскае) брать не буду, иначе с подкачкой в гиг с лишним у меня возникают некоторые трудности с тормознутостью системы.

И на дессерт статистика по GL на 53 planetsky за 20 часов. Из всего 18,622 Гб в 268 файдах rar архивов, глобакса оказалось 1,266 Гб в 31 файле. Совсем немного, около 7%. Это улов бетаская с таймаутом для GL 600000. Время вдвое больше чем было по умолчанию в бетаскае, но в 6 раз меньше чем по умолчанию в 20а.

А вот и первые итоги разницы в числе блоков.
1-й скай через 2 часа с 256 блоками по умолчанию уже записал на 3 файла меньше, чем 2-й с 1024 блоками. Разница эта пока укладывается в 100 Мб, но это только начало. Что будет дальше - узнаем завтра.А сегодня нагрузка на память: 114/253 первый скайнет и 177/334 - второй.

10 часов работы и нагрузка на скайнеты можно сказать пиковая: 287/329 Мб и 385/448 Мб. Нагрузка на CPU до 33% на втором скайнете и до 25 на первом. Появились дисконты - 748.
Содержимое incomplete и ОК по прежнему равно до байта, что уже говорит - ситуация не изменится. Никаких "случайностей" с этими установками не наблюдается. И даже содержимое папки ТЕМР отличается всего на 4 Мб.
На 53Е нагрузка от бетаская 52/55 Мб.

1 сутки. Пора подводить итоги. Самое интересное - я ошибся с предварительными выводами о равенстве улова на таких установках. Но все по порядку.
in=295 Gb;TCP=159 Gb; UDP=156 Gb - здесь пока равенство, а дальше пошел разбег. 1-й 20а - GL=82,95; written=11,26 Gb
2-й 20а - GL=85,61; written=12,11 Gb. Число сессий 2570 и ошибок 705 примерно равны. Дисконтов у меня проскочило 1022, погода нормальная, значит или с сигналом проблемы или с перегрузкой системы. Впрочем на других провайдерах (42Е и 53Е) дисконтов нет, значит не перегрузка виновата.
В incomplete содержимое сходится до байта.
В ОК разница почти в гигабайт. 1-й 20а - 7,475 Гб; второй - 8,443 Гб.
Файлы в улове трех типов: djvu - полное равенство, zip - 1,609 Гб против 1,625 Гб - почти равны. Значит гигабайт пришелся на rar.
Расклад по GL такой:
1-й - 4,181 Гб в 109 файлах. Всего 5,793 в 141 файле.
2-й - 5,132 Гб в 120 файлах. Всего 6,744 Гб в 152 файлах.
Как видно плюс 11 файлов и дали 1 Гб разницы, все файлы в GL и размером около 100 Мб, скорей всего это многотомники, потому что самые крупные файлы в 300 Мб есть в обоих скайнетах.
Логи теперь одинаковой длины 140 кБ и отличаются на каких то 36 байт.
Самое интересное для меня, когда же второй скайнет совершил свой рывок? 10 часов наблюдения показали равный улов (до байта!) и равное число файлов в закачках.
Выждал еще 4,5 часа и смотрю что изменилось.
По показанию скайнетов: 1-й GL-98,8Gb; 2-й GL 101,5Gb.
Нагрузка на процессор растет в пике до 25 на первом и до 35 на втором и ниже 15% не опускается. Память 196/227 и 222/376 Мб. Закачек 211 в первом и 203 во втором. Активных среди них по 9. В ОК 11,722 и 10,756 Гб, та же разница в 1 Гб. За 4,5 часа она ничуть не изменилась. Прямо загадка природы :). Ответ у меня только один, был пик в закачках GL, когда первый скайнет со своими 1024 блоками на сессию перестал справляться с обработкой потока. Но сейчас за 4,5 часа закачалось по 3 Гб в ОК, а разница не увеличилась...

И вот почти сутки, пока допишу - 9В6 уже отсчитает их на своём таймере.
Неожиданности начинаются с самого начала, с параметра in. 1-й скай - in=271,12 Gb; 2-ой - in=287,76 Gb. Время их работы отличается на 10 секунд и никаких умных мыслей по этому поводу у меня не возникает. 17 Гб разница по входу, откуда?
written=11,76 и 13,08. Параметры UDP в скобках (85,51/106,9) в первом и (98,9/124) во втором. Что точно означают эти цифры надо бы распросить S0RRY :).
Файлов в закачках 170 в 1-м и 191 во 2-м.
Нагрузка от 1-го 106/169 Мб и от 2-го - 128/200 Мб.
incomplete равны.
ОК - 7,199 и 8,127 Гб разница ровно 1Гб за сутки.
rar - 5,568 и 6,346; zip - 1,042 и 1,182
Как и прежде основная разница в rar.
3,054 Gb GL в 86 файлах из всего 5,633 Гб в 131 файлах. Это первый 9В6.
3,805 Гб GL в 109 файлах из 6,429 Гб в 154 файлах. Это второй.
800 Мб разницы в GL rar, 180 в zip, остальное в djvu.

Пока только цифры. Никакие выводы в голову не идут :), может они и не нужны...

PS
Не зря говорят: "Утро вечера мудренее" Утром обнаружилась и вероятная причина разного in в бетаскаях. Может и разницы в улове. Виноват я сам и моя невнимательность
Удалять результаты не имеет смысла, просто надо сделать поправку на то, что в ini файле кроме разного таймаута по GL был разный таймаут и по ТСР. Не могу сказать точно повлияло ли это на in, по моим представлениям не должно бы, но все же - разница была и её надо отметить. Пусть даже на день позже
Итак для 1-го 9В6 ini выглядел так:
tcp_timeout=180000
#fragment. paket t/o
fp_timeout=2940
#glo timeout
gl_timeout=180000

для 2-го так:
tcp_timeout=600000
#fragment. paket t/o
fp_timeout=2940
#glo timeout
gl_timeout=600000

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

S0RRY (а именно так пишется правильно его ник) пока некогда, как он сказал "Начался сезон - надо деньги зарабатывать." Но тоже надеюсь что версия с исправленным nntp скоро выйдет как релиз и продвинется работа над торами или еще чем нибудь не менее интересным.

Таймаут для ТСР был выравнен с таймаутом для GL и, следовательно, увеличен для первого с 3-х минут до 10, а для 2-го до 20 минут, вместе с тем же параметром для ТСР.
Просто даю цифры что из этого вышло, а потом будем осмысливать.
1-й in=325Gb TSE=22 UDP=990 (101,15Гб/125,45Гб)
written=14,16Гб files=185 (8/3488 - 4185)
2-й in=345Gb TSE=20 UDP=1802 (117,9Гб/146Гб)
written=15,58Гб files=214 (600/3488-5619)
То что в окне ская в скобках, я тоже дал в скобках, для "бегающих" цифр дал усредненное.
Скорость записи на диск 9В6 показывает около 200кб/с, со второго чуть выше.
Нагрузка на память 85/101 Мб и 160/204 Мб, какая для какого догадаться нетрудно.На процессор до 17% в пике, держится 5-12% для каждого, у второго чуть выше. Это с открытыми окнами. Со свернутыми в трей - ОЗУ на треть меньше расходуется.
Почему то дисконты по разному считаются, уже второй раз заметил, странно для стримсплиттера.
ОК - в первом 7,763Гб во втором 8,496Гб - разница примерно в 730 Мб.
Почти вся в rar: 5,293 и 5,909 Гб (около 610 Мб, остальное в zip).
В 1-м GL=3,899 Гб в 94 файлах из 126. ТСР=1,394 Гб.
Во 2-м GL=4,206 Гб в 106 файлах из 140. ТСР=1,703 Гб
То есть половина прибавки пришлась на ТСР, половина на GL.
Если сравнить по объемным файлам, то во втором 209 Мб в ТСР и 135мб в GL, которых нет в 1-м. Кроме них, файлов от 90 мб и выше так же на 2 больше во втором.

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

Пока оставим в покое Радугу с 60Е, с её глобом и закачками, для которых не достаточно часового таймаута на обработку пакетов ТСР и GL. Закачки все равно массово становятся на вечный прикол, побитые ржавчиной дисконтов - и большие как корабли, и мелкие как прогулочные лодочки :). С чем это связано трудно сказать, но несомненно, это одна из особенностей Радуги на 60Е.
Попробуем сравнить рыбалку с разными настройками на более "спокойном" спутнике Астра-5А, который сменил на рыбацком небе звездочку Евразии 42Е. Нагрузки здесь малые даже с часовыми таймаутами и большим колличеством блоков для обработки.Глобакс присутствует, но в малозаметных колличествах.У меня здесь работает неразогнанная карта SS2, легко переваривая весь поток.
Два забега (сутки работы и второй чуть меньше) на транспондере 11733 для двух скайнетов 20а и 9В6 дважды показали небольшое превосходство бетаская. Постоянные отключения электроэнергии не позволили облечь это опережение в цифровой отчет,и улов был можно сказать никакой. Огромное преимущество (почти 2-х кратное) UDP над ТСР делало поток в 1-2 Мб/с бесполезным.
Потому, при первом же отключении электричества попробовал посмотреть второй транспондер, который пару недель назад был практически пуст. Оказалось не зря.Здесь, при почти таком же потоке, UDP равно ТСР, что уже хорошо.
Смена хилого транспондера на более перспективный для рыбалки в первую же ночь дала результат - закачанную к утру авишку и еще несколько в активных закачках на хорошей скорости. Более 100кб/с мне трудно припомнить на Евразии, а здесь увидел в первый же день. Периодически скорость записи на диск по показаниям бетки была до 500кб/с. Это первый рекорд, но обычно скорость колеблется от 150 до 250 Кб/с.
Теперь о настройках ini файлов. При малой нагрузке можно в пределах разумного напрячь систему и скайнеты. Знать бы еще эти пределы...
Скайнет 20а:

#таймоут для пакетов при дефрагментации IP
ip_timeout=3000
#Размер буффера для сборки фрагментированных пакетов ip
ip_defrag_buf_size=16K
#Управление перехватчиком глобакс
#хранить не более пакетов глобакс для одной сессии
#gl_max_blocks_wait=256
gl_max_blocks_wait=3000
#Таймоут для сессии ms
gl_session_timeout=3600000
#таймоут для канала ms
gl_channel_timeout=300000
# tcp/ip
mss=1500
tcp_timeout=300000

Для 9В6:

grab_links=0
# tcp/ip -20 minut
#tcp_timeout=600000
tcp_timeout=3600000
#fragment. paket t/o
fp_timeout=2940
#glo timeout
gl_timeout=3600000
#память для фраг пака
IP_MAXPACKET=32000
#максимально допустимое значение вирт. памяти
MaxVirtMemUsage=220000000
cache_scan=4500
cache_max_block=250k
cache_flush=2200

Вроде бы все что может влиять указал. Через 21 час показания 20а такие:
in=92,8Гб ТСP=46,3Гб UDP=47,8Гб GL=4,1Гб written=17,01Gb
Последний параметр в 9В6 - written=16,1Гб
Думаете бетаскай записал за 20 часов на 1 гиг меньше? И да... и нет.
20а в ОК 12,482 Гб
9В6 в ОК 11,613 Гб
Вы скажете: "Да,меньше!". А я загляну в incomplete.
В 20а там один файл 100мб, в 9В6 там 10 файлов на 1,311Гб. Прибавим их к содержимому ОК и получим цифру большую, чем в 20а. В большинстве битых файлов недостает около 1кб информации и почти все они имеют запас на восстановление. Но на этом сюрпризы не кончаются.
Часть из битых в бетке файлов находится в ОК у 20а... Дисконтов всего 2 за почти сутки и дело не в них.
Объяснения у меня нет.
Но есть интересное наблюдение. Вечером сразу после включения программ в работу и появления первых 10 закачек, скайнет 20а начало забрасывать унками (.unk файлами). Налетело их больше 2-х десятков, в бетаскае их не наблюдалось. Утром унки все исчезли, кроме одного в ОК.В винраре этот уцелевший yнк показал себя 4 партом 2-й части "секретных материалов" в mkv. В бетке он в таймауте на 92,75% с 3-мя вырванными кусками в первой трети закачки.
Отметим и содержимое в GL. В 9В6 таких файлов 9 на 760мб, все в ОК, почти все части многотомников.
В 20а их 7 на 670Мб.
Пришло по 3 авишки с фильмами в ТСР, к тому же с приличным содержанием, что редкость по нынешним временам.
После сортировки улова выяснилось, что бетка пропустила последний 8-й парт фильма "Воробей", а 20а целиком не заметил фильм 1,1гб. О его содержимом умолчу, может скайнет 20а и прав :)...


Для выводов пока время не пришло и если электрики его дадут, то итоги подведем через пару суток. А пока нагрузка на память озу/подкачка по диспетчеру. 20а - 24/36Мб и 9В6 - 12/15 мб. Проц у 2оа до 6%, а у 9В6 - до 2%. При этом запись на винт идет с бетаская около 350кб/с при потоке в районе 1,6Мб/с.