Boinc не переключается между заданиями - Страница 2 - Boinc не переключается между заданиями - Страница 2 - Форум

#11 · 11.06.2021, 00:30

Есть ещё один способ.

Каждому проекту можно с помощью файла настроек app_config.xml жёстко задавать максимальное количество запущенных приложений.

А с Gerasim@home у меня тоже проблемы были в плане переключения между проектами, он как-то странно реагирует на приоритет. Einstein@home вообще на CPU лучше не считать, очень долго одно задание, а очков мало; на GPU намного лучше.

Создаётся текстовый файл в папке проекта (например для Gerasima) c:\......\Boinc\Data\projects\gerasim.boinc.ru\app_config.xml :

<app_config>
<project_max_concurrent>2</project_max_concurrent>
</app_config>

И теперь Gerasim больше 2-х заданий одновременно запускать не будет, и не будет мешать другим. А время переключения в настройках BOINC manager можно поставить большим, чтобы лишний раз не дёргались.

#12 · 11.06.2021, 01:26

Цитата: zlodeck от 11.06.2021, 01:26
Если имеет место быть желание считать одновременно несколько проектов, то данные рекомендации

Цитата: AenBleidd от 10.06.2021, 12:14

Посему, я бы порекомендовал ничего не делать и дать BOINC выполнять свою задачу (а именно не профукать дедлайны по задачам), когда нужно - он сам сделает переключение между задачами.

Цитата: PinkFloyd от 10.06.2021, 14:13

Если душа требует, чтобы считалось несколько проектов, то включите несколько проектов и просто не мешайте BOINC делать свою работу.

В общем, короче говоря, поменьше заморачивайтесь. ?

являются абсолютно верными.

Иногда душа, правда, требует ~~упороться~~ разобраться, откуда там чего и с чем его как. Сразу скажу, что ниасилил, но кому интересно, то велкам под кат.

[spoiler title="Планировщик Boinc"]

Цитата 2-летней давности с форума британской UK BOINC TEAM:

-- Can anyone explain how the scheduling priority works in Boinc Manager?

-- No-one can explain how the Boinc scheduling works, not even the authors!

То есть объяснить это дело могут не только лишь все, мало кто может это сделать (создателей боинка тоже касается).

Каждому проекту боинк-клиент (процесс boinc.exe) назначает т.н. приоритет планировщика (scheduling priotity, SP). Максимальный приоритет - 0, минимальный - минус бесконечность. Значение приоритета можно посмотреть в боинк-менеджере, выбрав проект на вкладке "Проекты" и нажав кнопку "Информация" на левой панели.

Если активны несколько проектов, то загружаться задания будут у того, у кого приоритет выше.

Если проект считается, его приоритет падает, если не считается - растет. Боинк пытается выровнять приоритеты, давая задания тому, кто больше простаивал.

Через некоторое время (скажем, 10 дней) приоритеты устаканятся и тогда проекты начнут получать задания вместе, переключаясь через заданный в настройках интервал. Будут ли их задания считаться одновременно? Если хватает ядер у процессора - то да, могут, сам наблюдал такое.

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

Приоритеты для GPU-приложений вычисляются отдельно от CPU-приложений.

А вот как эти приоритеты рассчитываются - это не очень понятно. Все, наверное, знают что такое RAC - Recent Average Credit - это средняя производительность всех машин кранчера в проекте. Гораздо меньше народу что-то слышали про REC - Recent Estimated Credit - можно перевести как "оценочный кредит за последнее время". Это тоже средняя производительность, но уже конкретной машины. Если откроете файл client_state.xml, то в каждом проекте найдете значение, обрамленное тегами <rec> - это оно и есть. При всем сходстве в названиях разница между RAC и REC принципиальная - RAC (и для проекта в целом и для каждого компьютера) рассчитыватся сервером проекта, REC - компьютером участника. Так вот приоритет планировщика вычисляется на основе всего двух величин: REC и Resource Share. Последнее - это количество ресурсов, выделенных проекту (по-русски в боинк-менеджере "Выделено ресурсов"). Формул для вычисления приоритета видел две: одной 11 лет, другой - 9. Наверное, правильна более свежая:

