When reporting I got this:

11/15/2017 8:32:51 AM | SETI@home | Project is temporarily shut down for maintenance

---

One server tuneup, coming right up.
Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

One server tuneup, coming right up.
Meow.

And already (provisionally) complete.

We had a drive in the array that holds the workunits that was generating errors. I've kicked it out of the array. We'll see if the rebuild fixes the problem.

I don't like the looks of WU 2739307008. One host successfully downloaded and ran it. Everybody else is getting D/L errors on it, 5 hosts so far. My machine's Event Log shows:

11/9/2017 7:17:34 AM | SETI@home | Started download of blc24_2bit_guppi_57895_43958_HIP91357_0024.29905.818.23.46.0.vlar
11/9/2017 7:17:38 AM | SETI@home | Finished download of blc24_2bit_guppi_57895_43958_HIP91357_0024.29905.818.23.46.0.vlar
11/9/2017 7:17:38 AM | SETI@home | [error] MD5 check failed for blc24_2bit_guppi_57895_43958_HIP91357_0024.29905.818.23.46.0.vlar
11/9/2017 7:17:38 AM | SETI@home | [error] expected 4bb0fee3928609f2b1df21e44ac13b4e, got 450a32005c6700d7ab95284edc959572
11/9/2017 7:17:38 AM | SETI@home | [error] Checksum or signature error for blc24_2bit_guppi_57895_43958_HIP91357_0024.29905.818.23.46.0.vlar

I just downloaded the WU manually and didn't seem to have any errors. The file doesn't appear to be truncated, either, ending with "" as the last line.

I just downloaded it as well. I got a manual MD5 of 450a32005c6700d7ab95284edc959572, the same as BOINC calculated for yours: that would suggest that the MD5 stored in the database when the file was created (so that the comparison can be done) might be corrupted.

EXCEPT: the person who downloaded the _0 replication got a clean download. _1 was a file size error (my download was 720,530 bytes, which is close enough without knowing the precise number of bytes expected): all the others got the MD5 error.

Which suggests that something was messing with, either, the database MD5 values, or, the stored files on disk. Neither really bears thinking about, and both are a long way outside our control. As Rob says, take the day off.

---

@SETIEric@qoto.org (Mastodon)

I see we've got some blc_25 WUs now. Looks like they require more work than the blc_24s did.

---

Grant
Darwin NT

We had a drive in the array that holds the workunits that was generating errors. I've kicked it out of the array. We'll see if the rebuild fixes the problem.

More disk drives was a line item in the fall fundraising drive, wasn't it?

We had a drive in the array that holds the workunits that was generating errors. I've kicked it out of the array. We'll see if the rebuild fixes the problem.

. . Thanks f or the update Eric.

Stephen

:)

The WU File deleters have been having issues for a few days now, however things appear to be getting worse with the backlog reaching new highs.
Hopefully we won't get to the point of running out of disk space till well after everyone's back at work at Berkeley.

---

Grant
Darwin NT

We had a drive in the array that holds the workunits that was generating errors. I've kicked it out of the array. We'll see if the rebuild fixes the problem.

. . Thanks f or the update Eric.

Stephen

:)

. . For what it's worth, since the issue with the derelict Raid drive. and hopefully no jinxes involved here, I have not had to play kick the servers at all. Work requests are being met and my caches are full. It would seem, on the surface, that the malfunctioning drive may have been at the heart of the issue for some time.

Stephen

:)

We had a drive in the array that holds the workunits that was generating errors. I've kicked it out of the array. We'll see if the rebuild fixes the problem.

. . Thanks f or the update Eric.

Stephen

:)

. . For what it's worth, since the issue with the derelict Raid drive. and hopefully no jinxes involved here, I have not had to play kick the servers at all. Work requests are being met and my caches are full. It would seem, on the surface, that the malfunctioning drive may have been at the heart of the issue for some time.

Stephen

:)

I too was wondering the same or more likely the re-apportioning of the memory Eric mentioned. I haven't had to kick the servers either. Smooth sailing for once and I really like it.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

. . For what it's worth, since the issue with the derelict Raid drive. and hopefully no jinxes involved here, I have not had to play kick the servers at all. Work requests are being met and my caches are full. It would seem, on the surface, that the malfunctioning drive may have been at the heart of the issue for some time.
Stephen
:)

I too was wondering the same or more likely the re-apportioning of the memory Eric mentioned. I haven't had to kick the servers either. Smooth sailing for once and I really like it.

. . Hi Keith,

. . Nice to know the effect is not just with my rigs. I wonder if things have improved for grant too, he seemed to be suffering from the issue a lot.

Stephen

??

. . Nice to know the effect is not just with my rigs. I wonder if things have improved for grant too, he seemed to be suffering from the issue a lot.

About the same.
Ok for days or weeks at time then the cache runs down for a bit & Tbars triple update gets it going again.
When there is no AP work, or mostly just GBT or Arecibo is when the issue generally occurs. The fact that there has been a steady flow of AP work for a while now is most likely why we're not having issues getting work.

---

Grant
Darwin NT

Back up over 90 minutes, still can't get any tasks for any of my three.
May be time to head to Einstein?

---

Once I noticed that the servers were back up, I went over to my crunchers and forced a request-for-work. I started getting work right away (first 1, then 100+ a couple of times), Check to see if your machines are on a delay because they requested work when none was available.

---

Once I noticed that the servers were back up, I went over to my crunchers and forced a request-for-work. I started getting work right away (first 1, then 100+ a couple of times), Check to see if your machines are on a delay because they requested work when none was available.

Thanks, the first thing I do when it's back up is force an update on all boxes via BOINCTasks.
Every 305 seconds getting "No work available"
===
Disregard, flowing now ...

---

Back up over 90 minutes, still can't get any tasks for any of my three.
May be time to head to Einstein?

. . I was surprised that I got some new work on the first try after the outage, but since then nada. Looking at the server page the RTS tasks are below 90K but the creation rate is only 8/sec. Oh well!

. . Have fun at Einstein :)

[edit] .. OK. so while I was reading and typing, a work request got "unable to communicate with project, server may be down" message followed on the next attempt by a large download. Maybe you should try again now :)

Stephen

:)

AP Validators don't appear to be working too well- Number of AP WUs awaiting Validation and Assimilation are heading for orbit.

---

Grant
Darwin NT

AP Awaiting Validation and WU Awaiting Assimilation continue to climb.

---

Grant
Darwin NT

I guess no one from the project has noticed. Hopeful that it gets fixed with maintenance tomorrow.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I guess no one from the project has noticed. Hopeful that it gets fixed with maintenance tomorrow.

Yep.
Hopefully the restart after the system shut down will kick things along.

---

Grant
Darwin NT