[OGR-25] hitparade van 22 augustus

[ParaNoiMia]

Tjonge, bijna kwart voor 1 en nog is deze mooie hitparade niet gepost.

We zien x-Ray op nummer 1, op de hielen gevolgd door een mooie flush van Pixilated NetphreaX, die daarmee The_Greater voorbijstormen en daarmee plek 20 overall overnemen en ook nog een mooie paal meenemen, gefeliciteerd ! Nu is natuurlijk de vraag of het schoolparkje van The_Greater inderdaad verleden tijd is, of dat ze in de wacht stonden om terug te slaan

Verder nog een rij mijlpaalbehalers, waarbij brum103 de grootste pakt van maar liefst 17P !

DPC net achter de Russen, maar gezien de voorspellingen over het einde van dit project maak ik me weinig zorgen. Een PS3 is echt superduur in Rusland. Toch ?

[OGR-25] hitparade van 22 augustus 2007

Daily Top 30
pos		daily	member	total
1.	(1)	221.102	x-RaY99 the one-man 'team'	18.486.729	(14)
2.	(6)	211.118	Pixilated NetphreaX	9.717.454	(20)
3.	()	169.613	NoizyCows	74.298.620	(4)
4.	(3)	150.900	Jive	98.210.135	(3)
5.	(17)	130.985	brum103	17.013.033	(15)
6.	()	98.330	amaZing graZe	1.100.000	(102)
7.	(3)	85.723	EliteHackers.info	35.171.913	(8)
8.	(2)	72.507	Fryslân MP	29.684.724	(11)
9.	()	69.642	Graasland	119.002.656	(1)
10.	(3)	42.895	Team BSD	33.239.061	(9)
11.	(6)	38.764	Digital Pizza Crew	54.021.318	(6)
12.	(1)	36.895	Team ColdFusion	110.195.190	(2)
13.	(1)	31.031	Division Brabant	25.042.769	(12)
14.	(4)	30.336	Stappel	49.626.390	(7)
15.	()	15.471	SpeedKikker	1.680.613	(74)
16.	(5)	15.219	Puchelaar & TonioG	4.962.303	(41)
17.	(3)	14.763	f1r3b4ll	976.627	(111)
18.	(1)	13.170	reznor	8.676.065	(22)
19.	()	11.318	MasterYoda	698.692	(132)
20.	(4)	10.906	Landgraaf Team	1.305.543	(88)
21.	(15)	10.869	The_Greater	9.578.255	(21)
22.	(4)	10.507	CSC Hand full Of Idiots "HOI"	6.247.384	(33)
23.	(3)	9.456	Ruben	1.431.596	(81)
24.	(3)	9.113	Dr0x	1.783.863	(71)
25.	(2)	7.061	Peter 'MathFox' Roozemaal	7.582.058	(25)
26.	()	6.824	Los Alcoholicos	31.446.260	(10)
27.	(2)	6.639	Tinkerer	2.373.107	(59)
28.	(1)	6.306	SAndMan	606.882	(146)
29.	(1)	6.143	Robinski	2.419.082	(56)
30.	(1)	5.720	't Griene gers fan Bantegea	76.918	(491)
Meer...

Overall Top 30
pos		total	member	daily
1.	()	119.002.656	Graasland	69.642	(9)
2.	()	110.195.190	Team ColdFusion	36.895	(12)
3.	()	98.210.135	Jive	150.900	(4)
4.	()	74.298.620	NoizyCows	169.613	(3)
5.	()	71.855.232	The Fonz	0
6.	()	54.021.318	Digital Pizza Crew	38.764	(11)
7.	()	49.626.390	Stappel	30.336	(14)
8.	()	35.171.913	EliteHackers.info	85.723	(7)
9.	()	33.239.061	Team BSD	42.895	(10)
10.	()	31.446.260	Los Alcoholicos	6.824	(26)
11.	()	29.684.724	Fryslân MP	72.507	(8)
12.	()	25.042.769	Division Brabant	31.031	(13)
13.	()	22.452.569	MAWEK	0
14.	()	18.486.729	x-RaY99 the one-man 'team'	221.102	(1)
15.	()	17.013.033	brum103	130.985	(5)
16.	()	13.789.512	NGS	0
17.	()	12.847.222	De Unie's	0
18.	()	10.554.133	De Utregse Kudde	0
19.	()	10.455.951	Theetjuh	1.301	(43)
20.	(1)	9.717.454	Pixilated NetphreaX	211.118	(2)
21.	(1)	9.578.255	The_Greater	10.869	(21)
22.	()	8.676.065	reznor	13.170	(18)
23.	()	8.277.767	#marijse united	0
24.	()	8.142.262	100% TGA, and D.net still owes us 2P nodes!!!!!!!!	0
25.	()	7.582.058	Peter 'MathFox' Roozemaal	7.061	(25)
26.	()	7.375.444	NightBird & #rulende_bikkels	0
27.	()	7.221.038	Team Antoniuscollege	0
28.	()	7.189.457	Clearance	141	(71)
29.	()	6.882.231	Team_Kwakende_kip	0
30.	()	6.745.762	Bobco	253	(67)
Meer...

