What a weekend. As noted by the others they successfully got the replacement science database server from Sun and brought it to the lab Friday afternoon. As we hoped it was basically plug n' play after putting the old thumper's drives in it. After some file system syncing and data checking Eric started the splitters on Saturday. All was well until bruno's httpd processes choked (more on that below). So we were not sending work for a whole day until Jeff kicked bruno this morning. The bright side is this allowed the splitters to create a whole pile of work in the meantime which we are sending out right now as fast as we can. The main bottleneck is NFS on the workunit file server which is (and always has been) choking at around 60 Mbps. It'll take a while for things to catch up.

We officially retired both koloth and kryten as of today - both are powered down, and in the case of koloth completely removed from the closet to make way for thumper, sidious, and then some. With the closet as empty as it has been in a long time I finally removed dozens of unused SCSI/ethernet/terminal/power cables that came with the rack, all tucked in various corners and secured with cable ties. The process of cutting the tightly wound ties in sharp metal cages left me with four bleeding wounds on my hands - nothing bad, only two required band aids - but I've wanted to get that particular clutter out of that rack for years.

With koloth and kryten gone bruno has been taking up most of the slack. I noticed last week it gets into these periods of malaise where httpd just stops working. I think this may be buggy restart logic when we rotate web logs, but it's a little weirder than that. Adding insult to injury one of its internal drives just up and died today. Luckily it was a RAID spare so nothing was harmed, and we had replacement drives already donated to us a while back. Eric replaced the drive, but we may need to reboot to fully pick it up. Probably during the usual outage tomorrow. Bruno is dropping lots of packets right now, resulting in all kinds of upload/download snags and showing up as "disabled" on the server status page. This should clear up over time.

The server situation will be in major flux, and generally in a positive direction, over the next week or so. I'll be trying to keep updating the server status page, but I make no guarantees about its accuracy.

Thanks again for your patience during the past couple of weeks. While I appreciate the kind words and sentiments I should point out that this past weekend for me wasn't exactly restful time off. I was working at
my other job.

- Matt

Have you allowed BOINC.EXE, BOINCMGR.EXE and BOINC.SCR complete access through the Windows firewall?

UPDATE: 27 Sep 2006
Have made sure FIREWALL allows ALL BOINC connections to work. When setting url, use http://setiathome.berkeley.edu
Response from server is "Project encountered internal error: shared memory violation"
Have tried everything suggested from this end. Any ideas???????????????????????
Any help is gratefully accepted. Andy is now holding pistol to monitor!!!!Axe is near at hand in case I miss!!!!!!

Checked the firewall, and it lets BOINC through. When I enter the URL, http://setiathome.berkeley.edu,
I get the error message.This is fustrating, to the point of being discouraged from continuing. The error message indicates a SHARED MEMORY VIOLATION.
Does this give you any ideas?I suspect something to do with BOINC having me registered, and maybe I didn't detach correctly?

I'll try a "clean" start to the program.

Have you allowed BOINC.EXE, BOINCMGR.EXE and BOINC.SCR complete access through the Windows firewall?

Have you allowed BOINC.EXE, BOINCMGR.EXE and BOINC.SCR complete access through the Windows firewall?

WRONG!!!

From Tech news

March 2, 2006 - 21:15 UTC
So it turns out the master database storage arrays had three drive failures during the long and thorough RAID resync process. We had two hot spares and a spare drive on the shelf. This, along with the fact that the array was RAID 10, means that we shouldn't have lost any data, but the resync process took extra time to do deal with these lost drives.
Why did we lose so many drives? These are old storage arrays donated to us a while ago, and the disks came with heavy wear and tear. We already had several other disks fail in this system so this is no big surprise. Once everything is resync'ed (in about 20 minutes from the time of writing) we'll start up the master database, check its tables (which may take as long as 24 hours), do some other hardware testing, and if all is well start up the assimilators/splitters again. If not, we might be out for an extra day as we continue to clean up.