Today the usual tuesday outage, which went fine. Of course, we preceeded this by having the project off all night to clean out various backlogged queues. It's at the point that if one part of the backend fails for long enough, the result table gets bloated and wreaks havoc on the whole system. But we were fully drained by this morning, and the database backup/compression went smoothly. We're catching up now.

Somebody asked what "db_purge.x86_64" is. In order to speed up the process of reducing the db_purge queue we wanted to run that process on the system where the actual archives are being stored to disk. This was thumper, a 64 bit machine, so that meant compiling a 64 bit version of the purger. The suffix "x86_64" denotes that.

During the outage Jeff and I reconfigured the workunit volume on our Snap Appliance to be a grouped set of mirrors instead of a big raid 5. The idea is that this will vastly help disk I/O - we'll start putting workunits back on this system in due time and monitor progress. We shall see how well this helps.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Matt,

So, did you play any gigs in Kiwiland? Or just pure vacation?

Matt, Nice Work @ Berkeley - and to You & Jeff - Keep it up . . .

Good to see you are back from vacation nice and refreshed hopefully. It's a very nice part of the world and the prefect time to escape fall in Northern Hemisphere. Keep up the good work and as usual, thanks for keeping us informed.

---

Thanks for the update Matt, and hope you had some nice time on your vacations.

One quick question, are you running any software RAID arrays on the project machines ?

not a complaint, but...

when I went to get more WU's, some of them came over as "0 bytes" on the "transfers" tab of the client... I've never noticed that before from active WU's!

---

.

Hello, from Albany, CA!...

not a complaint, but...

when I went to get more WU's, some of them came over as "0 bytes" on the "transfers" tab of the client... I've never noticed that before from active WU's!

There's a whole slew of these bad WUs.

I just aborted all them that were on two of my systems. (As soon as my wife gets off the other I'll do it also.)

To abort them you have to find the zero length WU files and then use the file name to find them on the Tasks tab.

Unfortunately, this results in a new file being sent out to someone else.

---

not a complaint, but...

when I went to get more WU's, some of them came over as "0 bytes" on the "transfers" tab of the client... I've never noticed that before from active WU's!

There's a whole slew of these bad WUs.

I just aborted all them that were on two of my systems. (As soon as my wife gets off the other I'll do it also.)

To abort them you have to find the zero length WU files and then use the file name to find them on the Tasks tab.

Unfortunately, this results in a new file being sent out to someone else.

It would be better if you let your machine try to crunch them. It would help the admins to troubleshoot the splitters if they see a bunch of errors stating "Compute error" and "SETI@home error -6 Bad workunit header" instead of "Aborted by user". If enough of the bad workunit header results kill the work unit instead of aborts, it would be easier for the admins do a database search for which work units need to be resplit.

not a complaint, but...

when I went to get more WU's, some of them came over as "0 bytes" on the "transfers" tab of the client... I've never noticed that before from active WU's!

There's a whole slew of these bad WUs.

I just aborted all them that were on two of my systems. (As soon as my wife gets off the other I'll do it also.)

To abort them you have to find the zero length WU files and then use the file name to find them on the Tasks tab.

Unfortunately, this results in a new file being sent out to someone else.

It would be better if you let your machine try to crunch them. It would help the admins to troubleshoot the splitters if they see a bunch of errors stating "Compute error" and "SETI@home error -6 Bad workunit header" instead of "Aborted by user". If enough of the bad workunit header results kill the work unit instead of aborts, it would be easier for the admins do a database search for which work units need to be resplit.

I'll make it easier for them: 17mr07ab and 18mr07aa.

---

Noticed today WU are not being taken according to the due dates.
Is that a seti or boinc problem ?

---

Noticed today WU are not being taken according to the due dates.
Is that a seti or boinc problem ?

BOINC takes runs the tasks from any particular project in First In First Out order unless there is a chance that this will miss a deadline. In that case it starts in Earliest Deadline First order. This is by design.

---

BOINC WIKI

I did see a few zero-crunch-length "Client Errors" workunits on one of my machines.

---