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

Mad'Max
текущие задания занимают в памяти видика в распакованном виде чуть меньше 500мб максимум, т.е свободной в разы больше - не вижу смысла и причины гонять туда сюда все это дело..
насколько я помню у меня "недовес" по очкам т.к. сказать был примерно одинаков в % на всех моих 4 видиках на тех заданиях, т.е. что на х16, что на х4 одинаково - что противоречит теории про шину...
дополнительное падение на предпоследнем посте я бы скорее связал что там контролер шины в чипсете - тогда как у всех остальных в проце был

Скормите фахспаю лог, пожалуйста. Уж очень мне интересно что он скажет

Конфиг там такой:
Celeron 1000@1330 / 512MiB PC133 / Linux

GoLeM_LI
Скормил калькулятору. В "Preferred Deadline" укладывается.

#77

noname2, это linuxforge.net? У меня там таких заданий нет в списке

GoLeM_LI
"Load all projects" левый нижний угол.

noname2, спасибо! Ошибку понял, учту

sco01
Ну это уже к программерам вопрос, зачем они гоняют часть данных по шине, при возможности (в теории) запихать все данные видеопамять и использовать данные только оттуда, а CPU только для управления процессом. Может не хотят увеличивать объем использования видеопамяти, чтобы старые карточки с 512-768 Мб памяти могли продолжать считать. Может какое-то ограничение текущей реализаций самой архитектуры GPGPС.
Насчет встроенного контроллера - может быть и с этим тоже связано (но относится к задержкам на том же пути CPU<-->GPU).

Впрочем как вопрос как оказывается не особо актуальный - GPU проектов с большими моделями мало и все они еще в статусе беты. Так что пока не так важно. К моменту релиза может и найдут в чем конкретно узкое место и способ его обойти програмно...

Еще нашел, что же случилось с опцией регулировки нагрузки на GPU - почему получилось так, что ключики есть, но по факту не работает.
Это было в ответ админа форума на вопрос от кого-то из участников о возможности регулировки нагрузки на GPU .

Т.е. опцию такую ввели, добавили ключик и даже "ползунок" в GUI интерфейсе(аналогичный регулировке нагрузки на CPU). Но работала она плохо, регулировка очень грубая - типа N секунд поработала карточка с 99% загрукой, X секунд постояла с нулевой загрузкой. В смысле комфотра работы юзера это ничем не поможет. Максимум для чего может сгодиться - снизить среднюю нагрузку на карту в случае общего перегрева. Потому через несколько версий клиента опцию решили убрать (до момента когда/если придумают способ более плавной регулировки), ну а консольный ключик остался.

Верный способ "ушатать" камень карты, если следовать теории деградации процессора от постоянных перепадов температур.
Если теория верна, то, безусловно, правильно, что это убрали.

У меня, судя по статистике, со вчерашнего дня поплыли 807x на ГПУ, чо очень удручает, т.к. суммарный ППД сильно упал по сравнению с 762х.

У меня они уже дня три прут , 762х-е никак не ловятся

Sir_N_Drew imsm
До сих пор спокойно ловлю 762х, без всяких ключей, бигпакет любой.
п.с. помню, некоторые иронизировали над моим 6-дневным запасом ГПУ-жаб. Если что, на 2-3 дня мне сейчас его хватит.

Провел исследование по совместной работе SMP F@H и счета разных проектов на GPU ATI. Вся собранная статистика тут: [F@H] Статистика заданий #10446736

Ну какие выводы можно сделать.
1й и главный (впрочем, уже и раньше известный, правда, я думал что не настолько все плохо...)
Это что SMP ядро F@H вещь капризная и лучше бы ее вообще не трогать во время работы. Загрузка всего ~1 ядра из 6 обрушивает скорость счета почти в 2 раза, а по PPD даже больше 2х...
Попробовал ради интереса "прибить" процессы к ядрам (с 1 по 5 ядра процессора закрепил за SMP, 6е ядро за GPU). Особой разницы не заметил: счет на GPU немного замедлился где-то с 5560 до 5020 PPD (видимо потому, что он в пике кратковременно бывает и больше 1 ядра грузит - а тут ему ОС вылезти на соседние ядра не дает). Счет же на SMP немного ускорился - где-то с 7000 до 7300 PPD, хотя средняя загрузка процессора от SMP немного снизилась, т.к. SMP процессы не могли залезать в 6е ядро, в моменты когда там нагрузка от GPU клиента проседала. Почему в результате быстрее точно не знаю - видимо, за счет того, что GPU клиент не влезал на его ядра и не сбивал работу (накладные расходы от переключения потоков).
Но общей картины это не меняет, разница небольшая.

