From the front page:

November 14, 2006
A configuration problem on our servers have caused workunit downloads to fail since yesterday afternoon. This has been fixed. However, we are bringing the whole project down for our regular Tuesday outage to back up our database. We should be back up in a few hours (22:00 UTC).

Be patient, they are working on it.

Actually, they fixed it about three hours ago (before 21:00 UTC - beating their own estimate!). Might be useful to bookmark this page.

Still, we definitely have a long catch-up period this time, and things will be slow for a while yet.

Actually, they fixed it about three hours ago (before 21:00 UTC - beating their own estimate!).

Sure doesn't look like it based on the machines here.

Hmmm, I don't know. The INR-688 interface to Cogent "flatlined" yesterday around 3 PM Berkeley time, so it would seem they knew they were in trouble before they left yesterday (Also an afternoon time frame was mentioned in the news item).

Still, the extra curricular activity factor may have played a part in how long it was out. ;-)

Alinator

Sure, it flatlined, but can you infer that they knew ;-) ?

a) Were they there? I don't know if it was a holiday / team meeting / awayday / schmooze the sponsors / fit a new receiver at Arecibo / anything else sort of day. All goood reasons for not fixing it.
b) Did they notice? Do they have a flat-line alarm? Not a good reason for keeping us in the dark. Even while all the new development is taking place, they should nominate someone to mind the shop during working hours.

Likely a big backlog....I have JUST received 7 downloads...AND SETI also now sees my preferences ie 1.5 days...something it hasn't done in about a week. Maybe (likely) our good friends at Berk. have been working on that earlier reported issue too. Horray....

---

It's my guess that his client has requested X seconds of work from seti and the order was filled, but just hasn't reached him yet, so the puter thinks it has X seconds on hand when infact it doesn't. The scheduler has already taken that into account and isn't requesting other work. Atleast, I think this is correct.

So when the download is finally completed, he would have X seconds on hand, and if the code was changed to see the non existent download and actually get work from elsewhere, then if the outage was short, the host would be overcommitted and risk missing deadlines.
tony

I think that's what is happening. This is one rare situation when micro managing may be needed. As I mentioned, suspending seti for a minute allowed other projects to download some work and keep my hosts busy, at least for a while.

Harri

This is a known issue in the current release, where it does CPU scheduling system-wide. The current beta does scheduling on a per-core basis.

Actually, there is a problem with the current code as well. If the only contactable project with a higher LTD than -task switch interval is acknowledging work requests by granting work, but the download server is off line, then the BOINC client believes that it has enough work on the way and should not request any more (when it actually does not have work on the way). I believe I have found a fix that will go into 5.7.4 or so.

---

BOINC WIKI

If I were to think that traffic In/OUT is no longer happening because the server has issues, then the higher volume of traffic will appear to flatline.

So the NFS issue prevents the traffic from happening... the lower volume of traffic is workstations trying to connect...

Hmmm, I don't know. The INR-688 interface to Cogent "flatlined" yesterday around 3 PM Berkeley time, so it would seem they knew they were in trouble before they left yesterday (Also an afternoon time frame was mentioned in the news item).

Still, the extra curricular activity factor may have played a part in how long it was out. ;-)

Alinator

Sure, it flatlined, but can you infer that they knew ;-) ?

a) Were they there? I don't know if it was a holiday / team meeting / awayday / schmooze the sponsors / fit a new receiver at Arecibo / anything else sort of day. All goood reasons for not fixing it.
b) Did they notice? Do they have a flat-line alarm? Not a good reason for keeping us in the dark. Even while all the new development is taking place, they should nominate someone to mind the shop during working hours.

---

Please consider a Donation to the Seti Project.

All the machines I can see say "Activities Suspended" No processing--things are just stopped. Restarted boinc, updated project, etc. Nothing.

This is a known issue in the current release, where it does CPU scheduling system-wide. The current beta does scheduling on a per-core basis.

Actually, there is a problem with the current code as well. If the only contactable project with a higher LTD than -task switch interval is acknowledging work requests by granting work, but the download server is off line, then the BOINC client believes that it has enough work on the way and should not request any more (when it actually does not have work on the way). I believe I have found a fix that will go into 5.7.4 or so.

John, just to make sure I'm reading this right.

Let's say say Project A has the highest LTD, Project B the next highest, Project C next, and so forth.

Project A is returning a NNW on requests, Project B is sending work but DL's are failing. You're saying that when the work for Project A runs out and BOINC discovers the result for Project B is unrunable it won't fall back and DL a result from Project C?

Alinator

Hmmm, I don't know. The INR-688 interface to Cogent "flatlined" yesterday around 3 PM Berkeley time, so it would seem they knew they were in trouble before they left yesterday (Also an afternoon time frame was mentioned in the news item).

Still, the extra curricular activity factor may have played a part in how long it was out. ;-)

Alinator

Sure, it flatlined, but can you infer that they knew ;-) ?

a) Were they there? I don't know if it was a holiday / team meeting / awayday / schmooze the sponsors / fit a new receiver at Arecibo / anything else sort of day. All goood reasons for not fixing it.
b) Did they notice? Do they have a flat-line alarm? Not a good reason for keeping us in the dark. Even while all the new development is taking place, they should nominate someone to mind the shop during working hours.

Apparently according to the Tech News they were busy enough worrying about other issues they *didn't* realize new work wasn't going out the door. ;-)

Oh well, things like that happen from time to time (even if alarms go off, just ask the guys at TMI). :-)

Alinator

Well, I have been (and still am) away on travel during this, and these are my observations. I usually get 17k per day. about 10k of that are machines that run SETI exclusively. The rest (11 machines) run SETI/Rosetta/WCG at 100/50/50. During the outage, I made 10.8. Now, the SETI-exclusive machines were running on a setting of 1.3 (or greater) days of work.

This tells me that one of two things happened:

1) I lost almost all the points on the mixed project machines...they sat idle, when they could have just worked on the other two projects instead.

or

2) The "Connect to network about every..." setting does not do what I have been told it does. And no, this is not attributable to the recent bug. These machines have been on the 1.3 days for (forgot to write) over a month now.

I'm guessing #1 based on other posts in this thread. So....we have uncovered a real bug, IMO. And a serious one at that.

---

Dublin, California
Team: SETI.USA

This is a known issue in the current release, where it does CPU scheduling system-wide. The current beta does scheduling on a per-core basis.

Actually, there is a problem with the current code as well. If the only contactable project with a higher LTD than -task switch interval is acknowledging work requests by granting work, but the download server is off line, then the BOINC client believes that it has enough work on the way and should not request any more (when it actually does not have work on the way). I believe I have found a fix that will go into 5.7.4 or so.

John, just to make sure I'm reading this right.

Let's say say Project A has the highest LTD, Project B the next highest, Project C next, and so forth.

Project A is returning a NNW on requests, Project B is sending work but DL's are failing. You're saying that when the work for Project A runs out and BOINC discovers the result for Project B is unrunable it won't fall back and DL a result from Project C?

Alinator

Depends on the LTD of C and whether the system is otherwise in EDF. If the system is not in EDF and the LTD of C is above the cutoff, then work would be fetched. Otherwise not. This is a bug for which I have submitted a fix. It did not make it into 5.7.4 as that came out immediately after I submitted the fix, but before anyone had a chance to look at it and check it in.

---

BOINC WIKI