In other projects a workuint is what it is.
Here is a workunit a trickle or the entire model?

Reason I ask this is that from the server stats page the \"Workunits waiting for validation\" stat is at 90,700 odd and rising. If workunits are trickles then I would hope that this stat would be falling.

Any info would be appreciated.
Thanking you

---

A wu is the entire model !

---

Oooops, sorry, I\'m not project staff, so I shouldn\'t have answered your question. Must be really going offtrack here!

---

No WUs here just models, some of us use WU to describe the models which is incorrect.

---

BOINC Wiki

Hi Jim K and Kilcock.

So the workunits here in the database/file status are wrong?
Sorry to seam a little dense about this but I\'m confused.
I\'m trying to sort out how long it will take for the trickles to catch up.

When I first noticed that there WAS a server status page, This is what it said:
As of 1 Oct 2005 20:30:46 UTC = Workunits waiting for validation 25,831

The next time that I saved the page it was:
As of 21 Dec 2005 18:06:58 UTC = Workunits waiting for validation 57,004

Currently, it says:
As of 3 May 2006 3:54:34 UTC = Workunits waiting for validation 90,829

The first two were \'normal\' processing times, as far as I can remember. And both were before the BBC invited the whole of the UK to join in.

edit
And the first two were also only for slab and sulphur, which were shorter, and had less trickles.

I wonder if that is the number of incomplete WU/models that have been returned.

My first thought was they say waiting for validation and stay as such until a validation process is run. CPDN doesn\'t have a validation process like other BOINC projects (which do redundant computing) so all finished models stay there. However the number of completed models is higher than 90,829 so they cannot all be staying in an unvalidated state. This leaves a few possibilities one being that the validation routine just checks they are complete and if so removes them from unvalidated.

Other possibilites include it is the number of models returned since a date that is later than the beginning of BOINC.

---

Visit BOINC WIKI for help

And join BOINC Synergy for all the news in one place.

We don\'t run \"validators\" in the BOINC sense, so that\'s just an accumulating number of models crashed or returned.

It could also be that there are still some checks which are done server side to assure the results returned fit within some reasonable limit... Although not running a redundancy run doesn\'t allow one to compare them, some rather gross mis-calculations might be quite obvious.

For example, and not really related to this project. But if someone was doing measurements, and came up with some negative value... Umm, what is negative space? How could an object be -3.0 meters in length? Something like that would be just too illegical to use as a figure for further calculations...

Course, I\'m not with the project, and am not entirely sure what they\'re code is doing, so can\'t say definitively. But some sort of validation checks for certain gross errors, which simply could not be an accurate calculation by any logical conception, might not be beyond reason...

There is one thing which could get one wondering here however:

- On Rosseta for instance, if a person checks their account for granted credit, then reports a finished WU, and checks it again; Rosseta which also uses no quorum grants credit immediately, and one\'s credit score immediately goes up.

- On CPDN however (and also seasonal), if a person checks their credit score, then enables networking (lets say) to allow it to trickle in. Now one checks it again, and the credit score isn\'t immediately incremented.

In fact, it has taken (from my experience) several hours to increment. Now add mention of validation, along with trickling in resulting in a delay before credit is applied. Could it be, that they do have a validator of sorts, that does some rudementary checks such as I\'m postulating are possible. And then if those checks pass, then the trickled in credit is applied? The other possibility would be a delay in the databases updating each other. Someone, on the project, probably has a clearer idea on which it would be...

---

Negative values are checked in the had* software, and cause a model crash at that point.

The trickles and credits USED to be registered/granted almost immediately, but this was altered to a longer period, because the constant calcs were slowing down the other server software, as the database went from huge to ... something bigger.
(Carl mentioned 7Gigs for the results table, in December last year.)