Приоритет планировщика SP = - REC / Resource_Share

Отсюда вытекает, что

Проект считается - REC растет - приоритет падает в более глубокие минуса.

Проект стоит - REC падает - приоритет поднимается вверх к нулю.

Выделяем больше ресурсов - уменьшаем абс. значение приоритета, поднимая его вверх, меньше ресурсов - наоборот.

Собственно, это и есть та самая балансировка, про которую упоминал AenBleidd. И манипулировать здесь мы можем только количеством ресурсов, значение REC изменить вручную нельзя. А можно ничего не делать и просто подождать :))

Увы, получить конкретные правильные цифры приоритетов у меня не получается. Дело в том, что в формуле REC и Resource_Share - это не реальные цифры, а нормированные. Как выполняется нормировка - для меня загадка. Вроде бы просто на единицу - но не сходится.

[/spoiler]

Если имеет место быть желание считать одновременно несколько проектов, то данные рекомендации

Цитата: AenBleidd от 10.06.2021, 12:14

Посему, я бы порекомендовал ничего не делать и дать BOINC выполнять свою задачу (а именно не профукать дедлайны по задачам), когда нужно - он сам сделает переключение между задачами.

Цитата: PinkFloyd от 10.06.2021, 14:13

Если душа требует, чтобы считалось несколько проектов, то включите несколько проектов и просто не мешайте BOINC делать свою работу.

В общем, короче говоря, поменьше заморачивайтесь. ?

являются абсолютно верными.

Иногда душа, правда, требует ~~упороться~~ разобраться, откуда там чего и с чем его как. Сразу скажу, что ниасилил, но кому интересно, то велкам под кат.

Планировщик Boinc

Цитата 2-летней давности с форума британской UK BOINC TEAM:

-- Can anyone explain how the scheduling priority works in Boinc Manager?

-- No-one can explain how the Boinc scheduling works, not even the authors!

То есть объяснить это дело могут не только лишь все, мало кто может это сделать (создателей боинка тоже касается).

Каждому проекту боинк-клиент (процесс boinc.exe) назначает т.н. приоритет планировщика (scheduling priotity, SP). Максимальный приоритет - 0, минимальный - минус бесконечность. Значение приоритета можно посмотреть в боинк-менеджере, выбрав проект на вкладке "Проекты" и нажав кнопку "Информация" на левой панели.

Если активны несколько проектов, то загружаться задания будут у того, у кого приоритет выше.
Если проект считается, его приоритет падает, если не считается - растет. Боинк пытается выровнять приоритеты, давая задания тому, кто больше простаивал.
Через некоторое время (скажем, 10 дней) приоритеты устаканятся и тогда проекты начнут получать задания вместе, переключаясь через заданный в настройках интервал. Будут ли их задания считаться одновременно? Если хватает ядер у процессора - то да, могут, сам наблюдал такое.
Ну и разумеется, если задание не укладывается в дедлайн, то боинк запускает его вне очереди, посылая приоритет планировщика лесом.
Приоритеты для GPU-приложений вычисляются отдельно от CPU-приложений.

А вот как эти приоритеты рассчитываются - это не очень понятно. Все, наверное, знают что такое RAC - Recent Average Credit - это средняя производительность всех машин кранчера в проекте. Гораздо меньше народу что-то слышали про REC - Recent Estimated Credit - можно перевести как "оценочный кредит за последнее время". Это тоже средняя производительность, но уже конкретной машины. Если откроете файл client_state.xml, то в каждом проекте найдете значение, обрамленное тегами <rec> - это оно и есть. При всем сходстве в названиях разница между RAC и REC принципиальная - RAC (и для проекта в целом и для каждого компьютера) рассчитыватся сервером проекта, REC - компьютером участника. Так вот приоритет планировщика вычисляется на основе всего двух величин: REC и Resource Share. Последнее - это количество ресурсов, выделенных проекту (по-русски в боинк-менеджере "Выделено ресурсов"). Формул для вычисления приоритета видел две: одной 11 лет, другой - 9. Наверное, правильна более свежая:

