Nieuwe .plan Update van Ivo

[Wceend]

distributed .plan updates in the last 24 hours:
---

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!

Dit is het officiele antwoord van D.net op al het gezeik.

[Bulldog]

Is duidelijk, vind het netjes uitgelegd.

[Burat]

Idd..

Tnx Ivo!

[Coen Rijkaart]

Wat ik me wel afvraag is hoe het zit als je in een keer een hele berg pakketjes download en deze wel gewoon flushed nadat je ze geprocessed hebt.

Stel je download in 1 keer genoeg pakketjes voor 30 dagen, volgens mij aan het einde van die 30 dagen stuur je ook pakketjes op uit keyspaces die niet 'COMMON' zijn, terwijl je wel braaf elke dag je verwerkte pakketjes opstuurt.

Of mag je volgens de policies ook niet extreem veel pakketjes per keer downloaden?

[Sequence]

dan heb je niet te maken met hele grote hoeveelheden lijkt me.. en dan die blokjes die je die dag flusht ook uit 1 (andere) keyspace

ivo:>> lekker duidelijk! tnx!

[Frenzy]

top dat je ook je amerikaanse collegae op deze manier inlicht over de situatie alhier

[Dutchman!]

toppie idd

[IceStorm]

Heel netjes....

Enige wat ik nog wil weten is hoe die 'spaces' ontstaan? Ik bedoel.. ik heb nu een buffer van 1000 blocks en die werk ik gewoon af... Maar wanneer komen er dan 'spaces' in ?

[Verwijderd]

Een subspace is niets anders dan 1/256 deel van de gehele set van mogelijke oplossingen. (zo'n reeks mogelijkheden wordt in de wiskunde een 'ruimte' danwel 'space' genoemd). De rc5-64 keyspace is 2^64 groot en die zijn opgedeeld in 256 keer 2^56 subspaces. Elke subspace bestaat uit blokken van 2^28 keys elk, dus elke subspace bevat 2^28 blokken/workunits. 2^28 bits = 32Mbyte. (1 bit per block omdat alleen maar aangegeven hoeft te worden of het block gedaan is of niet, de id/cpu/os/ver info staat in de logfiles)

[IceStorm]

Ok.. dus als ik het een beetje redelijk snap dan krijgen 'jullie' tijdens een megaflush teveel blocks uit verschillende 'partijen' binnen en dat vindt de keyserver niet leuk ...

Ok, thx

[Verwijderd]

Op donderdag 01 maart 2001 13:15 schreef leto het volgende:
...
De rc5-64 keyspace is 2^64 groot en die zijn opgedeeld in 256 keer 2^56 subspaces.
...

Ik meen me te heugen dat in een .ini van een wat oudere client ik wel eens gezien heb dat de randomprefix op 255 stond, maar die komt tegenwoordig niet meer voor in een ini-file.
Betekent dit dat "we" inmiddels al die 256 supspeeses al een keer rondgeweest zijn en nu dus bezig zijn met heruitdelen van workunits?

[jvdmeer]

Een subspace is niets anders dan 1/256 deel van de gehele set van mogelijke oplossingen. (zo'n reeks mogelijkheden wordt in de wiskunde een 'ruimte' danwel 'space' genoemd). De rc5-64 keyspace is 2^64 groot en die zijn opgedeeld in 256 keer 2^56 subspaces.

Voor het uitrekenen van de juiste key, hoefde toch maar de helft, 2^63 mogelijkheded te worden uitgerekend?

[Onno]

Waarom dat?

[IceStorm]

Op donderdag 01 maart 2001 19:58 schreef Onno het volgende:
Waarom dat?

Altijd maar de helft van het aantal oplossingen... Je hebt hem wel of je hebt hem niet

* IceStorm is irritant.. i know

[witchdoc]

kan iemand effe linken naar 'het bewuste topicje'?
ik vind er zo dadelijk niks over terug

[--Mulder--]

Dit gewoon een duidelijk uitleg

Iedereen weer tevreden

Groeten van de
[DPC] Twentse Gekke Koeien

[PieterJ]

Op donderdag 01 maart 2001 22:11 schreef poohbeer het volgende:
kan iemand effe linken naar 'het bewuste topicje'?
ik vind er zo dadelijk niks over terug

Pooh, Deze en deze

[witchdoc]

veel leesvoer :)ben nu thread 1 gepasseerd en onderweg met 2..
lijkt mij dat d.net 1 grote fout heeft gemaakt, en da's dat gedoe met spaces niet wat sneller wijder bekend maken..
iedereen redeneerde verkeerd dus snapten ze het probleem niet.. nu snapt iedereen die dit heeft gelezen het probleem tenminste..

Misschien wel de moeite voor een frontpage artikeltje btw? Bereiken we nog wat meer mensen denk'k

[witchdoc]

Op woensdag 28 februari 2001 21:30 schreef leto het volgende:
hoihoi

nogmaals een keer: Onze hardware voldoet. Een snellere compu, hoe vet je hem ook maakt, zal er niet voor zorgen dat blocks uit 20 open subspaces geen backlog vormen. de master is gewoon geoptimaliseerd voor het snel verwerken van blocks uit 1 of 2 spaces en dat algoritme gaan we ook zeker niet veranderen, want dit is hoe we het graag willen, en expres zo gedesigned.

Maar toch bedankt voor het idee

nu, niet om nog eens een boel gezeik te starten, maar lees ik hier nu tussen de lijntjes door dat d.net best wel die master zou kunnen programeren zodat ie wel meer dan 2 spaces aan zou kunnen?!

Wordt hier nog ergens over verder gepraat/verduidelijkt door die d.net mensen of hou'k best gewoon me muil?

[Dutchman!]

De software optimalisatie gaat niet worden veranderd, want dan zou je de tijd bij MegaFlushes verbeteren en de tijd van de dagelijkse run evenredig verslechteren. Het lijkt mij dat je niet een keer in de week stats wil

[witchdoc]

Op vrijdag 02 maart 2001 00:16 schreef Dutchman! het volgende:
De software optimalisatie gaat niet worden veranderd, want dan zou je de tijd bij MegaFlushes verbeteren en de tijd van de dagelijkse run evenredig verslechteren. Het lijkt mij dat je niet een keer in de week stats wil

klopt halm en half, maar als hun amd k6 niet eens 100% gebruikt wordt kan door middel van een nieuwe programmatie tesamen met een fatsoenlijk t-brid ofzo EN de dagelijkse EN de flushes worden bijgehouden.. of mis ik weer iets?