Обсуждаем проект 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

Mad'Max Похоже у меня на ноутбуке тоже ошибки посыпались.

Это разве ошибки?
Тем более, что не только на вашем компе.

NGC7293 Надо было на страницу вперед пролистать. Уже закачались и посчитались новые задания.

Mad'Max Разобрался немного с ошибками на ноутбуке - действительно причина в видеокарте GT 630M, ошибки посыпались после того как обновил драйвер на версию 310.70. После отключения "печки" в биосе, когда в работе осталась только встроенка от интел, ошибки прекратились. Сегодня включил обратно и откатил драйвер на версию 306.97. Пока ошибок нет, правда досчитывались старые задания. Сейчас закачал новое, посмотрю что получится.

Добавлено спустя 11 часов 40 минут 8 секунд:
Новые задания считаются также без ошибок.

Да, то что проблема с драйверами от NV подтверждается. Причем какой-то компонент драйвера связанный с карточками на базе кеплер-чипов, как я предположение давно и сделал, как только появилось первое свидетельство что вытаскивание/замена кеплер карты на какую-то другую прекращает ошибки.
На оф. форуме тоже еще один человек нашелся, который так же включением/выключением NV видеокарточки(тоже из кеплер семейства) в БИОС ноутбука вызывал появление/прекращение ошибок розетты.
Пара человек впрочем жаловалась, что у них и на ATI картах, якобы такие же ошибки. Но никто примеров не приводил, так что не ясно, та же это была ошибка или там были какие-то другие не связанные с видеокартой. (благо глюков разных РАХ не занимать)

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

Добавлено спустя 16 минут 32 секунды:
2 ALL
Если у кого задания вида CDPK_aa_... начнут массово помирать (практически сразу после старта). То это "нормально", просто забейте - ошибки в самих заданиях, а умирают почти сразу же(обычно через 3-10 секунд после запуска), так что ресурсы не теряются.

GT 630M у меня в ноутбуке не кеплер. Это "хитро" перемаркированная Хуангом GT 540M на 40 нм техпроцессе. Маркетинг блин

Это все таки спорт. Попал в топ 50 участников и счастлив. Жалко, что на двух машинах. Но у основной еще не весь потенциал по разгону выработан.

Ждём в топ 20
Конкуренция рождает совершенство

Интересный эффект последнюю неделю наблюдаю.
Розетта вдруг почему-то стала в неск. раз меньше оперативки жрать. Вместо уже привычных 300-500 Мб на поток, вдруг аппетиты упали до 100-200 Мб.
Речь про физичискую память, полная (виртуальная, с учетом свопа) осталась примерно на том же уровне. А вот именно физ. памяти кушать стала в разы меньше.
При этом новых клиентов розетты не выходило, задания если судить по названиям идут в основно те же.
Итересный "глюк" - за компом намного приятнее стало работать, несмотря на 5 потоков розетты, которым иногда доступных 3.5 Гб ОЗУ вообще не хватало и начинался своп, а иногда и глюки. То теперь те же 5-6 потоков + весь пользовательский софт(в котором изменений не было) и минимум 1 Гб свободной ОЗУ остаются, а зачастую больше (1,3-1,7 Гб).
RAC тоже несколько подров (видимо за счет меньших потерь на своппинг и запуск заданий)

Никто такого же не замечал?

P.S.
Сейчас по потреблению памяти РАХ почти сравнялся с проетами из WCG рабоющими на базе софта розетты.

У меня по 460 мегабайт оперативной памяти в среднем и столько же в свопе на поток. Итого на 4 потока используется почти 2Гб. Несколько улучшился отклик системы, но я списываю на результат разгона процессора. Считать стал быстрее это я заметил.

У меня наоборот, задания вида "endo" до 800 мб оперативы занимают, "rb" до 600. Еще заметил, "endo" больше грееет - на ноутбуке считает один поток, привязанный ко 2 ядру - температура 78, на остальных заданиях 71.

У меня пока все по прежнему (FX-8120)
#77

А у меня ВНЕЗАПНО вдруг вот так примерно стало:
#77
Вот и думаю - чего бы это могло быть?
И можно ли такой полезный "глюк" как-нибудь воспроизвести на других машинах...
Я вообще похожее раньше уже несколкьо раз наблюдал - если параллельно с розеттой начать ресурсоемкие проги запускать, которые сожрут много физ. памяти, она начинала свопиться, и объем потряблемой физ. памяти резко снижался (иногда вообще всего до 70 Мб) - все остальное выкачивалось в своп. Но при этом все подтрмаживало, и счет замедлялся т.к. она постоянно что-то тянула из свопа обратно. И как только появлялась свободная память (когда ее сторонняя программа особождала) R@H практически сразу раздувалась в объеме обратно перетаскивая все свои данные из свопа в оперативку...

