Dutch Power Cows hitparade van 28 februari

Voor de derde dag op rij hebben we ruim 4M gedaan, waarmee we de concurrentie ver achter ons laten.

Mensen die nog steeds client 8012 (ookwel aangeduid als 466) gebruiken worden dringend verzocht even hier te kijken. Vanwege een bug gaan blocks van deze client waarschijnlijk vanaf volgende week geweigerd worden.

Gisteren mochten we 9 nieuwe leden verwelkomen, wil jij daar morgen ook bijhoren? Kijk dan even hier hoe je mee kunt doen.

Voor de OGR-ende DPC-ers staat op GoT de OGR25-hitparade.

DPC top 30 van 28 februari

1.	(1569)	900.830	Division Eindhoven	2.614.014	(46)
2.	(1)	120.262	I 'R Cow @ I-netcafe Groningen	4.797.026	(19)
3.	(951)	109.121	De Utregse Kudde	960.900	(143)
4.	(5)	100.320	Ethan_Hunt	13.095.847	(6)
5.	(107)	99.793	Clan-of-nine	7.603.291	(9)
6.	(4)	96.629	Bill Goldberg	19.156.692	(3)
7.	(809)	87.687	AUGUSTIJN's MEGAFLUSH	3.350.789	(34)
8.	(2)	83.362	Quakers United \| Cewle Coown' Cadavers	17.105.383	(4)
9.	(9)	80.341	Azhrarn	156.724	(689)
10.	(5)	78.635	Team BVD	3.776.265	(28)
11.	(1)	75.043	DBC	16.908.513	(5)
12.	(24)	55.059	wiho	20.537.886	(1)
13.	(4)	51.223	-Killemall says: may the cow be with you	10.970.812	(7)
14.	(12)	44.248	Team BoGoH	3.756.826	(29)
15.	(8)	36.650	Arjan B	385.062	(336)
16.	(1251)	35.531	Team Casema slachtoffers	600.485	(235)
17.	(10)	33.224	DTC Computershops Delfzijl	2.389.530	(51)
18.	(901)	33.060	Westwood DC	1.064.143	(115)
19.	(445)	32.391	TexelCows	824.774	(173)
20.	(76)	32.245	ErwinTheBorg	223.975	(522)
21.	(8)	31.878	WebtraX Interactive - Bugged version flush :	538.967	(260)
22.	(10)	31.045	De Unie's	418.181	(317)
23.	(20)	29.228	-=WPCP=-	1.094.586	(114)
24.	(3)	28.963	Team \|>Just dU It!<\|	4.959.710	(17)
25.	(77)	28.457	Ronnie Tober NO Devote!	2.085.913	(59)
26.	()	27.865	Interior Lulu	19.606.561	(2)
27.	(1)	23.429	ShoQ.CoM & ClubDev.NL Combined forces	3.332.032	(35)
28.	(1603)	22.794	The NoName Power Cows	110.815	(900)
29.	(9)	21.702	Andy4fun	5.580.030	(13)
30.	(6)	21.538	[Groningen] Noorder Power Cows	3.583.793	(30)

De 15 grootste stijgers

Denis van Beek & Independant Flushers	1635	(42.)	17.047
The NoName Power Cows	1603	(28.)	22.794
Division Eindhoven	1569	(1.)	900.830
BrammeS	1511	(146.)	4.112
#Darling Blokkendoos	1471	(87.)	7.550
Omega Directive Cs-clan Oldenzaal	1424	(200.)	2.682
BeeSmart	1406	(119.)	5.109
dverboom	1318	(275.)	1.894
Team I-Motion.nl	1297	(92.)	7.208
Team Casema slachtoffers	1251	(16.)	35.531
Big Tazzz	1224	(329.)	1.554
Jeepey	1195	(241.)	2.208
dijkpriv	1164	(142.)	4.152
Olivier.Debonne	1153	(272.)	1.937
Bitpull	1062	(376.)	1.354

Top 15 teams

1.	()	4.494.112	Dutch Power Cows	735.230.126	(1)
2.	()	1.800.271	AnandTech	681.187.609	(2)
3.	()	1.359.140	HackZone Team -- Combined power of Russia and exUSSR countries	457.049.443	(4)
4.	()	1.276.690	Russian Team	455.176.365	(5)
5.	(1)	737.604	Slashdot.org	577.681.715	(3)
6.	(1)	708.380	Ars Technica Team Beef Roast	120.077.599	(23)
7.	(2)	595.432	The Amiga RC5 Team effort	318.688.866	(8)
8.	(1)	576.399	Japan Linux Users Group	238.854.698	(10)
9.	(1)	550.606	Team EvangeLista (Macs Rule! :-)	415.283.170	(6)
10.	(2)	445.949	Japan FreeBSD Users Group	249.296.861	(9)
11.	()	439.363	Japan Windows NT Users Group	224.498.174	(11)
12.	(1)	383.423	Team Warped (OS/2)	320.990.534	(7)
13.	(1)	346.044	Ukraine RC5	105.954.451	(26)
14.	(1)	333.393	Team Depaul	58.830.890	(47)
15.	(1)	303.178	SysOpt.com/Tweakit.com	136.634.271	(20)