Teams Daily Top 15
pos		daily	member	total
1.	()	1.735.787	BugTraq.Ru Team. United power of xUSSR.	1.049.263.599	(2)
2.	()	1.604.246	Dutch Power Cows	1.249.482.770	(1)
3.	()	792.051	Free-DC	234.864.761	(8)
4.	()	548.210	Ars Technica Team Beef Roast	400.925.771	(4)
5.	(1)	460.672	Distributed Amiga	463.680.234	(3)
6.	(1)	446.662	Team Warped (OS/2)	362.075.566	(5)
7.	()	261.339	2ch, Team	79.125.570	(32)
8.	()	215.885	Terminal & BBS Liane & Others RC5 Team	129.843.731	(21)
9.	(1)	192.792	Namibia RC5-64 team	201.039.218	(12)
10.	(57)	179.069	Japan FreeBSD Users Group	132.083.156	(19)
11.	(2)	151.503	SPring-8	144.232.144	(17)
12.	(1)	136.926	Team XtremePcCentral.com	11.173.120	(161)
13.	(1)	136.597	#distributed	241.214.926	(7)
14.	(9)	121.751	Team Hungary STB+	177.032.705	(15)
15.	(4)	116.448	yoyo@home BOINC wrapper	807.148	(1172)
Meer...

Teams Overall Top 15
pos		total	team	daily
1.	()	1.249.482.770	Dutch Power Cows	1.604.246	(2)
2.	()	1.049.263.599	BugTraq.Ru Team. United power of xUSSR.	1.735.787	(1)
3.	()	463.680.234	Distributed Amiga	460.672	(5)
4.	()	400.925.771	Ars Technica Team Beef Roast	548.210	(4)
5.	()	362.075.566	Team Warped (OS/2)	446.662	(6)
6.	()	349.236.722	AnandTech 10635	58.649	(27)
7.	()	241.214.926	#distributed	136.597	(13)
8.	()	234.864.761	Free-DC	792.051	(3)
9.	()	229.915.276	Slashdot.org 1365	54.076	(31)
10.	()	218.728.536	Czech D.NET Team	62.568	(23)
11.	()	210.495.503	Monochrome BBS	82.679	(21)
12.	()	201.039.218	Namibia RC5-64 team	192.792	(9)
13.	()	199.425.350	Team EvangeLista (Macs Rule! :-)	39.144	(34)
14.	()	180.181.289	Russian Team	17.510	(68)
15.	()	177.032.705	Team Hungary STB+	121.751	(14)
Meer...

Mijlpalen
brum103	17.000.000
Pixilated NetphreaX	9.600.000
Landgraaf Team	1.300.000
amaZing graZe	1.100.000
HuT-Gaming.eu	175.000

Leden
Flushers: 72/2942 = 2.4%
Geen nieuwe leden

Inhaalstats
BugTraq.Ru Team. United power of xUSSR. haalt ons in over	23 maanden

Megaflush top 5
18 mei 2007	NoizyCows 5 jaar !	24.940.613
11 juli 2006	Team ColdFusion - 6 year anniversary!	16.613.069
7 maart 2006	Graasland	12.595.528
15 augustus 2007	x-RaY99 the one-man 'team'	8.723.420
9 april 2007	Jive	7.899.714

Meer informatie
OGR-25 projectpagina op WDO
*** suggesties voor een DPCH? ***
bron

[Marcj]

Ah crap... X-Ray: waarom moet je nu vandaag weer boven je gemiddelde zitten?

Maar goed, iig wel The_Greater ruim voorbij

[Ids Lupo]

Jullie zitten toch ook boven je gemiddelde vandaag

[x-RaY99]

Sorry! Als ik dat geweten had, had ik even iets minder gedaan, maar toch een nette flush!

Wat is er met de andere loner aan de hand, Jive, ? Toch niet stiekem aan het sparen he!

[ Voor 33% gewijzigd door x-RaY99 op 23-08-2007 14:08 ]

[Robinski]

x-RaY99 schreef op donderdag 23 augustus 2007 @ 14:07:
Sorry! Als ik dat geweten had, had ik even iets minder gedaan, maar toch een nette flush!