2й вывод (тоже в общем не новый, но опять-таки все хуже чем я думал)
С точки зрения очков при наличии приличного ЦП на ATI картах считать не просто неэффективно (зря потраченное электричество), а просто противопоказано: вместо прибавки в скорости, можно вообще еще и в минус уйти (т.е. CPU + GPU ATI вполне может выдавать даже меньше, чем SMP CPU отдельно, если ему ничем не мешать – в моем случае связка процессор + видеокарта дает ~12.5к PPD против 16к PPD на процессоре отдельно). Хоть какой-то смысл может иметь использовать только слабый проц + мощная видеокарта (тоже будет очень неэффективно, но хотя бы в минус не уйдет).

3й вывод
Из всего, что мы рассматриваем сейчас для счета на ATI картах работе F@H на процессоре мешает сильнее всех... сам F@H! (в виде своего же GPU ядра). Падения скорости счета от других проектов меньше.
Впрочем F@H единственный в этом эксперименте мог загрузить карточку почти на 100% нон-стоп.
НСС грузит тоже почти на 100%, но не постоянно (периодически небольшие паузы с 0 загрузкой - когда считает CPU часть).
POEM грузит равномерно но где-то на 50-60% (может и больше, но ему F@H мешает)
Но если кто-то вдруг все еще на ATI картах считает по схеме SMP + GPU на одном компе, то замена GPU проекта на другой, падения скорости на CPU части вызывать в большинстве случаев не должна. Скорее даже наоборот отдача от процессора увеличится. Если же карта простаивает, что отдача от CPU конечно существенно снизится, но меньше чем от счета самого F@H на GPU.

4й вывод
7й клиент при определении PPD по-прежнему косячит как и раньше. TPF судя по всему показывает правильное реальные (всегда примерно совпадало с тем, что я по логу вручную посчитал ), а вот PPD значения могут быть левыми.
Точнее не левые, я вычислил, что за ерунду он там показывает. Это не глюк какой-то, а просто логика у программеров эту функцию писавших несколько странная:
PPD определяется как сутки/(TPF*100)*прогнозные очки текущей жабы.
Все вроде бы правильно? Вот только TPF учитывается текущий/мгновенный (за последние несколько шагов непрерывной работы), а вот прогнозные очки за жабу с учетом пауз в работе клиента (т.е. время счета не как TPF*100, а прогнозное время сдачи - время получения жабы). По отдельности все правильно, но когда эти два значения используются в одной формуле может получаться ерунда.
В результате если счет шел без пауз PPD будет таким же, как в калькуляторе. И на жабах без бонусов (т.е. GPU) тоже как в калькуляторе, т.к. от перерывов в расчетах на безбонусных жабах очки не падают.
А вот если паузы в процессе счета были и задание бонусное, то будет не мгновенный PPD, а какая-то ерунда. Но зато и плюс есть – 7й клиент PPD определяет очень быстро, ему не нужно ждать несколько полных фреймов шагов как в FAHSpy. Похоже он напрямую с ядром общается и то ему сообщает промежуточные результаты (а не только 100 точек на жабу через логи).
Надо бы поставить последнюю самую свежую версию 7го клиента и посмотреть не изменился ли там порядок расчета. Если нет, то можно эту информацию в FAQ по 7-му клиенту добавить.

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

А как дела обстоят с линейкой ati 7900? Наверное стоит потестировать, ибо во многих проектах boinc они отъедают от cpu ничтожную долю.

