Since the scheduler can request a person's BOINC client to defer communication for a certain amount of time, would it be possible to set the scheduler to defer everyone for say 24 hours? maybe 12 or 6 even? That would minimize people's PCs banging on the scheduler incessantly...

The potential problem with that is if it causes someone to miss a deadline...

Brian,

Keep in mind that deadlines aren't that absolute. I would expect the validators/assimilators/transitioners would be off for a while (partially to let the splitters run, and partially to extend deadlines).

... and we'd all come up to speed again much faster if they throttled the BOINC clients to near-optimal server-load.

-- Ned

I said "if"...

:sigh:

My point was, no matter what is done, someone's not going to be happy...

... and even if they miss the deadline and still get credit, they'll probably be unhappy.

... as will those who are deferred 24 hours just before things come back up.

SETI has always said "there will be times when there is no work" and yet many expect nothing less than 100% availability.

---

Should there be a replica master science database as a backup to operate in case of an emergency like this one?

Heck, if they want to send one out my way, I'd be willing to wait until friday AFTERNOON for it.

Actually, Sun are quite willing to send you one. All you have to do is send them a video telling them why you should have it. ;) You can always donate it to S@H. ;)

---

Be lucky

Neil

Since the scheduler can request a person's BOINC client to defer communication for a certain amount of time, would it be possible to set the scheduler to defer everyone for say 24 hours? maybe 12 or 6 even? That would minimize people's PCs banging on the scheduler incessantly...

The potential problem with that is if it causes someone to miss a deadline...

Brian,

Keep in mind that deadlines aren't that absolute. I would expect the validators/assimilators/transitioners would be off for a while (partially to let the splitters run, and partially to extend deadlines).

... and we'd all come up to speed again much faster if they throttled the BOINC clients to near-optimal server-load.

-- Ned

I said "if"...

:sigh:

My point was, no matter what is done, someone's not going to be happy...

... and even if they miss the deadline and still get credit, they'll probably be unhappy.

... as will those who are deferred 24 hours just before things come back up.

SETI has always said "there will be times when there is no work" and yet many expect nothing less than 100% availability.

The solution is for the server to respond to work request with NO WORK, CALL BACK IN XX HOURS

---

Thanks for the continuing patience and encouraging sentiments since the science database server crashed over a week ago. Still waiting on the server replacement. I think we're all anxious for it to arrive already, but we originally expected it no earlier than late-in-the-day today.

We had the usual database backup outage, in case anybody noticed. Outside of the usual backup/compression of the BOINC database, I fixed the replica server, so that's back up and running again. I also rebooted our Network Appliance which has been complaining about "misconfigurations" as of late, but that didn't seem to help or hurt. We think a bad drive in the system is causing these errors. I then replaced a bad drive in the Snap Appliance so that's back to having two working hot spares (phew). Jeff, Eric, and I also cleaned up the lab. Entropy reigns supreme around here. The table which we sit around and eat lunch was full of miscellaneous screws, heat sinks, empty drive trays, shredded bubble wrap, etc. but not anymore.

- Matt

---

How I understand you Matt ;-)

Meanwhile climate predition is very happy... eheheheheheh

---

Should there be a replica master science database as a backup to operate in case of an emergency like this one?

It's only a question of money. See Home>Donate, it's all there

---

The solution is for the server to respond to work request with NO WORK, CALL BACK IN XX HOURS

5/9/2007 12:42:26 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
5/9/2007 12:42:26 AM|SETI@home|Reason: To fetch work
5/9/2007 12:42:26 AM|SETI@home|Requesting 259200 seconds of new work
5/9/2007 12:43:26 AM|SETI@home|Scheduler request succeeded
5/9/2007 12:43:26 AM|SETI@home|No work from project
5/9/2007 12:43:26 AM|SETI@home|Deferring scheduler requests for 1 hours, 38 minutes and 22 seconds

... and even if they miss the deadline and still get credit, they'll probably be unhappy.

... as will those who are deferred 24 hours just before things come back up.

SETI has always said "there will be times when there is no work" and yet many expect nothing less than 100% availability.

None of the project team has specifically stated that missed deadlines will be considered / revalidated, so that is at best an "if" situation too....

...and as far as the 100% uptime, yep... I wonder if those folks consider the situation in reverse...that they do not give 100% of their processor's uptime...

The solution is for the server to respond to work request with NO WORK, CALL BACK IN XX HOURS

5/9/2007 12:42:26 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
5/9/2007 12:42:26 AM|SETI@home|Reason: To fetch work
5/9/2007 12:42:26 AM|SETI@home|Requesting 259200 seconds of new work
5/9/2007 12:43:26 AM|SETI@home|Scheduler request succeeded
5/9/2007 12:43:26 AM|SETI@home|No work from project
5/9/2007 12:43:26 AM|SETI@home|Deferring scheduler requests for 1 hours, 38 minutes and 22 seconds

