LHC@home

initial replication 3

No, don't worry about that. It's a well-known terminological inexactitude (mistake) in the BOINC server code.

Two tasks were sent out on 30 Oct 2012, an initial replication of two.

When they failed to agree, a third instance was created and sent out on 3 Nov 2012, to make a current replication of 3.

BOINC updates the number, but it doesn't update the word.

Sort of...YES 2 were initially sent out, but the 1st unit errored out the same day and the 3rd unit was sent out 2 days AFTER the 2nd unit was returned to the Project. 2 units were sent out 30 Oct, 1st unit returned the same day, 1 unit returned 1 Nov. The 3rd unit was sent out 3 Nov and returned 4 Nov. This could be due to VERY slow Server responses or a Server 'glitch' that ended up causing the current situation. The replacement unit SHOULD have been sent out immediately after the 'inconclusive' unit was returned, NOT 3 days later.

COULD this be a part of the problems of not sending the bad units to another user? Is the Server NOT recognizing the invalid or inconclusive units properly and therefore NOT resending the units?

Sorry, not true (if we're looking at the same workunit). Both of the first two tasks returned 'success' status, so no problem could possibly be detected until the second report was received at 1 Nov 2012 | 6:44:33 UTC, and the validator was able to detect the mismatch.

After that, the third - tie-breaker - task 9891207 was created at 1 Nov 2012 | 6:44:48 UTC. 15 seconds for task creation isn't excessive: the delay between creation and distribution is a queue function, as we've discussed elsewhere.

It's just a very, very busy project. They maintain a 'high water mark' of around 300,000 tasks ready to send, and turn over about 60,000 tasks per hour - so the end of the queue is never more than five or six hours away.

That sounds simple enough that it could be made to work here too. The trick is having the code to do it and setting the high/low water marks appropriately. For example, if Eric has a batch of 179,249 tasks, just to pick a nice not-round number, then he ought not to dump all 179,249 into the queue at once. There needs to be a high water mark of say 2,000 and a low water mark of say 1,000. The batch starts with the feeder, splitter, or whatever its name is, dumping 2,000 tasks into the queue. When there are only 1,000 tasks left in the queue the feeder/splitter/whatever dumps all the resends into the queue and follows those with enough tasks to fill the queue to the high water mark. Eventually all 179,249 tasks have been put into the queue with all the resends sprinkled in as well at the beginning of each top-up. There should be only a short tail which won't matter anyway because even if Eric creates another big batch the tasks in the tail will go into the queue first before tasks from the new batch.

Now the milllion dollar question is.... Is there server code available that does that? Is that code already installed? If so what are the names of the options/config items that make it happen?

The keywords to look for are 'Work generator' (as used at Einstein) or 'workunit generator'. 'Splitter' is a specialised version of a WU generator used at SETI: 'feeder' is a different animal altogether, and doesn't belong in this list.

initial replication 3

No, don't worry about that. It's a well-known terminological inexactitude (mistake) in the BOINC server code.

Two tasks were sent out on 30 Oct 2012, an initial replication of two.

When they failed to agree, a third instance was created and sent out on 3 Nov 2012, to make a current replication of 3.

BOINC updates the number, but it doesn't update the word.

2) I've just come across a wee problemette - WU 4413334. I think the middle one should have been set to 'invalid' after the third user reported - I'm not sure whether it will be properly marked off as completed like this.