| Russian Team @ distributed.net |
| | заглавная | | что это | | кто мы | | этапы | | как подключиться | | общение | | программы | | ресурсы | | FAQ |
| | what the FAQ | | общие вопросы | | клиенты | | прокси | | сети |
FAQ: Клиенты
ПРИМЕЧАНИЕ: В большинстве случаев под словом "клиент" подразумевается свежая CLI-версия клиента для платформы Win32. В противном случае версия и/или платформа указываются отдельно. Q: Как установить клиента, чтобы он автоматически запускался при старте Windows и работал незаметно для пользователя? A: В командной строке набрать dnetc.exe -install Клиент пропишет в Registry следующую информацию: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices] "distributed.net client"="<диск:>\\<путь>\\dnetc.EXE -hide" Теперь клиент будет запускаться как сервис и начинать работать до login'а пользователя. Параметры запуска клиента можно при необходимости редактировать при помощи regedit. Например, если вам нужно, чтобы клиент стартовал автоматически, но показывал свою иконку в трэе - просто уберите -hide. Q: Когда клиент запущен как сервис под NT в режиме hide - работает ли он быстрее, чем если его просто запускать руками? A: Нет. Зато работает до логина. Q: У меня под NT dnetc -install не дает никаких результатов. Почему? A: dnetc -install выполнится только если у тебя есть права запускать и останавливать сервисы. Например, если ты Администратор. Q: Вроде как сделал dnetc -install, а все равно после загрузки приходится клиента запускать вручную (NT4 SP4). Где грабли? A: Control Panel -> Services -> Distributed.Net Client -> Startup... -> Automatic Q: Запустил клиента с параметром -hide. Захотел посмотреть, чего он уже насчитал - обломался. Как можно в таком режиме за ним следить? A: 1) Веди лог - в него и смотри. 2) Направь клиента на прокси, и смотри отчеты по нему. (удобно в случае сети) Q: Машинки на работе включены круглосуточно, а вот в инете сидят по ночам. Можно ли их заставить забирать/отдавать блоки только ночью? A: Можно. Вставь в .ini-файл следущие строчки под пунктом [networking]: dialup-watcher=active interfaces-to-watch=* последняя строка необходима, если для соеденения используется не только модем. Q: Что будет делать клиент, когда у него во входном буфере закончатся блоки, а связи с интернетом нет? A: Начнет считать случайные блоки. Q: Что такое случайные блоки? A: Это блоки, случайно выбираемые клиентом из пространства еще не просчитанных. Q: Как клиент знает, какие блоки еще не просчитаны? A: Загляни в .ini файл своего клиента. Там увидишь строчку "randomprefix=столько-то". Эта строчка отражает текущее количество блоков, просчитанных всем проектом. Она обновляется каждый раз, когда клиент или Personal Proxy, через которую он работает, соединяется с кейсервером dnet. Исходя из этого значения клиент и устанавливает, из какого множества блоков выбирать случайные. Есть мнение, что случайные блоки выбираются не из всех непросчитанных, а только из ~10% пространства, следующего за уже просчитанными блоками. Из-за этого повышается вероятность того, что один и тот же случайный блок может быть просчитан несколькими клиентами. Засчитан же он будет тому, кто отправит его первым. P.S. Как показывает опыт вероятость обсчета уже зачтенных другим блоков велика - около 60%. Q: У меня есть на примете контора с небольшой сеточкой, не имеющей выхода в интернет. Сам я появляюсь там редко, приблизительно раз в месяц. Стоит ли ставить туда клиентов, жующих случайные блоки? Ведь за месяц большинство из них может быть просчитано и отправлено другими... A: Ставить клиентов однозначно стоит: вероятность обсчета тех же блоков другими довольно мала. Посуди сам: ~10% пространства блоков весь проект dnet считает уже почти год. Кроме того, на эту сетку можно поставить Personal Proxy с большими буферами :) скачанных с dnet блоков и менять их раз в месяц дискеткой с единой точки вместо того, чтобы обходить десяток машин. Q: Мой клиент не имеет доступа к интернету. Связь - через дискету. В сутки он съедает около 100 блоков, а его надо обеспечить автономным питанием на 3-4 недели. Как сделать ему входной буфер побольше? A: Один из способов - слить несколько файлов по 2000 блоков, а потом несколько раз запустить клиента, каждый раз предварительно переименовав очередной из файлов в CHKPOINT.RC5 (или как он там у тебя называется). Клиент автоматом блоки из него перекачивает в buff-in.rc5 Другой способ - также слить несколько файлов по 2000 блоков, записать их на дискетку. принести домой, и, не перезапуская клиента, дать ему команду dnetc -import <drive:\\path\file_name>. И так несколько раз по количеству файлов. Клиент будет есть блоки из принесенных файлов и добавлять их в свой входной буфер. P.S. Клиент позволяет делать буфер до 2000 блоков! Q: У меня на машинах под Win32 работают старые 16-bit программы. Клиент, запущенный на такой машине, тормозит. Что делать? A: Попробуй максимально поднять idle sensitivity в properties 16-bit задачи. Должно немного помочь. Q: Есть ли какие программы, кроме tame, чтобы досовские приложения, пущенные под Win32, не загребали под себя все процессорное время, а отдавали часть клиенту? A: Под OS/2 ничего лучше tame нет. Под NT4.0 tame тоже нормально работает. Досовой задаче остается 8-10%, клиенту - все остальное. Q: Почему клиент, работая в фоне, съедает почти 100% процессорного времени? Не отбирает ли он время у других задач ? A: Если выражаться точнее, то клиент работает не "в фоне", а с наименьшим приоритетом. Т.е. если процессор не загружен более приоритетными задачами, то свободное процессорное время клиент отбирает под себя и безропотно отдает его любой появившейся задаче, даже скринсэйверу (скринсэйверы - давить!). Поставь какой-нибудь продвинутый таск-менеджер от третьей фирмы на Win95/98 и сам увидишь. Кроме того, в этом смысл существования клиента: он _должен_ съедать все остающееся процессорное время. А остается его чаще всего как раз процентов 90. :) Q: Как включить в клиенте под BSD поддержку многопроцессорности? A: Можно принудительно указать количество процессоров (через -config), если клиент не определяет автоматически. Можно также запускать несколько клиентов по числу процессоров. Q: А как работает клиент на многопроцессорном компе: каждый проц жует свой блок или все они переваривают разные части одного и того же блока? A: Каждый проц - свой блок. Q: Зависит ли скорость счета от размера пакета? A: Нет. Пакеты разного размера считаются с одинаковой скоростью. Большой размер пакета лишь ускоряет обмен с кейсервером за счет снижения оверхеда (подтверждение на прием/передачу пакета). Q: Зависит ли скорость счета от приоритета, с которым работает клиент? A: Как показывает опыт, практически не зависит. Особенно это касается Windows-систем, где так называемая "многозадачность" реализована очень криво. Q: Зависит ли скорость счета от правильного выбора клиентом ядра (core)? A: Да. По умолчанию клиент автоматически определяет тип процессора и запускает оптимизированный под него вариант ядра (core) - программы, которая, собственно, и производит рассчеты. Однако, иногда - довольно редко - процедура автоопределения ошибается и запускает ядро не для того процессора (прецеденты в Команде имели место с процессорами Cyrix и NexGen). В этом случае необходимо принудительно задать тип процессора через setup, что может привести к ускорению работы клиента (в нашем случае - до 20%). Q: Как можно оптимизировать работу клиента? A: 1) Мне все-таки оч-чень кажется, что было бы оч-чень неплохо указывать checkpointfile, в связи с тем, что иначе есть возможность долго-долго считать пакет(*), а потом в связи с каким-нибудь сбоем (типа выключения питания компьютера усером) его СОВСЕМ потерять (как я понимаю, клиент сначала считывает очередной блок в ПАМЯТЬ, потом там же его считает, время от времени - в настройках cktime=xx (default=5 минут) - сохраняя информацию в checkpointfile, а по default он пустой!, etc). Рапортую - пакетов 10-15 именно по описанной причине у меня потеряны для истории. В случае проставления checkpoint сам блок не теряется, теряется только время, прошедшее с последней его записи. Правда в этом случае, по-моему, запускать разные клиенты из одной директории будет не так удобно. 2) Насчет размера и количества пакетов - конечно, каждый решает это для себя сам - результаты, полученные по benchmark, ничего реального на данный момент не означают - но я, например, в последнее всемя всегда (кроме 386-х - там ждать 2 дня результата скучно) ставлю preferredblocksize=33, для Netware Client - preferredblocksize=31 (он больше, вроде бы, не понимает). Чем больше preferredblocksize, тем дольше считается один пакет (пакет "длиной" 2^33 в 32 раза больше чем "длиной" 2^28), соответственно реже выдается результат, но какая разница - скорость та же, блоков столько же? А принимается/отправляется он с такой же скоростью, как один маленький (124 байта=124 байта), так что время-на-линии/деньги-за-это экономятся. (*) Термин пакет используется в смысле "42 RC5 packets (217 work units) remain in buff-in.rc5". Q: Где можно взглянуть на исходники клиента? A: Исходники полноценного клиента недоступны. То, что раздают с dnet (http://distributed.net/source/) - это "test and benchmark client" (без сетевой части, поддержки конфига, etc). Q: Скачал новую версию клиента, конфиг оставил прежний. Клиент стал закачивать меньше блоков. Почему? A: С некоторых пор в конфиге указывается размер буферов в блоках, а не в пакетах, как раньше. Делайте буфера больше... Q: У меня локальная сеть. Поставил в установках lurk only, а он не работает. Где проблема? A: По умолчанию dnet ищет только модемы (PPP). Укажи в [networking] interfaces-to-watch=* и проблема исчезнет! Q: При сливе/закачивании блоков клиент выдал: Fetch::Bad request acknowledgement. Это что? A: Причин несколько: 1. Связь оборвалась (наиболее частый вариант - 99%). 2. Ошибка в буферных файлах (было у меня разок когда дискетку восстанавливал) (решается вырезанием блока из буфера: 8 байт кол-во блоков в буфере, затем по 124 байт на блок) 3. Почти фантастический - неправильно просчитанный блок при отправке (на глючных процессорах) distributed.net Russian FAQ |
|