Wat is er met de andere loner aan de hand, Jive, ? Toch niet stiekem aan het sparen he!

Ik vermoed een lichte daling als gevolg van het weer iets groter zijn/worden van de blokjes.
Heel distributed.net lijkt te maken te hebben met een daling in de keyrate vandaag.


edit: ik voel ook een nieuwe geduchte concurent aankomen voor DPC: http://stats.distributed....p?project_id=25&id=462671 / http://www.rechenkraft.net/yoyo/

Deze duitse jongen heeft een BOINC wrapper gemaakt voor de distributed.net client, voorlopig flushed die alleen nog onder zijn eigen e-mail adres, en hij gaat met sprongen vooruit in de output.

Overigens is het project misschien voor ons ook wel mooi in de toekomst, want er wordt nog gewerkt aan een manier om een custom e-mail adres mee te geven, wat ons DPCers misschien gemakkelijker (remote) clients oplevert die nu al boinc draaien en gemanaged worden via BAM of iets dergerlijks.

[ Voor 41% gewijzigd door Robinski op 23-08-2007 15:03 ]

[Ids Lupo]

OMG! Mijn client eet net een hele berg fase 6 stubs op. Dan heb je het niet meer over 'wat' groter wordende pakketjes. Hij is nu al een uur aan het chunken ipv de 3 minuten die het eerst was.
Je ziet het ook op dnet. De overall rate was eventjes gezakt naar 50G/s.

[Bastien]

Hier is het nog niks groter atm: Summary: 324 packets (507.62 stats units)... in een uurtje ongeveer. En dit zie ik ook wel geregeld langskomen op de clients: 2 packets (0.32 stats units)

Proxy wordt gek Naja het zal wel weer veranderen als de buffer van mijn eigen proxy en die van TCF opgekauwd is

En we weten nog steeds niet wie de luier te vol gescheten heeft

[ Voor 10% gewijzigd door Bastien op 23-08-2007 19:42 ]

[Reneger]

omg...

Volgens mij heeft mn proxy in 2 uurtjes 800 packets uitgedeeld...

[CBA]

Iemand ervaring met verschillende soorten clients en dezelfde buffer in ?

Heb namelijk 3 clients op m'n USB stickje staan, PC, OSX PPC & OSX x86
nu vraag ik me af of ik zonder problemen dezelfde in buffer kan gebruiken. Weliswaar draaien deze clients nooit terzelfdertijd natuurlijk.

Andere locatie waar ik kom start ik de client van m'n USB stick.

[Verwijderd]

CBA schreef op donderdag 23 augustus 2007 @ 20:33:
Iemand ervaring met verschillende soorten clients en dezelfde buffer in ?

Heb namelijk 3 clients op m'n USB stickje staan, PC, OSX PPC & OSX x86
nu vraag ik me af of ik zonder problemen dezelfde in buffer kan gebruiken. Weliswaar draaien deze clients nooit terzelfdertijd natuurlijk.

Ja, het kan... hergebruik van buffers heeft wel het nadeel dat wanneer een client voor een andere architectuur start, deze van voor af aan begint met de stub waar door de andere client al aan gerekend was. Je verliest gemiddeld een halve stub werk.

P.S. Het is mogelijk om meerdere clients tegelijkertijd uit een buffer te laten eten... met bovengenoemde valkuil.

[Verwijderd]

CBA schreef op donderdag 23 augustus 2007 @ 20:33:
Iemand ervaring met verschillende soorten clients en dezelfde buffer in ?

Heb namelijk 3 clients op m'n USB stickje staan, PC, OSX PPC & OSX x86
nu vraag ik me af of ik zonder problemen dezelfde in buffer kan gebruiken. Weliswaar draaien deze clients nooit terzelfdertijd natuurlijk.

Andere locatie waar ik kom start ik de client van m'n USB stick.

Die clients kunnen dezelfde in buffer gebruiken, maar er is één nadeel: soms herbegint een client met een WU.

Je weet dat als een WU niet helemaal is verwerkt en de client afsluit, dat deze de partieel afgewerkte WU terug in de inkomende buffer zet. Als je nu een (andere) client opstart met deze buffer, gaat deze verder met de partieel verwerkte WU (buffers zijn FIFO), merkt dat die al voor een deel is gedaan door een client met een andere versie/architectuur/os/whatever en trasht de resultaten voor die WU; i.e. hij herbegint van voor af aan met die WU! Voor RC5 en voldoende snelle machines is dat misschien nog geen ramp (paar minuten CPU tijd verloren) maar het is natuurlijk pure verspilling en zonde.