chlp
В смысле как 7ххх ведут себя при счете в F@H?
Не знаю как там насчет нагрузки на процессор, но по результатам на самом ГПУ клиенте с 7й серией карт все совсем плохо. F@H пока не умеет на ней нормально работать:
[F@H] Статистика заданий #10378490
Более-менее нормально работают только 5ххх и 6ххх карты. На 7ххх криво работает, а поддержку старых (4ххх и ранее) прекратили.

Научи, как делать запасы 762х?
Чем больше 762х достанется команде - тем больше 807х достанется врагам = дабл профит!
А то 807х какие-то совсем странно безрадостные - PPD на 560Ti 448cores@1730 чуть меньше, чем на просто 560ti 384cores @ 1660, у первой и ядер больше и частота выше, но PPD - меньше!
Ладно оно просто минус 8к на GPU делало, так оно ещё и с SPM 12 поточника 5к снимает, если комп не трогать, а если трогать - так 8-10к от обычных SMP в минус.
Хрен бы с ним, если б они хотя бы SMP не просаживали, а то чуть браузером пощёлкал - фигакс минус 10к - "Эй, кажется, у вас 2 ядра отпаялись, превед от Стэнфорда, бггг))".
Опять мудрят они там, то ли из температуры GPU стали PPD рассчитывать, то ли из потребления энергии GPU.
PS: advmethods не стоял, вчера как попёрли 807х - 2е прожевал и в GPUGrid ушёл.

economist2000
Убрал -advmethods, пришла 7623

Jeepster
Консервирую жаб примерно так:
#77
На компе создается 14-15 папок с ГПУ-клиентом. В конфигурации клиента для каждой папки присваивается свой machineid. Всего, для одного компа может быть до 16 шт. machineid, один-два я отдаю для процессорных клиентов, остальное - для карточки.
Остальные настройки ГПУ-клиентов, как правило делаю одинаковыми, хотя такое обилие клиентов позволяет сохранять для разных целей разные конфигурации, чтобы потом не менять. В extra_parms также прописываю ключ -oneunit для всех клиентов, жабы в которых будут храниться в запасе (все, кроме одного, считающего постоянно). Далее запускаю 1-й клент, закачиваю жабу, дожидаюсь начала ее счета (выхода на 0%), прерываю счет. Закачиваю следующую жабу и т.д.
На жабах, шедших год назад, можно было по 2-3 жабы на одной карточке одновременно запускать, что существенно экономило время на "засолку". Задания 762х капризные, вылетают, слетают дрова, поэтому запускаю по одному, зато у них огромное время на счет выделяется, почти 38 дней желательное время, и более 48 дней - дедлайн.
Далее, при появлении невкусных заданий досчитывается полученное невкусное и запускаются клиенты с законсервированными жабами. Сидеть возле компа все время не требуется, счет прекращается автоматически и клиент выгружается, а запуск следующего клиента осуществляется с помощью какого-нибудь менеджера. Время на шаг известно, спланировать расписание запуска не сложно. Для моих карточек время счета 762х, к примеру, чуть меньше 12 часов.
Да, требуется повозиться. Но терять треть производительности компа из-за прихода менее продуктивных жаб, грузящих процессор к тому же, я не хочу. Для того, чтобы сделать комп более производительным традиционным путем апгрейда тоже ведь приходится повозиться, но это мало кого смущает.

Может задание "неправильное"? Раньше было всё не так плохо. Ну, относительно результатов 5-й и 6-й серии - http://foldingforum.org/viewtopic.php?f ... 30#p203789

Mad'Max

давно всем считающим ФАХ известный факт

я на 200% уверен что отдав видику 1 поток ты забыл поменять кол-во потоков на процессоре...
Т.е. ставь smp 5 и привязывай именно эти ядра с ЦПУ + привязка 6 к гпу. все это с ограничением по кол-ву ядер нужно делать (через winAFC например)
вот тогда будет все нормально

p.s. Просто СМП считает так - скорость ВСЕХ ядер равно скорости самому медленному - т.е. у тебя все 6 ядер считают как то просаженное...

Всех с прошедшими праздниками!

Насколько велика вероятность, что задействуя четыре физических ядра процессора из четырёх, исключив Hyper-threading повысится скорость счёта (про то, что не нулевая не предлагать )?