Mijlpalen

Ethan_Hunt	13.000.000
Dutch Cow Clan	2.000.000
Division Eindhoven	2.000.000
Emission Powercows	1.000.000
ruben	900.000
De Utregse Kudde	900.000
Team Fortunates	900.000
TexelCows	800.000
Melkunie koeien	700.000
Team Casema slachtoffers	600.000
KoelKast Clan says:visit koelkast.net	600.000
Cows Taskforce	400.000
De Unie's	400.000
Richard (CPoQ)	300.000
De MelkMachine =All your milk are belong to us=	300.000
Denis van Beek & Independant Flushers	200.000
Dutch DanceAholic	200.000
ErwinTheBorg	200.000
Fox	200.000
LandaR	100.000
LeChuCk	100.000
The NoName Power Cows	100.000
Azhrarn	100.000
E.T.O.	100.000

Leden

Aantal leden	4651
Verschil met vorige dag	10
Nieuwe leden	9
Retirements	0

Welkom bij DPC deepfreezer, OkkE, helldesk, waxie, Yeechie Tu, passie.p, Demoniac, serge en Participant #341,258!

IT-banen

Reacties (25)

bwt 1 maart 2001 14:04

D.net over de grote hoeveelheid aangeboden blokjes van oa. DPC.
http://n0cgi.distributed.net/cgi/dnet-finger.cgi?use r=ivo

28-Feb-2001 20:41 (Wednesday) ::
After Decibel's plan from yesterday, there are some things that need
explanation. We've had a lot of complaints from DPC members that argued
that there was no organized megaflush going on and that the accusation
made by the DCTI staff yesterday was premature and partly false.

What seemed to be the cause for the backlog was individual team members
who saved up some blocks flushed them because they feared their 8012 blocks
would become invalid soon. A valid reason to flush, one would say.
Unfortunately it turned out that this caused a lot of blocks flushed at
the same time, blocks that normally would have been distributed over days.

Some remarks on this practice: It's _not_ good to save up blocks. Even
when you do it only on your own or 'just for a few weeks'. Why?

Our master is optimized for processing keys from 1 or at most a couple of
subspaces. Every subspace takes up 32MB paged-in memory. A lower number
of paged-in subspaces means a faster master. Due to the optimizations in
the code, even switching between in-core spaces means a huge performance
hit. As soon as the master process has a backlog of a couple of million
blocks from 20 or so different subspaces, it chokes.

Some people justify their flushing by saying: 'But hey, if you can't cope
the load of a couple of million blocks more per day, how are you going to
handle this in the future when these loads are normal?' I hope above
mentioned explanation will show this reasoning is false for once and for
all. We have a perfectly capable master box, its specs are still way
adequate, load testing shows that when blocks are somewhat from the same
subspaces, we can easily handle 1000Gkeys/s with the current hardware.
Normally, blocks from unopened spaces are kept in a separate queue which
is processed at quiet times. When suddenly a lot of blocks come from a
lot of unopened spaces, that theoretical 1000Gkey ceiling jumps down to
a something below our current rate, hence the backlog which is very hard
to get rid of.

With this explanation I hope to have convinced people not to save up too
many blocks. Daily stats are what they are for: Daily rankings. Not for
getting a #1 spot for 1 day because you've saved up more or longer than
your friends. If you really want to be #1, just recruit more computers!

We try to suit as many participants as possible and we are very pleased
with all the enthusiasm distributed.net participants show. But if people
keep doing things against the policies set out by distributed.net staff,
we might have to take measures against it, by blocking people from stats
or changing the lifetime of a block. This is not because we suddenly
dislike those participants, but because we want the contests to be
satisfying for _all_ users. without backlogs, so everyone can have their
blocks tallied in time.

One more thing on backlogs: Backlogs don't mean our system is broken, it
just means our system is handling the load sort of well. We do accept all
blocks, and never give a connection refused on our proxies. We _will_
process all those blocks in the end. Maybe not today, but eventually. So
in the end each and every blocks you flush will be counted. Your stats
total will reflect your total work done. And if we all take care in
flushing to the system as it was designed, backlogs will be kept to a
minimum and daily stats will be correct, too.

Keep on crunching!

ks_choice @bwt • 1 maart 2001 14:51

hele bovenstaande post

Ik vind dat ze wel een beetje aan het (excusez le mot) zeiken zijn. De competitie maakt het voor veel mensen juist leuk. Daar zouden ze blij mee moeten zijn. Anders wil ik mijn PC'tje ook best gewoon idle laten staan, hoor. Als ze echt problemen hiermee hebben, laten ze dan actie ondrnemen ipv zo te klagen. Breng dan idd de levensduur van een blokje omlaag of doe iets anders. Dit heeft waarschijnlijk meer effect dan een klaagzang zoals deze.