Коммерческая распределенка - минус один - Wednesday, March 21, 2001 - 10:55 - maxx
Popular Power, одна из первых компаний, построивших свой бизнес на распределённых вычислениях, объявила о прекращении коммерческой деятельности.
Компания собиралась создать свою сеть, основанную на тех же принципах, которые использует сеть проекта SETI@Home. Специальные программы, установленные на входящих в сеть компьютерах, должны были бы производить обработку данных фармацевтических компаний, студий компьютерной графики и других заказчиков Popular Power.
В отличие от участников проекта SETI@Home, предоставляющих мощности своих компьютеров совершенно бескорыстно, участникам проектов Popular Power полагась оплата. Те, кто предоставил свои компьютеры, получали бы часть заработанных компанией денег.
Однако надежды на коммерческий успех, которые строили основатели Popular Power, не оправдались. Пока продолжается выполнение только некоммерческих проектов, таких как моделирование реакции организма человека на вирус гриппа.
Popular Power - не единственная компания, надеявшаяся обратить модную технологию в деньги. Среди её бывших конкурентов можно назвать основанную руководителем проекта SETI@Home Дэвидом Андерсоном компанию United Devices (не так давно поглотившую проект d.net - maxx), компании Entropia, Parabon Computation, Applied MetaComputing и бесплатного интернет-провайдера Juno.
Источник: http://www.compulenta.ru/news/2001/3/20/10429/
OGR - итоги февраля - Monday, March 12, 2001 - 6:26 - victor
За январь в OGR-25 было проверено 728,582,363 GNodes (+2.89% к январю), общее количество проверенных GNodes на 28/02/01 составило 3,252,618,988.
В OGR-24 за месяц обработано 432,479 GNodes(-9,82% к январю), итого - 134,643,321.
По командам:
на 28/02/01 за месяц к январю участников
AnandTech 36,912,179 6,494,512(2) 95,19% 858( +65)
Slashdot 31,892,428 4,261,453(3) 90,74% 684( +37)
Dutch Power Cows 22,948,584 9,832,081(1) 170,12% 1059(+129)
The Amiga RC5 Team effort 19,890,938 2,575,257 79,30% 559( +27)
Russian Team 15,857,147 3,183,542(4) 76,94% 976( +30)
Wonder Monkeys 11,841,475 1,355,735 89,18% 8( +1)
Team Warped (OS/2) 11,565,342 1,740,647 89,46% 222( +3)
Japan FreeBSD Users Group 11,438,750 2,403,717 117,41% 141( +21)
DPC стала безусловным лидером по скорости расчета и вышла на третье место по Overall. Успеет она выйти на первое место или нет зависит от длины оставшейся дистанции (лично мне она неизвестна). Наша команда осталась на пятом месте, HackZone Team - на двадцатом, moomin поднялась с 24-го на 23-е место; Ukraine RC5 поднялась с 89-го до 70-го места.
По странам:
на 28/02/01 на 31/01/01 за месяц к декабрю участников
7. Australia 24,249,254 20,788,046 3,471,208 99,58% 491( +40)
8. Sweden 23,062,499 19,249,176 3,813,323 87,77% 618( +38)
9. Russia 17,636,761 14,147,659 3,489,102 99,64% 1001( +71)
10. France 14,283,388 12,579,367 1,704,021 74,64% 445( +22)
11. Finland 11,822,476 10,020,807 1,801,669 99,76% 383( +18)
Россия осталась на девятом месте, Эстония на 15-м, Украина на 24-м, Латвия - на 43-м, Литва - с 50-го на 47-е, Туркменистан -
переместился с 54-го на 57-е, Беларусь - с 62-го на 59-е, Киргизстан - с 64-го на 61-е, Казахстан - на 60-го на 63-е, Узбекистан - с 75-го на 74-е, Молдова - с 83-го на 76-е, Таджикистан - с 79-го на 78-е, Грузия - с 89-го на 87-е, Армения - со 114-го на 116-е, Азербайджан - с 128-го на 122-е.
RC5-64 - итоги февраля - Monday, March 5, 2001 - 6:31 - victor
За февраль в проекте обсчитано 1,967% кейспейса(-0,146%).
Командная статистика:
Dutch Power Cows 87,248,252 99,485,809 (-12,30%) +221 участник
AnandTech 50,858,201 53,085,450 ( -4,20%) +67 участников
HackZone Team 35,436,565 44,681,505 (-20,69%) +69 участников
Russian Team 31,969,614 32,410,104 ( -1,36%) +32 участника
Ars Technica Team 21,211,777 19,600,611 ( +8,22%) +43 участника
Slashdot.org 20,017,550 21,174,758 ( -5,47%) +17 участников
В нашей статистике новичок - Ars Technica Team Beef Roast, обошедшая сдающую позиции Slashdot.org.
HZ обогнала RT, но не в первую неделю, как ожидалось, а лишь 9 февраля.
Ukraine RC5 - 26-е место(31 января - 26-е), moomin - 29(27), vladivostok.net (united team) - 43(43), Team Lithuania - 97(96).
Статистика по странам:
Netherlands - 94,208,800 (-13,24%) +199 участников
Russia - 70,552,267 ( -2,38%) +99 участников
Germany - 65,732,063 ( -5,60%) +170 участников
Japan - 62,097,215 ( -1,28%) +50 участников
Голландцы так и не успели догнать японцев до наступления весны, впрочем это событие, как и наступление весны в природе -
неотвратимо. Между тем и те и другие преодолели весьма знаковый рубеж - 1,000,000,000 (МИЛЛИАРД) блоков. Что же, если очень
постараемся, то к следующему месяцу и мы(вслед за немцами) станем миллиардерами.
Украина - 17-е место(31 января - 17-е), Эстония - 20 (20), Латвия - 38(37), Литва - 40(38), Беларусь - 42(42), Армения - 46(44), Казахстан - 52(51), Молдавия - 63(61), Киргизстан - 61(62), Узбекистан - 69(69), Туркменистан - 75(75), Грузия - 111(109), Таджикистан - 114(115), Азербайджан - 115(116).
DNetFingerNews, 3 Mar. - Sunday, March 4, 2001 - 13:54 - marck
Jeff Lawson (bovine@distributed.net)
После долгого ожидания мы рады представить вам официальную линию наших "мулек и фенек", которую называют также dnet-ware. В настоящее время мы производим два вида футболок, один вид фуфаек, кружки и мышиные коврики. Все это можно заказать на http://www.distributed.net/dnetware/
Кроме того, за последние несколько дней мы зарегистрировали ощутимый прирост в потоке блоков, так что изрядное их количество попало в отложенную очередь и будет обработано отдельно в ближайшие дни. Некоторые новые оптимизации в коде кеймастера 324 версии должны обеспечить существенное улучшение производительности обработки принимаемых блоков в большинстве ситуаций. Отложенная очередь будет обрабатываться в выходные, так что статистика должна отражать реальные цифры уже в ближайшие несколько дней.
DNet FingerNews, 02 Mar. - Saturday, March 3, 2001 - 3:22 - marck
Paul Gentle (moose@distributed.net):
Выложены новые бета-клиенты v2.8013.467, исправляющие баги в версиях 2.8012.466:
- Windows 32bit [x86/Zipped]
- MacOS [m68k]
- MacOS [PPC]
Клиенты берутся со страницы пререлизов http://www.distributed.net/download/prerelease.html; файл changes.txt включен в каждый архив, а также может быть найден на http://www.distributed.net/download/changes.txt
Не забудьте сообщать о найденных багах нашей Багзилле: http://www.distributed.net/bugs/
Данные клиенты действительны в течение 7 дней. Они работают медленнее предыдущих релизов -- мы знаем об этом. Потеря скорости будет исправлена к очередному релизу. Я мог бы расссказать длинную историю о том, как все это происходило, но она на самом деле не слишком интересна. В основном все дело в разных компиляторах, которые использовались....
DNet FingerNews, 28 Feb. - Thursday, March 1, 2001 - 13:29 - marck
Дэвид Макнетт (David McNett, он же Nugget, nugget@distributed.net):
Презабавная штуковина: http://www.ratajik.com/COWPump/
DNet FingerNews, 28 Feb. - Thursday, March 1, 2001 - 13:25 - marck
Ivo Janssen (ivo@distributed.net):
После вчерашнего сообщения Decibel'а осталось некоторое количество вещей, которые стоило бы объяснить поподробнее. Мы получили изрядное количество жалоб от членов команды DPC, утверждавших, что никакого организованного мега-слива не было, и что вывод, сделанный командой DCTI, был поспешным и во многом неверным.
На настоящий момент причиной фактического выхода статистики из строя мы считаем совокупность отдельных участников, копивших блоки в прошлом и сливающих их из соображений типа "мои 8012 блоков скоро не зачтут вовсе". Кто-то скажет: "И что ж в том дурного?" Увы, увы, это вызывает одномоментный сброс большого количества блоков, который в норме должен был бы происходить в течение многих дней.
Маленькое замечание: вообще нехорошо пытаться копить блоки. Даже если вы делаете это в одиночку и "только на несколько недель". Почему?
Наш мастер-сервер оптимизирован для обработки ключей из одного или по крайней мере из малого количества сегментов. Каждый сегмент ключей занимает 32 мегабайта памяти. Чем меньше сегментов загружено в память одновременно, тем быстрее идет процесс обработки. Из-за оптимизаций кода даже процесс смены сегмента достаточно сильно ухудшает производительность. Когда на мастере набирается очередь из нескольких миллионов блоков из, скажем, 20 сегментов, ему совсем плохеет.
В ответ на это некоторые могут заявить: "Ну уж если вы теперь не можете справиться с выбросом нагрузки в виде нескольких миллионов блоков, что же вы будете делать с ними потом, когда такая загрузка станет нормальной?" Я надеюсь, что данное выше объяснение сохраняет истину и на будущее. Мы тщательно спроектировали мастер-сервер, и его тестирование показало, что при обработке более-менее стандартно поступающих блоков, мы с легкостью обработаем поток порядка 1000 гигаключей в секунду на текущем оборудовании. В нормальной ситуации блоки из неоткрытых сегментов откладываются в отдельную очередь, которая обрабатывается в периоды снижения загрузки. При наличии кучи очередей для массы неактивных сегментов теоретическая производительность в один тераключ в секунду падает до величины, которая ниже средней скорости получения ключей, ибо ситуация с растущей очередью -- одна из самых неприятных для любого процесса обработки данных. [Спросите у любого серьезного программиста баз данных - D.Marck].
Я надеюсь, я привел достаточно веские аргументы для того, чтобы участники не пытались сохранять слишком много блоков. Ежедневная статистика предназначена именно для того, как она называется: для оценки дневной производительности. Не для того, чтобы раз в год на сутки занять первое место из-за того, что вы накопили больше ваших друзей. Если вы действительно хотите занять первое место, просто найдите больше компьютеров для обсчета!
Мы пытаемся привлечь максимальное количество участников, и всегда рады проявлениям энтузиазма участников. Однако, если наши правила постоянно нарушаются, мы можем быть вынуждены предпринимать специальные меры против этого, например, блокированием участников в статистике или ограничением времени жизни блока. Не потому, что нам не нравятся эти конкретные участники, а потому, что мы хотим сохранить ситуацию честного соревнования для всех. По возможности, без "хитрых приемов", типа накопления блоков.
Последнее замечание по поводу очереди блоков: ее создание не означает, что наша система сломалась, просто нагрузка на нее такова, что требует специальных мер по обработке. Мы примем все блоки, и никогда не будем отказывать в приеме блоков на наших прокси-серверах. Мы обязательно обработаем все их. Может быть, не сегодня, когда получится, но обработаем. В результате каждый блок будет учтен. Ваша суммарная статистика будет корректно отражать общее количество блоков. Если все мы будем предпринимать усилия по поддержанию работы системы в том виде, в котором она была спроектирована, отложенных очередей возникать не должно, и ежедневная статистика тоже будет корректна.
Продолжаем перемалывать!