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

[Death]

http://www.pubquizcentre.nl/DigiK-oz/dceon.aspx

можно неплохо рвануть вверх.

EONstart

Running multiple EON clients was a pain in the ass....UNTIL NOW! I wrote a small program that'll start as many EON clients as your PC's memory will allow. You may have to experiment a bit to find the optimal setting.

To use this program, you'll need the .NET framework. It is included in VISTA, and you can download it for XP at microsoft's website.

First, make sure you have EON installed, and that you have succesfully returned at least one result.

After that download EONstart.exe (if you have problems downloading it, try here ) Copy it to a directory on the system you want to run EON on. In that same directory, create a directory called Eon. In that Eon directory, copy the files client.exe, client.cfg, key.pub and AlCli.dll from the directory the EON client is installed in.

Next, just run EONstart.exe, specify the number of clients to run (carefull, it'll use lots of memory if you set this number too high). Try starting with 50 clients. If your PC survives, simply increase the number of clients untill your PC starts complaining or is using excessive paging file. Decrease the number of clients by 10 or so and that would be about the maximum number of clients you can run. You could also decide to enable the local proxy, in that case starting just 5 to 10 clients will be sufficient, since the proxy will handle the fetching and reporting of work.

Suggested settings : 5 clients maximum, 5 clients crunching, enable local proxy, 8 requesters, 4 reporters, queue size 60 minutes, and clients connect to local proxy.

That's it! See your EON scores rise above anything you ever imagined!

October 15, 2008 : Version 0.5.0 released

Fixed another reported "decimal" bug again...

October 13, 2008 : Version 0.4.9 released

Got a report of a crash with the message "value to large or to small for decimal" again. I thought I had fixed al those...Apparently not! I fixed another possible occurence of this one and hope this is the last one. Problem with this one is, I can't reproduce this problem on my systems, so there just might be another one lurking.

October 12, 2008 : Version 0.4.8 released.

Fixed a few minor bugs, and raised the maximum number of requesters/reporters to 100 each. Use with care though, expecially the number of reporters directly influences the upload of your internet connection (8 reporters will use about 1 Mbit upload capacity).

October 4, 2008 : Version 0.4.7 released

Finally, I tracked down the problem which plagued all releases since the proxy was introduced (0.4.0) with hanging threads, threads which had ended but still showed up as active, etc. This will make sure you actually have the number of requesters/reporters running that is shown in the status display. No more excessive threads, no more problems with 0 reporters running where a (much) higher numer is displayed, causing the buffer to run empty. And also very important : no more enormous headache caused by lengthy debug sessions for me :-). I suggest everybody upgrade to this version, since it also eases the burden on the eOn server caused by the hanging receive/send requests.