DigiK-oz - Локальный кэш Налаштування

[Death]

DigiK-oz - Локальный кэш

С помощью этого менеджера решается проблема засыпания (ZZZ) клиента. Теперь клиент берет задания из локального КЭШа и соответственно у вас всегда есть в наличии задания для обработки (и 100% нагруженный EON-ом процессор).

Мини-ФАК по установке (Спасибо Death за объяснение)

1. К этому моменту у вас уже должен быть установленный и правильно работающий клиент EON, который приносит вам очки.
2. К этому моменту у вас уже должен быть установленный .NET framework (на ВИСТЕ и так есть, на ХР - проверяем есть ли?)
3. Идем на сайт автора и качаем последнюю версию менеджера (106 Кб) (ну или просим когото из команды шоб выслал по почте)
4. Скопировали EONstart.exe в директорию с уже установленным EONом.
5. Создали внутри папки с EONом еще одну папку с названием EON (менеджер сам попросит создать папку ту что ему нужно)
6. Скопировали в нее файлы client.exe, client.cfg, key.pub, AlCli.dll из папки с EONом.
7. Запускаем DigiK-oz. Идем в file ---> settings.
8. Maximum number of EON client to start - сколько запускать копий клиента при старте. Рекомендую ставить количество копий клиента = количеству ядер на процессоре.
9. CPU% to use - ставим 100% загрузка ЦПУ (иначе зачем тогда весь этот сыр-бор?).
10. Maximum number of crunching client максимум работающих клиентов = количеству ядер на процессоре.
11. After graceful shutdown: cleanup&exit - досчитать все задания в локальном прокси и выйти. Самое правильное решение, так что ставим тут галку. Остальные три галки ставим по вкусу (я не ставил ни одной).
12. Client settings Ставим галки напротив тех ядер процессора, которые мы хотим использовать (тоесть ВСЕ), а так-же выставляем приоритет процессов.
13. Proxy Вот, самое интересное в это менеджере. Естественно ставим галку "включить локальный прокси" и настраиваем его:
14. Maximum queue - количество заданий в КЭШе. Грубо прикидываем, сколько секунд считается одно задание, и насколько времени вы хотите обеспечить "автономную" работу клиента. К примеру если задание считается одну минуту и вы хотите 30 мин. автономность - то ставим значение "60" для двухядерного процессора.
15. Maximum number of requesters to start - Сколько "имитировать" клиентов, посылающих запрос? К примеру, если поставить значение "50" то сервер выдачи заданий проекта будет думать что у нас на машине запущено 50 клиентов (и соответственно, будет стараться обеспечить всех их работой). Поэтому это количество должно в 4-10 раз быть больше чем количество работающих клиентов.
16. Maximum number of reporters to start - имитация количества клиентов, которые будут отправлять задания обратно на сервер проекта. Ставим немного больше чем количество работающих клиентов.
17. On graceful shutdown, first empty proxy - при "правильном" завершении работы менеджера сначала будет очищен КЭШ и только потом будет стоп. Ставим тут галку, ибо это полезно для проекта, т.к. новые задания выдаются на основании уже посчитаных старых.

Примерную конфигурацию менеджера для 4-х ядерного процессора можно видеть на скриншоте:

 

запускай пока не поздно )))

http://www.free-dc.org/forum/showthread.php?t=16166

Fortunately, we are pretty safe from storms in Austin being so far inland. Ike didn't even bring rain here.

Our server, on the other hand, is less fortunate. It was in good hands with my postdoc, Lijun, and I think this new paper is a big step forward in the simulation methodology.

A new student, Rye, is taking over. We've purchased a new server to help cut down on the memory and communication problems. But I think we're settled on switching to boinc to solve our ongoing server issues. In that system, the issuing of work units is separated from any other calculations on the server, so that it is always responsive to client requests.

Our first new project will be to look at dynamics in high-temperature Ni alloys. These will be more expensive calculations, so we'll have to rescale the statistics.

In the long-term, we'll be switching the entire system to quantum calculations. There are still some fundamental issues to work out, but this will allow for modeling reaction dynamics at surfaces. This has great potential for designing new catalysts, particularly for energy conversion applications such as in fuel cell.

Це повідомлення відредагував nikelong: Mar 18 2009, 23:47

[nikelong]

DigiK-oz - Локальный кэш

С помощью этого менеджера решается проблема засыпания (ZZZ) клиента. Теперь клиент берет задания из локального КЭШа и соответственно у вас всегда есть в наличии задания для обработки (и 100% нагруженный EON-ом процессор).

Мини-ФАК по установке (Спасибо Death за объяснение)

1. К этому моменту у вас уже должен быть установленный и правильно работающий клиент EON, который приносит вам очки.
2. К этому моменту у вас уже должен быть установленный .NET framework (на ВИСТЕ и так есть, на ХР - проверяем есть ли?)
3. Идем на сайт автора и качаем последнюю версию менеджера (106 Кб) (ну или просим когото из команды шоб выслал по почте)
4. Скопировали EONstart.exe в директорию с уже установленным EONом.
5. Создали внутри папки с EONом еще одну папку с названием EON (менеджер сам попросит создать папку ту что ему нужно)
6. Скопировали в нее файлы client.exe, client.cfg, key.pub, AlCli.dll из папки с EONом.
7. Запускаем DigiK-oz. Идем в file ---> settings.
8. Maximum number of EON client to start - сколько запускать копий клиента при старте. Рекомендую ставить количество копий клиента = количеству ядер на процессоре.
9. CPU% to use - ставим 100% загрузка ЦПУ (иначе зачем тогда весь этот сыр-бор?).
10. Maximum number of crunching client максимум работающих клиентов = количеству ядер на процессоре.
11. After graceful shutdown: cleanup&exit - досчитать все задания в локальном прокси и выйти. Самое правильное решение, так что ставим тут галку. Остальные три галки ставим по вкусу (я не ставил ни одной).
12. Client settings Ставим галки напротив тех ядер процессора, которые мы хотим использовать (тоесть ВСЕ), а так-же выставляем приоритет процессов.
13. Proxy Вот, самое интересное в это менеджере. Естественно ставим галку "включить локальный прокси" и настраиваем его:
14. Maximum queue - количество заданий в КЭШе. Грубо прикидываем, сколько секунд считается одно задание, и насколько времени вы хотите обеспечить "автономную" работу клиента. К примеру если задание считается одну минуту и вы хотите 30 мин. автономность - то ставим значение "60" для двухядерного процессора.
15. Maximum number of requesters to start - Сколько "имитировать" клиентов, посылающих запрос? К примеру, если поставить значение "50" то сервер выдачи заданий проекта будет думать что у нас на машине запущено 50 клиентов (и соответственно, будет стараться обеспечить всех их работой). Поэтому это количество должно в 4-10 раз быть больше чем количество работающих клиентов.
16. Maximum number of reporters to start - имитация количества клиентов, которые будут отправлять задания обратно на сервер проекта. Ставим немного больше чем количество работающих клиентов.
17. On graceful shutdown, first empty proxy - при "правильном" завершении работы менеджера сначала будет очищен КЭШ и только потом будет стоп. Ставим тут галку, ибо это полезно для проекта, т.к. новые задания выдаются на основании уже посчитаных старых.

Примерную конфигурацию менеджера для 4-х ядерного процессора можно видеть на скриншоте:

[Rilian]

DigiK-oz - Локальный кэш

это бы в статью на сайт https://distributed.org.ua/index.php?go=Pages&in=cat&id=33