Обсуждаем проект Folding@Home.
Номер нашей команды: 47191
Страница регистрации в проекте F@H: https://apps.foldingathome.org/getpasskey Обязательна для получения бонусных очков
По вопросам работы универсального клиента обращайтесь в соответствующие ветки:
Универсальный (SMP+GPU) клиент v.7
Folding@Home под Linux
Статистика заданий и рекорды команды: [F@H] Статистика заданий
В этой ветке все о мониторинге клиента FAH http://forums.overclockers.ru/viewtopic ... 1&t=122378
Статусы основных серверов F@h: https://apps.foldingathome.org/serverstats
Список текущих проектов: https://apps.foldingathome.org/psummary?visibility=ALL
Статистика команды на сайте extremeoverclocking.com: https://folding.extremeoverclocking.com ... s=&t=47191
Статистика по общему количеству CPU\GPU, мощности проекта: https://stats.foldingathome.org/os
Статистика по отдельным картам и процессорам в проекте: https://folding.lar.systems/gpu_ppd/overall_ranks
Официальный форум проекта: https://foldingforum.org
Мы в Telegram - https://t.me/TSCRussia

Surg30 Без НТ скорость счета будет меньше.

Surg30
Не поверишь, но нулевая отрицательная.

Спасибо Комрады!

Сейчас они у меня то приходят, то не приходят. Хотелось бы постоянства

Sir_N_Drew
7-й клиент? Попробуй на 6-й, без ключей вообще. Кстати, пасскей у меня указан.

На половину машин идут одни, на половину - другие, не зависимо от клиента и наличия пасскея, без ключей.

что за новый клиент такой?

Humorman
Странно. На 8057 хотя бы ключи влияли, кроме удачи...

Добавлено спустя 1 минуту 29 секунд:
AlexB
Новый - это какой?

7.2.9 - я такого ещё не видел...
считал раньше только на консольном

AlexB
7-й клиент уже года 2 как есть, но мне больше консольный нравится.

economist2000 я ещё с прошлого года на 6 сижу

Да, 7-е клиенты начали склоняться к 807* заданиям.
AlexB Седьмой очень приятен во многовидюшечной (sic!) конфигурации.

Всем привет! Камрады, возникла необходимость на паре машин с W7x64 заюзать nnCron для гашения фолдинга при открытии таскменеджера. Скачал последнюю версию крона, но в процессе танцев с бубном выяснилось, что именно с 64-битной семеркой у крона проблемы (в частности, люди пишут, что крон видит не все процессы). На форумах были какие-то советы, как это обойти, но че-то у меня ничего не вышло. Может, кто-нибудь решил проблему, и поделится со мной готовым рецептом?

imsm
хочешь именно останавливать фолдинг или скрыть процесс из таскменеджера тоже пойдет (уже не кроном, естественно )?

Надо именно остановить, чтобы загрузка проца стала 0%. А то наоткрывают мульен окошек разных, потом ищут, что тормозит - ага, процесс FahCore_a3 жрет 100% проца...

imsm
ну а если не будет процесса FahCore в списке?

Biker Но загрузка проца 100% останется, боюсь, начнут ковыряться вплоть до переустановки системы
Хотя, можно попробовать. Если скажешь, как это сделать )

imsm
да, общая загрузка 100% остается, что прикольно
ProcessHide

Вот тут я ошибся. На деле никакой постоянной связи у клиента(ФАХконтрол) с ядром в 7м клиенте не появилось. Точно так же реальные обновления только раз в фрейм (т.е. либо просто по логу работу отслеживает ну либо "сеансы связи" совмещены с записью в лог). Ну а быстрое и частое обновление статистики в FAHcontrol - это на деле банальная интерполяция/экстраполяция на основе предыдущих записей в логе.
Для интереса (правда проверял другое - это случайный побочный эффект) остановил (поставил "на паузу" не прерывая работы) счет одного из 6 потоков SMP ядра (средствами ОС).
Расчеты при этом по факту остановились, т.к. без сихронизации между потоками счет SMP не возможен. Правда остальные 5 потоков так и продолжали 5 ядер по полной грузить не производя никакой полезной работы.(в чем можно убедиться по детальному логу самого ядра в рабочей папке)
Но 7й клиент продолжал бодро увеличивать % выполнения жабы и немного обновлять другие циферки не замечая, что по факту счет давно застопорился. Так 10% жабы (10 фремов) и занимался экстраполяцией. Только потом когда я снял паузу с 6го потока и ядро закончило очередной фрейм считать и сделало запись в лог, клиент заметил что работа за это время почти не продвинулась, откатил прогресс выполнения жабы на 10% назад, пересчитал TPF, PPD и т.д.