Aangezien in jouw geval de drie clients altijd verschillen (ander OS, andere architectuur of beide) zal dat dus altijd resulteren in het herbeginnen van partieel afgewerkte WU als je een andere client opstart.

Kun je niet gewoon drie subfolders maken voor die drie clients en ze elk een buffertje geven? Of één folder met drie buffertjes en dan je clients starten met een scriptje dat buffertjes gaat renamen al naargelang het OS en architectuur waar je draait...

[edit]
Note to self: sneller typen visje...
Note to MathFox: GMTA Oh, en dat herbeginnen is niet alleen voor een verandering in architectuur. Ook voor bvb een verandering van OS (Windows vs MacOS X voor CBA) en client versie etc. Ik vermoed dat dnet dat doet uit veiligheidsredenen. Stel dat ze niet herbeginnen en 99% is door client X gedaan en client Y werkt die 1% af en flusht die WU... die komt bij de keyserver als 'done by Y' aan natuurlijk. Eventuele fouten in de eerste 99% worden dan aan client Y gelinkt terwijl dat niet zo is, of nog veel erger: er wordt een bug ontdekt in client X en die blokjes zouden dus verkeerde resultaten kunnen bevatten. Blokjes door client X moeten opnieuw worden uitgegeven... Dus geen risico en alle werk gegarandeerd door één client laten doen

[ Voor 19% gewijzigd door Verwijderd op 23-08-2007 22:38 ]

[puchelaar]

Ik hou me o.h.a. niet zo heel erg bezig met de stubgrootte, maar door de dicussie ging ik zojuist even checken; 1 packet in buffout: 848.39 statsunits...

[Qwerty-273]

Verwijderd schreef op donderdag 23 augustus 2007 @ 22:30:
Kun je niet gewoon drie subfolders maken voor die drie clients en ze elk een buffertje geven? Of één folder met drie buffertjes en dan je clients starten met een scriptje dat buffertjes gaat renamen al naargelang het OS en architectuur waar je draait...

Kan ej dan neit beter met 'vier' mapjes werken? Voor elke client 1, die slechts 1 unit ophaalt, berekend en flust naar het vierde mapje waar de "remote buffers" instaan. Deze kan je dan met 1 client fetchen en flushen (command line) of gewoon via de mail ophalen en versturen? Je hebt dan 1 plek waar je moet updaten voor nieuw werk en het gedane werk vandaan kan plukken. De drie clients werken elk aan hun eigen stukje en hoeven dus niet opnieuw te starten ;-)

[Robinski]

Qwerty-273 schreef op vrijdag 24 augustus 2007 @ 01:18:
[...]

Kan ej dan neit beter met 'vier' mapjes werken? Voor elke client 1, die slechts 1 unit ophaalt, berekend en flust naar het vierde mapje waar de "remote buffers" instaan. Deze kan je dan met 1 client fetchen en flushen (command line) of gewoon via de mail ophalen en versturen? Je hebt dan 1 plek waar je moet updaten voor nieuw werk en het gedane werk vandaan kan plukken. De drie clients werken elk aan hun eigen stukje en hoeven dus niet opnieuw te starten ;-)

Mooie oplossing

[Verwijderd]

Qwerty-273 schreef op vrijdag 24 augustus 2007 @ 01:18:
<verhaal over vier mapjes en remote buffers>

Dat kan natuurlijk ook

Ik denk nooit aan remote buffers eigenlijk. Een paar keer 'dnetc -import <buffer>' is zo getypt en dan kun je alsnog met één client fetchen en flushen

[Verwijderd]

Verwijderd schreef op donderdag 23 augustus 2007 @ 22:30:
[...]

[edit]
Note to self: sneller typen visje...
Note to MathFox: GMTA Oh, en dat herbeginnen is niet alleen voor een verandering in architectuur. Ook voor bvb een verandering van OS (Windows vs MacOS X voor CBA) en client versie etc. Ik vermoed dat dnet dat doet uit veiligheidsredenen. Stel dat ze niet herbeginnen en 99% is door client X gedaan en client Y werkt die 1% af en flusht die WU... die komt bij de keyserver als 'done by Y' aan natuurlijk. Eventuele fouten in de eerste 99% worden dan aan client Y gelinkt terwijl dat niet zo is, of nog veel erger: er wordt een bug ontdekt in client X en die blokjes zouden dus verkeerde resultaten kunnen bevatten. Blokjes door client X moeten opnieuw worden uitgegeven... Dus geen risico en alle werk gegarandeerd door één client laten doen

Een andere reden is dat niet alle engines op dezelfde manier over een stub lopen; en compleet het bos in kunnen gaan of een stuk helemaal niet controleren. Veiligheid en zekerheid.