When will the remaining 2 disks crash?

Errr...

I think he was just shooting for a bit of a play on words/math with that post. ;)

Heh, I at least got a chuckle out of it!

P.S. Thanks for getting the project back up even faster than anticipated, E@H team!! :D

Greetings :)

Here are some links for any who may be interested.

Intels Answer:
http://www.intel.com/technology/magazine/computing/RAID-6-0505.htm

Hardware Secrets answer:
http://www.hardwaresecrets.com/article/314

And the Math behind it all:
http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

The only problem we have with disk failure is the delays during rebuild time. My current update communication has been deferred for 150 hours :P
Hmmm, perhaps this is something else?

Any word on why 2M of the results were deleted?

Thanx Pooh Bear, I did a manual update and its working again :)

Yeah... I did that too, clearing out about 40 pending results!! Mainly 'shorts'.

Though the server messages do indicate some backing and filling - deletions, re-downloading, new grid data, re-sending lost results, duplicate reports & such. So I'd assume there has been some loss ( beyond timewise ) from the recent down. However now my little farm has resumed crunching more slices of the pie... :-)

Cheers, Mike.

The one week backoff looks like it was introduced somewhere in the 5.3.x or later series of BOINC. I have a couple of boxes still on 5.2.13 which have managed to recover by themselves, although there were still quite a few hours of lost crunching time. At least it wasn't a week for them.

This is now the third time recently that the vast bulk of my farm has had to be manually rescued from its one week coma. I can't wait until they release a production version of the client that fixes this stupidity. I call it stupidity because there appears to be no easy way to break out of this coma automatically, even though there would appear to be usable triggers. For example, whilst the project is offline, the inability to contact the scheduling server quickly leads to the one week backoff. At the same time, the backoff for uploading seems to peak out at around 1-4 hours for each finished result. If you have a reasonable cache, you will end up with multiple finished results, all trying to upload at random times. Now whilst the upload server and the scheduling server are different processes perhaps on different machines, why couldn't the sudden resumption of uploads when the project comes back online be used to trigger a resumption (even if only temporarily) of trying to contact the scheduler so that new work can be downloaded?

I'm probably missing something obvious, but my only recourse for the problem of losing a weeks crunching has been to manually update each machine as soon as the project is back on line. This is fine for most people but quite a problem for me. At the time of these last three outages, I've had close to 200 machines to manually update. Some of this had to be done by going physically from box to box. However most of it could be done from one machine by using Boinc Manager to access the remote machine. By the time you actually establish the connection, examine the various work queues and message lists, hit the update button, watch the messages list to ensure that results are reported and that new work is downloaded, etc, several minutes can easily fly by. Multiply say 3 mins per machine by 200 machines and that's a helluva lot of unnecessary (and very mind numbing) hours that I've just wasted :).

So if anybody knows of an easier way to update 200 machines, I'd love to hear about it. I'm getting mighty sick of doing it manually. The machines are in two separate locations (my home and my work) and are spread over several rooms. The work location has 180+ on a single subnet sharing (through about 15 hubs/switches each from 8 to 24 ports) a single ADSL internet connection. As long as the project is up and stable, everything works fine and everything is very much set and forget. However these recent outages and server flakiness problems have been giving me real headaches.

:-) Well Said :-)
Regards
Masud.