Обсуждаем проект Rosetta@Home.
Все вопросы задавать только после прочтения
FAQ по проекту Rosetta@Home
(обновлен 05.07.2020)

официальный сайт проекта
наша команда номер 528.
скачать BOINC клиент. (Windows, OS X, Linux, Android)
"Portable" версия BOINC клиента

Новости о борьбе с COVID 19 и о проекте в целом с оф. форума за март 2020 (спасибо Lecc)
Список научных достижений за последние 5 лет от 19.01.2019 (спасибо Lecc за анализ)

Альтернативная статистика:
1) BOINCstats;
2) stats.free-dc;

Соседние темы:
[TSC!] Наши успехи в Rosetta@Home
[R@H] Догонялки
[TSC!] Разбираемся с BOINC
[TSC!] Заготовки для FAQ BOINC
[TSC!] Выбор железа для F@H и R@H

Мы в Telegram - https://t.me/TSCRussia

Останови рассчеты, сделай копию папки C:\ProgramData\BOINC, переустанови BOINC в настройках при установке указав в Data directory каталог на другом носителе. После этого из бекапа замени его.

Triglav88 пасиба, этот вариант подходит. При установке возможность выбора я конечно же видел, но подумалось, что каталогами проектов можно рулить из настроек.

прикольная штука, спутниковую рыбалку чем то напоминает или торренты Задания заливаются пачками, 14к очков уже за два дня, правда не знаю на сколько значим этот показатель и значим ли вообще. И народу маловато - 171 человек на раздаче считают.

А может мне кто-нибудь объяснить почему по boincstats.com "RAC - средняя производительность в очках (согласно Rosetta@Home)" и "RAC - средняя производительность в очках (согласно BOINCstats)" отличаются ~ на 80к? Какой из этих показателей более "адекватен"?

P.S. У ПОЭМа таже картина, только разница между аналогичными значениями уже порядка 150к.

Добавлено спустя 34 минуты 4 секунды:
Судя по описанию в FAQe на самом боинкстате, их стата более точная нежели проектная.

[kane]Enforce
А они одинаковый временной интервал берут?

очень правильный вопрос - один обновляет раз в день, другие через 4 часа, есть и те, которые каждый час обновляют. Оф сайты проекта имеет без вариантов самый короткий интервал. А вот http://boincstats.com - именно тот, который показывает вчерашние сливы с обновлением в 12 часов каких. Так что сравнивать с http://boinc.bakerlab.org/top_teams.php просто некорректно будет

Боинкстат берёт 60-дневный период, а оффы хз.

Сказать что более точная некорректно. Это примерно как говорить, а какое среднее значение "лучше": мода? или медиана?

Основное отличие - у BoincStat RAC это простое среднее арифметическое скорости за последние 60 суток (или с начала счета для новых юзеров/машин, считающих менее 60 суток). Т.е. суммарные результаты(в очках) за 60 дней делить на 60. Соответственно после 60 дней неактивности падает полностью до нуля, выходит на максимум (после перерыва в счете) так же ровно за 60 дней. Для новичков только начавших считать это среднее арифметическое от начала счета.

RAC самого BOINC это не простое среднее, а средневзвешенная скорость. Период усреднения у нее стремится к бесконечности, но при этом вес убывает в 2 раза каждую неделю(на самом деле не дискретно скачком раз в неделю, а плавно пересчитывается при каждой успешной сдаче заданий). Т.е. скорость счета за последние 7 дней дает вклад 50%, скорость за предыдущие 7 дней (от 7 до 14 дней назад) дает вклад 25%, счет 3 недели назад 12.5% и т.д.
В результате в начале (после подключения/отключения счета) он меняется намного быстрее чем BS RAC, а в конце (по мере приближения RAC к текущим ежедневным сливам) все медленнее и медленнее.
Часто пишут что официальный RAC это среднее за 1 месяц, но это не совсем правильно - это упрощение. Но т.к. за месяц набирается около 94% веса, то для простоты объяснения можно и так считать что примерно за месяц.

Лично я считаю более адекватным и удобным BOINC RAC. Но BS RAC более простой и понятный показатель (особенно для новичков).

