Hi,

my linux host finishes the WU's and after a while they get no credit awarded. Don't understand why because the log doesn't indicate an error or faulty hardware, exit status is normal on all wu's.

Sometimes i get credited, but lots of results come back without points. All graphical libraries are installed.


Example

Thx in advance, DevinK

Due to the fact that the db ran dry of work; the scheduler allowed two different types of hosts to claim the same WU (for validation) at the same time (race condition), with the result being that your WA was not matched to another host of the same hardware class. This should be fixed temporarily now because there is now more work.

m.


____________
M.F. Somers

You should perhaps turn on homogeneous redundancy, as WUs from Lin/Apple and Win don't seem to match.
I've got a lot of WUs where I get invalidated because the other computers of the quorum were Windows, some where a Win got invalidated against two Lin or at least in one case my Lin and a Darwin, and some that went just fine because I was paired with a Lin from the beginning.

It hadn't happened in the past, something seems to have changed either with the app or with the WUs.
____________
Gruesse vom Saenger


For questions about Boinc look in the BOINC-Wiki

I've seen this problem recently on my Linux machine too.

Homogeneous redundancy is turned on; this is a race condition in the shmem-table: when the db has not enough work ready, the two result units of the same workunit are both put into the shmem table to be scheduled to hosts. when at that point two different hosts of different hardware classes each claim a result unit of the same workunit; this race condition happens; both crunch fine; both return results, but it won't match and the server will generate another result unit to be scheduled to find concensus. see? this is a 'design' flaw in the boinc feeder schedulers which weren't exactly made for homogeneous redundancy in the first place.

Our adapted feeder takes this effect into account correctly only if enough work is available in the db. This is a design decision: what would you do if you only have one wu work and with it two result units to schedule; would you not send out the second result to a host and let all hosts wait until the first result has been computed; or do you accept the possibility you will have a mis-match and do schedule it? For the science and project the latter choise is more wise ;-).

m.


____________
M.F. Somers

Homogeneous redundancy is turned on;

No you misunderstand; let me repeat:

"this is a race condition in the shmem-table: when the db has not enough work ready, the two result units of the same workunit are both put into the shmem table to be scheduled to hosts. when at that point two different hosts of different hardware classes each claim a result unit of the same workunit; this race condition happens; both crunch fine; both return results, but it won't match and the server will generate another result unit to be scheduled to find concensus. see? this is a 'design' flaw in the boinc feeder schedulers which weren't exactly made for homogeneous redundancy in the first place."

and explain a bit more:

"What you probably do not know is how the hr_class in the Db is assigned it's value; it starts of with value 0 (meaning any host can get this result unit to crunch) until a host has claimed a result unit and hr_class will get a value corresponding to the hardware class of the machine. After that, the hr_class value is set to a value and only hosts of the same hr_class will get the other rsult unit.

*IF*, however, both result units of a fresh workunit (with hr_class =0) are present in the shmem-table; and two different hosts at the same time claim it (cause hr_class = 0), the final hr_class value is determined by the host with slowest scheduler request. This is a race-condition that happens when fresh results are added to the Db and the Db is running dry."

A bit clearer now?

m.
____________
M.F. Somers

A bit clearer now?

*IF*, however, both result units of a fresh workunit (with hr_class =0) are present in the shmem-table; and two different hosts at the same time claim it (cause hr_class = 0), the final hr_class value is determined by the host with slowest scheduler request.

H'mmm... This I need to investigate; I'm definitely sure HR is turned on otherwise we would have all sorts of other serious problems! It could be that this is a glitch somehow when I temporarily stop and restart the project for maintenance and backups... I did have some issues in the beginning of the month when the DB ran dry and I had to shorten the delay time of jobs a bit... Got no clue yet; but I'm really sure HR is turned on and is working fine...

m.
____________
M.F. Somers

Just wondering what happened to this result:

25239302 10923457 5 Oct 2010 13:15:37 UTC 7 Oct 2010 1:27:11 UTC Over Success Done 37,624.66 196.61 pending

25239285 10923439 5 Oct 2010 13:15:37 UTC 6 Oct 2010 2:33:11 UTC Over Success Done 16,963.88 88.64 0.00

The 2'nd result on here was a success but granted 0 credit. Just wondering if something is up with my hardware. Thanks