Добавлено спустя 47 минут 38 секунд:

Задание тоже самое. По крайней мере проект один и тот же и там и там - 11293. Если только конкретный экземпляр жабы как-то криво сгенерировался...
Но скорее всего дело не в жабе, а в новых дровах AMD в которых обновляли(добавляли новые фичи)/оптимизировали OpenCL. Что дало некоторую прибавку в скорости счета в других проектах РВ на 7ххх картах, но в F@H обычно наоборот вызывает сильное падение скорости.

Но то, куда ты ссылаешься(на старых драйверах, с которыми F@H лучше дружил) это разве "не так плохо"? Там ~8500 PPD с топовой карточки последнего поколения -HD 7970.
Это ужасный результат не только относительно NV карт, но даже относительно предыдущих ATI карт. Для сравнения моя 5750 (которая по железу даже на 1/3 от 7970 не тянет) выдает 5000-5500 PPD.

А вот в вышедшем новом бечмарке ФАХ (в котором среди прочего часть кода для будущих OpenMM GPU ядер обкатывается/проверяется) 7ххх карты вроде относительно неплохо работают: [F@H] FAHBench - тест скорости видеокарт в Folding@Home (официальный F@H GPU benchmark)

Добавлено спустя 1 час 26 минут 25 секунд:

А я люблю все самостоятельно изучать/проверять.
И всем-ли? Вот буквально между нашими постами Jeepster вклинился с удивлением/негодованием, что загрузка даже 1 ядра строронней (помимо SMP потоков) работой сильно сбивает скорость SMP счета.
И регулярно такие же вопросы в обсуждениях всплывают. Если это давно и всем известно, это должно быть FAQ по ФАХ. Что для вариантов счета SMP+GPU (и особенно если плюс к этому еще и юзер за компом частенько объявляется и тоже проц немного загружает какими-то своими прогами) большая скорость скорее всего будет достигаться если SMP ядру -1 (или даже может быть -2) потока сделать.


Не забыл, а наоборот специально разные варианты проверял и выложил. Как с со сменой кол-ва потоков у SMP так и без. Чтобы сравнить скорости в разных вариантах.

Но по умолчанию (без тонкой настройки, которой большинство не занимается) все работает как раз так - СМП продолжает считать на всех доступных потоках, параллельно считается CPU часть от видеоядра. Например после установки 7го клиента(кот. теперь финальный и основной) имеем именно такую ситуацию.
А в результате скорость резко падает. На NV карточках это еще не очень сильно заметно (хотя зависит еще и от задания), а на ATI вообще жестко (хотя для ATI в самых последних выпусках 7го вроде планировали автоматическое резервирование 1 потока сделать...).

То, что скорость по самому медленному потоку выравнивается это я знаю. Т.к. остальным приходится "притормаживать" ожидая синхронизации с отстающим. Так вообще все SMP работают. (Правда в случае с F@H "ждущие" потоки при этом не снижают нагрузку на процессор почему-то)
Правда никакого 1 выделенного "просаженного" ядра в этом случае нет. "Просаженное" ядро было бы если вручную привязать потоки к ядрам, но при этом не уменьшить кол-во потоков в SMP, а потом запустить к ним в добавок GPU клиент. Если ручками не вмешиваться, то по умолчанию при ситуации 7 активных потоков на 6 ядрах (или 5 на 4х ядерном и т.д.) ОС начинает потоки по кругу по ядрам перебрасывать и обеспечивает более-менее равномерное усредненное распределение ресурсов между ними. Но вот видимо от этого активного гоняния процессов по ядрам скорость SMP резко и падает. А у 7 однопоточных процессов такого эффекта нет (падение скорости происходит примерно пропорционально отобранным ресурсам)

P.S.
А SMP F@H сейчас нормально с нечетным кол-вом потоков работает? Раньше помню часть заданий на нечетном кол-ве потоков глючили. Да и 7й клиент говорит что число потоков SMP слота дожно быть кратно 2(хотя принудительно поставить дает и нечетные)...

Mad'Max
Было несколько заданий которые валились на старте, но я тогда на 7 потоках больше полгода считал и то все ОК было (клиент после пары попыток качал др задание)
Сейчас насколько я знаю таких заданий нет