народ, я тут погонял кэш, по тестам кэша в AIDA разница между х44 и x40 множителем кэша существенной не выглядит вообще. Да еще для стабильности пришлось поднимать напругу на vcore и vrm, что отрицательно сказалось и на температуре, видел тут сравнение, прирост вроде как бы есть, но стоит оно того?
Просто если смысл есть, то думаю допилю найденный стабильный резалт, до логического минимума по напряжению, на котором есть стабильность.
З.Ы. boinc 7.4.36 x64

Добавлено спустя 1 час 28 минут 6 секунд:
полученный мной резалт таков:

По результатам я услышал мнение:

Поэтому этот вопрос меня и заинтересовал)

Там же не только в f@h тестировали, но и в других программах. Производительность падала только при превышении множителем кеша множителя процессора, до этого рост. ИМХО правильный алгоритм разогнать процессор до устраивающих параметров, а потом поднимать кеш до тех пор пока температура и напряжения позволяют и нет превышения значения множителя процессора.

ну превысить значения множителя цп все равно не получится - напруга не позволит. В моем случае, для стабильного разгона кэша до х44 (ЦП х47) множителя пришлось не только повысить напругу на vrm, но еще и vcore подкинуть (темпа++), а в результате я увидел неоднозначный результат, который вроде как и не стоит таких изменений относительно текущего полностью стабильного конфига... Поэтому думаю, что особого смысла в разгоне кэша нет, тут если рассматривать увеличение производительности, то лучше проц посадить на 48 множитель, правда это будет уже другой историей, да и необходимости в этом пока нет.

Kirito
Кеш можно х43 или х42 оставить, в любом случае лучше чем х40

А каким боком к разгону ЦП собственно Розетта?
Она даже как бенчмарк не сгодится, т.к. хотя ее скорость от разгона конечно тоже зависит, но вот на сколько именно % - фиг замеришь в отличии от F@H (где хотя бы можно поймать жабу того же типа и сравнить время на шаг).

Скорее вопрос был обратный, так как имелось в виду виляние разгона кэша на производительность вычислений. Дело в том, что увеличение производительности за счет разгона кэша с х40 до х44, согласно синтетике AIDA64 не только не существенное, но еще привело к увеличению латентности L2 кэша, пусть L3 и стал быстрее, что в сумме ставит под вопрос эффективность такого разгона (в конкретно приведенном примере). А с учетом того, что стабилизация потребовала увеличение vcore/vrin и как следствие температуры, мне и стал интересен вопрос о рациональности разгона кэша с точки зрения улучшения производительности в R@H. А если и говорить о % то тут речь о каких нибудь 1-2%, да и то если они вообще будут, ибо смутила меня эта латентность кэша...

Народ, подскажите такую вещь, недавно посмотрел логи выполненных заданий, иногда (довольно редко, но все же) попадаются кривые, в данном случае Outcome explain - Client error / Client state explain - Compute error. Как правило в таких заданиях CPU time (sec) меньше (различной степени) чем время Success заданий, соответственно начисляется только claimed credit. Конф разгона абсолютно стабилен, сначала думал, может косяки из за того, что использую комп при фоновом счете в 100% CPU, но проанализировав время возникновения таких ошибок данное предположение отпало, так как они возникали когда комп не использовался для работы. Так же был случай когда было несколько косячных заданий два подряд и еще через одно нормальное. Собственно вопрос - косяк в железе или это допустимо?
Еще интересно, чего это нас так мало на раздаче? Всего зарегистрировано не мало участников, а фактическое количество активных кранчеров за последние три месяца особенно и не изменилось. Политика партии по улучшению ситуации проводится?

Kirito
"Кривые" задания для розетты это нормально.

Ты наше место видел? Отрыв от преследователей? Спешить уже некуда.

Видел разумеется, и спешка тут не при чем Вопрос был немного другой, но да ладно)

Подскажите, r@h считается только на процессорах из-за особенностей алгоритма или из-за отсутствия у разработчиков ресурсов для gpu клиента?

googayo ну они объясняли раньше частыми обновлениями версии расчётного приложения. Программеры там криворукие, так что может оно к лучшему... Хорошо хоть жабы ЦП перестали дохнуть на полпути при времени счета 24 часа, как весной-летом прошлого года.