Приоритет планировщика SP = - REC / Resource_Share

Отсюда вытекает, что

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

Собственно, это и есть та самая балансировка, про которую упоминал AenBleidd. И манипулировать здесь мы можем только количеством ресурсов, значение REC изменить вручную нельзя. А можно ничего не делать и просто подождать :))

Увы, получить конкретные правильные цифры приоритетов у меня не получается. Дело в том, что в формуле REC и Resource_Share - это не реальные цифры, а нормированные. Как выполняется нормировка - для меня загадка. Вроде бы просто на единицу - но не сходится.

atch отреагировал на эту запись.

#13 · 18.06.2021, 15:52

Всем спасибо за информацию - теперь многое прояснилось.

Для задается приоритет, так же задаётся нагрузка на ЦП, но где настраивается нагрузка на ГП?
Как я понял, на ГП может выполняться только один проект одновременно, и нет возможность задать максимальную нагрузку на ГП, скажем в 50% что бы шумела меньше и комфортно было оставить работать на ночь?

#14 · 18.06.2021, 16:21

На GPU можно понизить напряжение питания и рабочие частоты программой MSI Afterbarner. Нагрузка заданием, увы , не регулируется.

#15 · 18.06.2021, 16:22

Цитата: gureev_cps от 18.06.2021, 15:52

Как я понял, на ГП может выполняться только один проект одновременно, и нет возможность задать максимальную нагрузку на ГП, скажем в 50% что бы шумела меньше и комфортно было оставить работать на ночь?

Извне (не самим приложением, а приложением, его контролирующим) невозможно регулировать троттлинг видеокарты. Сама идея обработки на видеокарте состоит в том, что на нее отсылается порция данных, и ожидается ее завершение. Невозможно приостановить обработку порции данных, когда она уже заслана на видеокарту.

Поэтому уменьшить использование GPU нельзя, но можно увеличить, запустив более одного приложения на видеокарте одновременно (некоторые запускают по 4 для максимального использования ресурсов).

Gureev Evgeny отреагировал на эту запись.

#16 · 18.06.2021, 18:05

Цитата: Gureev Evgeny от 18.06.2021, 15:52

что бы шумела меньше и комфортно было оставить работать на ночь?

Поддержу ale4316 - андервольтинг очень неплохой метод снижения нагрева/шума, но нужно смотреть что за видеокарта. На каких-то видюшках это делается просто, через утилиты, а на каких-то картах нужно шить BIOS.

#17 · 18.06.2021, 18:19

Цитата: PinkFloyd от 18.06.2021, 18:05

Цитата: Gureev Evgeny от 18.06.2021, 15:52

что бы шумела меньше и комфортно было оставить работать на ночь?

Поддержу ale4316 - андервольтинг очень неплохой метод снижения нагрева/шума, но нужно смотреть что за видеокарта. На каких-то видюшках это делается просто, через утилиты, а на каких-то картах нужно шить BIOS.

Опишу свой небольшой опыт. Видюшка у меня RX480 майненая, поэтому стоковые частоты не держит, приходится убавлять чуть ли не на четверть... вот так:

Gureev Evgeny отреагировал на эту запись.

#18 · 22.06.2021, 17:10

Спасибо, что поделились опытом - попробую вечерком.

#19 · 22.06.2021, 17:31

Цитата: Gureev Evgeny от 22.06.2021, 17:10

Спасибо, что поделились опытом - попробую вечерком.

Незачто