Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Проект MD@home можно считать открытым. 24.11.02 01:27 Число просмотров: 1917
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
Дмитрий! Большое спасибо за аннонс (без шуток и двойного толкования).
Я действительно весьма признетелен!
|
|
<dnet>
|
Проект MD@home можно считать открытым. 23.11.02 22:53
Автор: Konstantin <Konstantin Leontiev> Статус: Member
Отредактировано 24.11.02 01:19 Количество правок: 4
|
Ну вот! Можно считать дипептиды.
Официально объявляю проект открытым.
Не все из важных замечаний мы учли в клиентской части.. Сейчас идёт разрабока следующей версии клиента. Но и эта уже удовлетворяет многим из предявленных её требованиям.
В следующей версии:
1) Сворачивание в трей.
2) Инсталляция как сервис в WinNT/2K/XP.
Дополнительные подробности см. на форуме http://distributed.org.ru/
ссылка: http://www.moldyn.ru/
http://www.moldyn.ru/
|
|
Точно? 25.11.02 17:28
Автор: Deviator <n/a> Статус: Member
|
решил потестировать клиента, запускаю - получаю:
-----------
Trying to initialise and run calculation thread:
================= Distributed Caclulations =================
DNet_Thread: runing get/send thread.
Server WWW.MOLDYN.RU say that no WU's available now.
DNet_Thread: stoped get/send thread.
-----------
версия: 1.15.1a
3 разА запускал, PHP минуты 2 покряхтит и клиент встаёт с вышеприведённым сообщением.
типа, вопрос возник: "кто виноват и что делать?"
|
| |
У меня так было, пока GUID не прописал 25.11.02 18:40
Автор: Kost <Пробки Москвы> Статус: Elderman
|
> решил потестировать клиента, запускаю - получаю:
> -----------
> Trying to initialise and run calculation thread:
>
> ================= Distributed Caclulations
> =================
>
> DNet_Thread: runing get/send thread.
> Server WWW.MOLDYN.RU say that no WU's available now.
>
> DNet_Thread: stoped get/send thread.
> -----------
1) user_guid= не забыл прописать?
2) что в distributed.log?
|
| | |
обижаете :) 25.11.02 22:56
Автор: Deviator <n/a> Статус: Member
|
|
|
| |
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 18:07
Автор: Night Knight [HZTeam.msk] <George Fedosejev> Статус: Member
|
|
|
| | |
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 20:47
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
|
Они не сколько не должны сказываться на то что работает сейчас. Более того мы это наблюдаем. Т.е на всех машинах на которых мы это тестируем проблем нет.. Надо смотреть конкретно distributed.log и client.ini
|
| | | |
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 23:00
Автор: Deviator <n/a> Статус: Member
|
> Они не сколько не должны сказываться на то что работает
> сейчас. Более того мы это наблюдаем. Т.е на всех машинах на
> которых мы это тестируем проблем нет.. Надо смотреть
> конкретно distributed.log и client.ini
похоже, он через мой роутер не могет прорваться, вот сейчас из дома (директом по модему) взял блок и чего то начал шуршать, завтра попробую время найти - пошарить по логам прокси. кстати, невредно было бы иметь возможность конектиться через SOCKS4, он аутеитефикации не требует и портами на роутере в нём проще рулить
|
| | | | |
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 26.11.02 00:00
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
> > Они не сколько не должны сказываться на то что
> работает
> > сейчас. Более того мы это наблюдаем. Т.е на всех
> машинах на
> > которых мы это тестируем проблем нет.. Надо смотреть
> > конкретно distributed.log и client.ini
>
> похоже, он через мой роутер не могет прорваться, вот сейчас
> из дома (директом по модему) взял блок и чего то начал
> шуршать, завтра попробую время найти - пошарить по логам
> прокси. кстати, невредно было бы иметь возможность
> конектиться через SOCKS4, он аутеитефикации не требует и
> портами на роутере в нём проще рулить
Как только изучу спецификацию SOCKS4 - сделаю. Если поможете или подскажите библиотеку сделаю быстрее.
|
| | | | | |
проблемы 26.11.02 10:04
Автор: Deviator <n/a> Статус: Member
|
> Как только изучу спецификацию SOCKS4 - сделаю. Если
> поможете или подскажите библиотеку сделаю быстрее.
это давайте отложим, поскольку есть куда более существенные проблемы, да и помошник я в этом почти никакой - моё дело правильно настроить уже готовое.
Логи отослал на мыло (кот. указано для этого), а впечатления помимо... - это, конечно, никакой не релиз-кандидат, это почти полноценная альфа...
Максимум, что удалось добиться в рабочей сети - скачать входные блоки. Даже при наличии полных входных буферов, клиент запускает PHP (!), мало того, это же происходит при указании работы только с локальными буферами (!), т.е. на настройки клиент просто не реагирует (?).
Если соответствует действительности сообщение: http://www.bugtraq.ru/cgi-bin/forum.cgi?type=sb&b=1&m=65128 о размере выходных буферов, то с софтом, вообще, можно не торопиться - трафик в размере >1Gb в мес. ни для меня, ни для большинства сетевиков просто нереален. Что бы быть реальным, он должен быть, хотя бы, в 50 раз меньше и то это много, но хоть как то представимо. Иначе проект попадёт исключительно в разряд курьёзов, а его имя, боюсь, станет нарицательным.
Возвращаясь к началу всей дискуссии по теме, всё женастоятельнорекомендую изучить опыт уже имеющихся проектов, как успешных, так и нет - что считать успехом, каждый решает сам. MoDyp пока, гораздо больше похож на F@H и аналоги, чем на DNet.
|
| | | | | | |
проблемы 26.11.02 18:26
Автор: StR <Стас> Статус: Elderman
|
> каждый решает сам. MoDyp пока, гораздо больше похож на F@H
> и аналоги, чем на DNet.
Он и не может быть похож на днет... класс задач совершенно другой...
|
| | | | | | | |
я имею ввиду похожесть подходов, а не внешние признаки 26.11.02 19:12
Автор: Deviator <n/a> Статус: Member
|
|
|
| | | | | | | | |
Что _именно_ Вы имеете в виду под выражением "такие же подходы"? 26.11.02 20:23
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
|
|
| | | | | | | | | |
подходы + 27.11.02 00:03
Автор: Deviator <n/a> Статус: Member
|
Под подходом, я подразумеваю, в первую очередь:
- способ организации проекта (т.е. что является исходной точкой), для проектов SETI, F@H, MoDyp это некая прикладная задача, которую хотелось бы решить до того, как её решение потеряет смысл ввиду старения вселенной. D-Net шёл с другой стороны, по принципу: "давайте организуем механизм, позволяющий раскидать решение сложных задач на незанятые процессоры, а заказчики найдутся" (естественно, я немного утрирую, но только немного);
- кто организует проект, для D-Net это люди решившие заниматься _распределёнными вычислениями_, "по барабану" какими, остальные проекты организовывались "заинтересованными лицами" (опять же с долей утрирования);
- "целевая аудитория", т.е. кого предпочитают привлекать организаторы в качестве доноров, D-Net "целится" в "скучающих сетевиков", остальные в "сознательных энтузиастов" (проявляется это, в первую очередь, в способе отображения процесса работы софта).
БОльшая часть остального вытекает из вышеперечисленного: это и "фантики и бантики" у всех клиентов, кроме D-Net'овского, и наличие единственного полноценного прокси, а так же клиента под платформы про существование которых я, к примеру, узнал из списка доступных клиентов... (но уже наоборот, только у них), и способ ведения логов и стата, и мотивация участников (полезность vs азарт)... Т.е. D-Net во главу угла ставит принцип: "входить тихо и быстро, не высовываться и не мешать тому, что работает, отваливать по первому требованию не оставляя следов", остальные этим похвастаться совсем не могут.
Собственно, дальше говорить нет смысла - это уже следствия. Естественно, что ошибки (организационного плана) бывают у всех и не D-Net'овские проекты не полностью аналогичны, я говорю только об исходных посылках (бизнес-моделях) этих проектов.
Теперь о '+' (кот. в заголовке).
Похоже мне удалось смоделировать ситуацию, в кот. клиент создаёт себе проблему с (возможно, только с распределённым) кэшем. Запускаем клиента при отсутствии юнитов в папке кэша и невозможности связи с сервером раздачи - он делает указанное кол. подпапок под юниты, лезет в и-нет и отваливается, при этом файл: "last-wu.dat" не создаётся. После этого, запускаем клиента с доступом в и-нет - он находит готовые папки, набивает их юнитами... и опять не создаёт файл: "last-wu.dat", после чего тыкается то в и-нет, то в папки юнитов, а делать ничего не хочет - файлА то нету... Видимо, нужен механизм проверки целостности кэша и доп. механизм контроля раздачи юнитов, например, на основе атрибутов папок или файлов.
|
| | | | | | | | | | |
подходы + 27.11.02 18:55
Автор: StR <Стас> Статус: Elderman
Отредактировано 27.11.02 18:59 Количество правок: 1
|
> Под подходом, я подразумеваю, в первую очередь:
> - способ организации проекта (т.е. что является исходной
> говорю только об исходных посылках (бизнес-моделях) этих
> проектов.
В общем согласен, но бизнес-модель завязывается на техническую модель, которая зависит от класса задачи...
Тот же днет (бизнес-модель) ориентирован на задачи полного перебора с ответом типа да/нет, цель md - получить максимальное количество информации для каждого элемента задачи, поэтому сделать "свой днет" не получится... не уверен даже, что вообще можно нормально положить эту задачу на распределенные вычисления, как раз из-за желательности максимального объема ответа...
кстати и с соревновательностью будут сложности...
|
| | | | | | | | | | | |
подходы + 27.11.02 19:46
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
> > Под подходом, я подразумеваю, в первую очередь:
> > - способ организации проекта (т.е. что является
> исходной
> > говорю только об исходных посылках (бизнес-моделях)
> этих
> > проектов.
> В общем согласен, но бизнес-модель завязывается на
> техническую модель, которая зависит от класса задачи...
> Тот же днет (бизнес-модель) ориентирован на задачи полного
> перебора с ответом типа да/нет, цель md - получить
> максимальное количество информации для каждого элемента
> задачи, поэтому сделать "свой днет" не получится... не
> уверен даже, что вообще можно нормально положить эту задачу
> на распределенные вычисления, как раз из-за желательности
> максимального объема ответа...
> кстати и с соревновательностью будут сложности...
Ну почему же... Мы пожмём результаты и нужны же не все возможные результаты а лишь самые необходимые. :)
|
| | | | | | | | | | | | |
на оба постинга 27.11.02 22:03
Автор: Deviator <n/a> Статус: Member
|
> > > Под подходом, я подразумеваю, в первую очередь:
> > > - способ организации проекта (т.е. что является
> > исходной
> > > говорю только об исходных посылках
> (бизнес-моделях)
> > этих
> > > проектов.
> > В общем согласен, но бизнес-модель завязывается на
> > техническую модель, которая зависит от класса
> задачи...
Вот в том то и дело, что сначала бизнес-модель, а исходя из неё (естественно, не только из неё, но не паралельно, не до, а после) составляется техзадание. Эксперименты по установке лошади и телеги в различные конфигурации уже проведены, результаты получены и нет никакой необходимости снова и снова прыгать с балкона, для того, что бы убедиться в дествии законов Ньютона.
> > Тот же днет (бизнес-модель) ориентирован на задачи
> полного
> > перебора с ответом типа да/нет, цель md - получить
> > максимальное количество информации для каждого
> элемента
> > задачи, поэтому сделать "свой днет" не получится... не
> > уверен даже, что вообще можно нормально положить эту
> задачу
> > на распределенные вычисления, как раз из-за
> желательности
> > максимального объема ответа...
Возможно, но что бы коментировать эту часть, надо хоть какое-то представление о предмете иметь, а я кроме названия ничего об этом не знаю. Единственное соображение - если количество результатов само по себе становится проблемой (а мне кажется, что это вполне может случиться), то налицо нерациональная постановка задачи. Впрочем, это совершенно умозрительное соображение, а соответственно, не имеющее содержательных оснований.
> > кстати и с соревновательностью будут сложности...
Вот это целиком зависит от толковости организаторов - если посмотреть ТиВи, так чем только пиплы не меряются...:)
> Ну почему же... Мы пожмём результаты и нужны же не все
> возможные результаты а лишь самые необходимые. :)
Собственно, это и нужно, просто этот процесс надо довести до максимально привлекательного варианта.
|
| | | | | | | | | | |
подходы + 27.11.02 01:00
Автор: Konstantin <Konstantin Leontiev> Статус: Member
Отредактировано 27.11.02 01:04 Количество правок: 1
|
> Под подходом, я подразумеваю, в первую очередь:
>
> - способ организации проекта (т.е. что является исходной
> точкой), для проектов SETI, F@H, MoDyp это некая прикладная
> задача, которую хотелось бы решить до того, как её решение
> потеряет смысл ввиду старения вселенной. D-Net шёл с другой
> стороны, по принципу: "давайте организуем механизм,
> позволяющий раскидать решение сложных задач на незанятые
> процессоры, а заказчики найдутся" (естественно, я немного
> утрирую, но только немного);
>
> - кто организует проект, для D-Net это люди решившие
> заниматься _распределёнными вычислениями_, "по барабану"
> какими, остальные проекты организовывались
> "заинтересованными лицами" (опять же с долей утрирования);
>
> - "целевая аудитория", т.е. кого предпочитают привлекать
> организаторы в качестве доноров, D-Net "целится" в
> "скучающих сетевиков", остальные в "сознательных
> энтузиастов" (проявляется это, в первую очередь, в способе
> отображения процесса работы софта).
>
> БОльшая часть остального вытекает из вышеперечисленного:
> это и "фантики и бантики" у всех клиентов, кроме
> D-Net'овского, и наличие единственного полноценного прокси,
> а так же клиента под платформы про существование которых я,
> к примеру, узнал из списка доступных клиентов... (но уже
> наоборот, только у них), и способ ведения логов и стата, и
> мотивация участников (полезность vs азарт)... Т.е. D-Net во
> главу угла ставит принцип: "входить тихо и быстро, не
> высовываться и не мешать тому, что работает, отваливать по
> первому требованию не оставляя следов", остальные этим
> похвастаться совсем не могут.
>
> Собственно, дальше говорить нет смысла - это уже следствия.
> Естественно, что ошибки (организационного плана) бывают у
> всех и не D-Net'овские проекты не полностью аналогичны, я
> говорю только об исходных посылках (бизнес-моделях) этих
> проектов.
>
> Теперь о '+' (кот. в заголовке).
> Похоже мне удалось смоделировать ситуацию, в кот. клиент
> создаёт себе проблему с (возможно, только с распределённым)
> кэшем. Запускаем клиента при отсутствии юнитов в папке кэша
> и невозможности связи с сервером раздачи - он делает
> указанное кол. подпапок под юниты, лезет в и-нет и
> отваливается, при этом файл: "last-wu.dat" не создаётся.
> После этого, запускаем клиента с доступом в и-нет - он
> находит готовые папки, набивает их юнитами... и опять не
> создаёт файл: "last-wu.dat", после чего тыкается то в
> и-нет, то в папки юнитов, а делать ничего не хочет - файлА
> то нету... Видимо, нужен механизм проверки целостности кэша
> и доп. механизм контроля раздачи юнитов, например, на
> основе атрибутов папок или файлов.
Спасибо за "+". Ошибка была немного в другом. Если папка где надо создать структуру кеш существовала (не её вышележащая папка, а она сама), то он не создавался... Это я только что пофиксил. Но всё равно большое спасибо.
По первой части если честно - нет просто времени клавиатуру топтать... У меня сейчас другой азарт. :)
|
| | | | | | |
проблемы 26.11.02 10:23
Автор: Konstantin <Konstantin Leontiev> Статус: Member
|
> > Как только изучу спецификацию SOCKS4 - сделаю. Если
> > поможете или подскажите библиотеку сделаю быстрее.
А я то думалл ссылочку на библиотеку бесплатную какую дадите.
> это давайте отложим, поскольку есть куда более существенные
> проблемы, да и помошник я в этом почти никакой - моё дело
> правильно настроить уже готовое.
>
> Логи отослал на мыло (кот. указано для этого), а
> впечатления помимо... - это, конечно, никакой не
> релиз-кандидат, это почти полноценная альфа...
Ответ на мыло дал. Я думаю там всё просто.
> Максимум, что удалось добиться в рабочей сети - скачать
> входные блоки. Даже при наличии полных входных буферов,
> клиент запускает PHP (!), мало того, это же происходит при
> указании работы только с локальными буферами (!), т.е. на
> настройки клиент просто не реагирует (?).
Что касается запуска PHP на нём ещё пока кеш сделан.
И выборка элементов из него. А то что он в логах get и send пишет не пугайтес никуда он не коннектиться. Это просто процедуры которые как только видят, что коннект запрещён сразу завершаються
> Если соответствует действительности сообщение:
> http://www.bugtraq.ru/cgi-bin/forum.cgi?type=sb&b=1&m=65128
> о размере выходных буферов, то с софтом, вообще, можно не
> торопиться - трафик в размере >1Gb в мес. ни для меня,
> ни для большинства сетевиков просто нереален. Что бы быть
> реальным, он должен быть, хотя бы, в 50 раз меньше и то это
> много, но хоть как то представимо. Иначе проект попадёт
> исключительно в разряд курьёзов, а его имя, боюсь, станет
> нарицательным.
Ну во превых трафик исходящий, я не настаиваю. Сама задача такова, что в 50 раз мы не снизим объём результирующих данных даже если очень напряжёмся. Максимум 10 и то в лучшем случае. Результатом перебора диапазона чего-то на вшивость является одно число из него (в идеале 64 бита :) в вашем самом успешном проекте). А в нашей науке на самом деле данных нам нужно ещё больше чем сейчас отсылается... Просто мы понимая ценность трафика поумерили свой пыл до минимума. И если нам ещё удасться, максимум можно ожидать что результат на одно WU будет около 60-100Кб - третьего не дано. Если вам тяжело работать с такими объёмами, то я не могу на этом настативать - в любом случае спасибо за помошь!
> Возвращаясь к началу всей дискуссии по теме, всё же
>настоятельнорекомендую изучить опыт уже имеющихся
> проектов, как успешных, так и нет - что считать успехом,
> каждый решает сам. MoDyp пока, гораздо больше похож на F@H
> и аналоги, чем на DNet.
Я уже это понял :).
|
| | | | | | | |
трафик 26.11.02 11:55
Автор: Deviator <n/a> Статус: Member
|
[...]
> Сама задача
> такова, что в 50 раз мы не снизим объём результирующих
> данных даже если очень напряжёмся. Максимум 10 и то в
> лучшем случае.
[...]
> И если нам ещё удасться, максимум можно ожидать
> что результат на одно WU будет около 60-100Кб - третьего не
> дано.
Может и не дано, а мож поискать надо...
Если просто жать результаты универсальным архиватором, то, действительно, о радикальном изменении размера, речь не пойдёт, но вот если подойти с другой стороны..., как обычно, сзади... :)
Во-первых, проанализировать формат результатов на предмет внутренней избыточности, например, можно ли представить результаты в относительном формате (т.е. "от предыдущего"), логарифмическом или ещё как то компактнее, чем уже есть.
Во-вторых, проанализировать "глубину" обработки - нельзя ли за счёт большей обработки исходных данных прийти к более компактному результату, или отбросить заведомо неинтересные результаты - естественно, что считать интересным, решать постановщикам задачи.
В-третьих, после всего этого связаться со специалистами по разработке архиваторов (с тем же Рошалем) и попытаться "вытрясти" из них специализированый архиватор именно для ваших данных - разница в упаковке может быть просто колосальной.
Естественно, такой проект плод "миллиона" компромисов и каждый вовлечённый в него, будет "тянуть одеяло на себя", я то-же :).
|
| | | | | | | |
трафик 26.11.02 11:34
Автор: Kost <Пробки Москвы> Статус: Elderman
|
Давайте немного посчитаем.
1) Константин, а сколько входящего трафика при закачивании одной WU с сервера клиенту?
2) К этой величине добавится порядка 7-10% от исходящего трафика (в TCP не бывает потока данных строго в одном направлении). Это сейчас немного, но может иметь значение в случаях домашних сетей, где люди платят из своего кармана центов по 15 за мегабайт.
> минимума. И если нам ещё удасться, максимум можно ожидать
> что результат на одно WU будет около 60-100Кб
Пока идет первый этап проекта, это не вопрос, подумаешь, 400 WU на всех.
Вот когда начнется следующий этап и потребуются большие вычислительные мощности, размер WU может стать препятствием.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