А тут такой же эффект, только теперь все в своп уходит "добровольно" (а не под прессом нехватки памяти) и обратно уже не вылезает(активного свопа тоже не наблюдается). И скорость счета не падает (даже наоборот подросла но это может и совпадение просто)...

Похожим образом ведут себя проекты работающие на базе софта Розетты из World Community Grid. На оф. форуме некоторые юзеры (я тоже среди них) на программеров "наезжали" - дескать, как же так получается, что вами же разработанный софт у других команд ухитряется жрать памяти в разы меньше? Ответа не было...
А тут оказывается и сама R@H может быть почти такой же скромной. Если захочет...

Добавлено спустя 9 минут:
Smoke77
Насчет Endo есть такое дело. Это "тяжелые" задачи сами по себе. Там одна моделька от 2 до 5 часов на хорошем проце считается (из-за этого у них время счета кстати скачет - с такими крупными моделями, в целевое время нереально попасть - будет либо меньше либо больше существенно).

Кстати уход в своп был и у меня. Но я клиенту обрезал процент используемого свопа до 30%, с целью уменьшить нагрузку на слабую дисковую подсистему.

Не трогал сутки машину. Как результат 1900 на двух хостах в сутки. Я думаю хороший результат.

В смысле, на каждом Q9400 такой результат?

Добавлено спустя 2 минуты 55 секунд:
OneginForte
А что не разгонишь? У меня был Q9400, 3,2 ГГц брал одной шиной без повышения напряжения (все на авто). Нормально разгонять я тогда не умел, да и смысла не было: для остальных задач хватало номинала.

Один Q9400 + старый E6300 в помощь. Q9400 и так разогнан до 3ГГц.

Как-то маловато. У меня на E5700@3,45ГГц, который работал примерно в режиме 21/7, было летом порядка 900-1050 очков в день. А тут в 3 раза больше ядер... Одну из причин наверно знаю - задания с тех пор стали менее вкусными.

Решил посмотреть, как там с памятью стало. Все по прежнему, розетта любит память
#77

Хотя конечно хороший вопрос, не дофига ли 4 гига оперативки для программки-скринсейвера?

Угу, у меня тоже опять как обычно память жрать начала. Безболезненный уход в своп с очень малым расходом физической оперативки закончился. В компе так же ничего не менялось, а ситуация усела 2 раза кардинально поменяться - сначала в одну сторону потом в другую(назад).
Значит это все-таки задания какие-то другие шли, хотя по названиям особо и не отличались.
Причем еще что заметил, те которые много жрут (как и обычно) объем физической и общей веделенной(виртуальной) памяти практически идельно совпадают (плюс-минус 1% максимум). Те которые жрали мало (в 2-4 раза меньше) по объему виртуальный были практически такими же, как те что жрали много из той же серии задач. Если не понятно выразил мысль, то можно на примере.
Допустим есть жаба серии Аxxx. Жрет около 450 Мб на поток.
Раньше (и сейчас опять к этому вернулось) распределение было таким - выделено 450 Мб, из них физической 450 Мб (т.е. 450 виртуальной = 450 физической + ~0 из свопа)
А потом вдруг пришли (перед НГ около недели продолжалось) другие жабы, вроде же этой же серии Axxx(судя по названиям), но физической оперативки едят всего порядка 150 Мб, но еще и 300 Мб из свопа (что дает те же ~450 Мб виртуальной).
Для жаб другой серии, допустим Bxxx используется 320 Мб на поток.
Обычно это 320 Мб виртуальной = около 320 физической и около 0 из свопа.
Но одно время (как писал выше) жабы этой серии ели всего около (70 !) Мб физической, при этом остальное добирая из свопа (так что общий объем вирутальной тоже было порядка тех же 320 Мб).
При том, что свободной оперативки оставалось много (>1 Гб) и активного использования своп файла не наблюдалось.
Выглядит это так, как будто есть где-то какая-то опция включена типа "запретить выгрузку неиспользуемых данных в своп". При этом если ОС начнет принудильно выгружать данные в своп (когда физическая тупо кончится(вообще) и другого выхода уже не будет), то как только появляется чуток свободной из свопа все сразу же перекачивается обратно в оперативку.

А тогда, когда малые объемы шли, соответствующая опция почему-то оказалась неактивной и данные не используемые в данный момент активно спокойно ушли в своп...
Возможно это при генерации заданий на сервере задается и BOINC получив на нее смотрит. Или сама программа(минирозетта) во время работы через Win API напрямую ОС сообщает, что ее данные нельзя в своп убирать...

Вот ведь как бывает
#77