Task 15475090 finally completed for me - a lot of time on dual core atom netbook which will not be getting any more full resolution ocean models! got Workunit error - check skipped against validate state. All the other units I have noticed that completed successfully had initial against validate state. Just wondered if this means anything significant or not? I suspect the latter but wish to indulge my idle curiosity.

Congratulations :-)


The 'validate' stuff is not used at CPDN because it is done later statistically by the researchers.

---

I'm a volunteer and my views are my own.
News and Announcements and FAQ

Technically, what it means to BOINC is that your task is the only good one in that work unit (all the earlier tasks failed), so its result cannot be compared to the others.

(BOINC was designed on the assumption that two different computers processing a task would produce results that are identical, bit for bit. If this were true a simple comparison of results would be a useful check for correct data transmission. But climate models break that assumption.)

Since CPDN never runs the BOINC cross-checking ("validation") code, tasks keep whatever "validate state" BOINC's end-of-task code assigns: for failed tasks, "Invalid"; for most good results, "Initial"; and for the last result and only good one of a bad bunch, "Workunit error - check skipped".

Thanks Greg and Mike, I knew that cpdn didn't use the BOINC validation but not that it still told me something about the work unit. Probably be a long time till I notice that particular message again.

(BOINC was designed on the assumption that two different computers processing a task would produce results that are identical, bit for bit. If this were true a simple comparison of results would be a useful check for correct data transmission. But climate models break that assumption.)

Not exactly, BOINC was designed on the assumption the projects would write their own validator, but did include two generic validators, one is the bit-by-bit comparison and the other is "everything validates". Example, the SETI-validator allows 1% variation between most signal-strengths, but at the same time demands the signals is at the same frequency.

Since the validator is project-specific, a CPDN-validator could example check if all trickle-files was reported, all files is uploaded and can also do some other checks on the results. A CPDN-validator doesn't need to compare to other results for wu, meaning no problem with different results.

By running validator & Assimilator, CPDN could also run db_purger, meaning wu's finished would be archieved and removed from database. One obvious advantage here is, finished wu's wouldn't spawn a re-send doomed to fail with download-error 1.5x after the deadline. Another advantage is the database would be kept smaller, and don't need to do the ocassional manual archieving often leading to problems as CPDN has been doing...