Server only said not work. Client decided when to retry. Client should have got the retry time from the server.

---

IT IS VERY QUIET....TOO QUIET WITHOUT THE SERVER AND WORK UNITS. BUT A REPLACEMENT BY SUN WILL SAVE THE DAY. THANKS SUN!

---

Should there be a replica master science database as a backup to operate in case of an emergency like this one?

... all that takes is money.

---

... and even if they miss the deadline and still get credit, they'll probably be unhappy.

... as will those who are deferred 24 hours just before things come back up.

SETI has always said "there will be times when there is no work" and yet many expect nothing less than 100% availability.

None of the project team has specifically stated that missed deadlines will be considered / revalidated, so that is at best an "if" situation too....

That has been their practice in the past (to "extend deadlines" by not running all the processes right after an outage).

---

Just curious: what is the backup plan in case the motherboard delivery is delayed or that the 'rebuild' doesn't go as hoped for (something else is wrong) and the project can't get going next week?

Would it make any sense to move the affected project application to the existing (functional) high end servers, throttle down the WU creation/acceptance rates, and live a more austere existance (metaphorically speaking) for a while? It would take some work, but what recourse do you have if the fix doesn't go as expected?

Speculatively speaking, this situation seems like a good reason to run the project on VM's.

That has been their practice in the past (to "extend deadlines" by not running all the processes right after an outage).

One of my favorite scenes from the "Enter the Matrix" video game, when Ghost is asked why he checks his guns whilst in the loading construct:

"Hume teaches us that no matter how many times you drop a stone and it falls to the floor, you never know what'll happen the next time you drop it. It might fall to the floor, but then again it might float to the ceiling. Past experience never proves the future."

Condolences on your loss.

Would it help if we 'suspended' our SETI clients until the sys is up and thus avoid a heavy demand for new work units?

As SETI is still taking in finished units, the dealine issue is a non issue. When units are sent out there will be appropriate deadlines based on past practice. (IMHO)

... and even if they miss the deadline and still get credit, they'll probably be unhappy.

... as will those who are deferred 24 hours just before things come back up.

SETI has always said "there will be times when there is no work" and yet many expect nothing less than 100% availability.

None of the project team has specifically stated that missed deadlines will be considered / revalidated, so that is at best an "if" situation too....

That has been their practice in the past (to "extend deadlines" by not running all the processes right after an outage).

---

"It is better to be hated for what you are then to be loved for what you are not"
- Andre Gide (1869-1951)

Hallo,
I!m Whisper from Belgium.
I found it real sloppy off the organisation, that they didn't did the effort to mail al the volonteers off this long offline beeing. (mails for donations can wel).
I hope that the will have more respect fore the thousenden free volonteers who give their pc and electricite on this science job.
But if a still so unfair keep treated, no mail with a word of explanitian, i consider to stop right now.
sssa mail with explainanation , and wath will happen and when we can expect the first work ,en so on is the least they coud do.

Greet Gerard

---

Doe maar gewoon, dat is al gek genoeg.

hahaha always the same hard disk bad or server too hot hd not recognised hahaha all them littele green man are laughing with us but Belgium is patient and we wait and hopes with you that the new server can keep up with us hot hot hahaha greetings belgium

---

(so, for UNIX u haven't to pay a license.)

Only if you steal a copy.
LINUX & BSD are based on UNIX, but they are not UNIX.

BSD is UNIX. FreeBSD, OpenBSD and netBSD are not UNIX.
Tullio

I would like to remind people that the B in BSD stands for Berkeley.

Touche' .... and let me tell those that don't know that BSD was generated initially from UNIX version7 tapes obtained from AT&T under an educational license available from AT&T at the time. This was what was on the BSD 2.8/2.9 tapes used on the PDP-11... Afterwards, BSD 4.3 was released for the VAX and other systems available back then.. This was based on the AT&T UNIX SYSTEM3 tapes (the immediate predecessor of SYSTEM5)... System5 was never really released on an educational license, so, any SYS5 code or clones thereof needed to be added to BSD a bit at a time (not literally bit by bit..) What parts were added and not omitted....

So, that is where the BSD variants parted company with other systems that were based on SYSTEM5... The final AT&T UNIX SYS9/PLAN9 was never released by AT&T, so, there is no way of knowing whether or not any of the code ever leaked and were or were not incorporated into Linux or BSD.

Regardless of it's specific parentage or direct or indirect heritage, BSD,Linux and UNIX ... i.e. *NIX is one heck of an O.S. And... it's all UNIX, no matter what the specific flavor...