unserialize() refers to reading cached data. It could be a disk problem or it could be that the project was taken down at exactly the wrong moment.

edit: Then again, if the cache was from pre-maintenance it should have expired by now.

Massive graph breaks at Haveland indicating the SSP export has been messed up for quite some while.

---

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

A proud member of the OFA (Old Farts Association)

WooHoo, somebody really crammed the jukebox full:

total channels to do: 11322

---

Yes, that might just barely get us through next Monday. I think we go through 1600 - 1800 channels every 24 hours.

---

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

A proud member of the OFA (Old Farts Association)

More issues from Carolyn. I have had disk index error messages from that server continuously since November. They still haven't fixed it. Database is screwed up. Whether by failing disk or corruption, who knows?

I just got this now, trying to see p. 2, where my two crunchers were 29 and 31 earlier today.

Bah, humbug!

---

Yes, my second fastest cruncher was #24 on the list when it was last visible. Hope they can finally permanently fix this ongoing issue.

---

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

A proud member of the OFA (Old Farts Association)

If you let the RAC drop a bit, you'll be able to see it again on page 3 (&offset=40), once it's dropped to #41 ;-)

Interesting. I didn't look any further than page #2. Really seems to point at corrupted database.

---

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

A proud member of the OFA (Old Farts Association)

Yes, that might just barely get us through next Monday. I think we go through 1600 - 1800 channels every 24 hours.

. . Hi Keith,

. . I was hoping to make it to next Wednesday but I was basing that on 1500 per day. At least we should be safe for the weekend and the guys should be able to relax as well.

Stephen

<fingers crossed>

If you let the RAC drop a bit, you'll be able to see it again on page 3 (&offset=40), once it's dropped to #41 ;-)

. . LOL!

. . Ever the practical one :)

Stephen

:)

Hi Stephen . . . . yes, fingers-crossed. I think my 1600-1800 channel per day is probably pretty good for baseline, mostly BLC task, end of the normal week once we are out of the 'everyone at the feeding trough' post outage Tuesday-early Wednesday demands.

Will have to check my numbers come early Tuesday morning before the outage starts to see if I have to revise my estimate. I think this is the first time on predominantly BLC work that we will have enough tapes loaded post-outage to not need any remedial work added before the next outage.

---

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

A proud member of the OFA (Old Farts Association)

Yes, that might just barely get us through next Monday. I think we go through 1600 - 1800 channels every 24 hours.

Do we have any idea how many tasks come from 128 channels? I'm assuming that this is one tape/disk

---

From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

I don't know the exact number of tasks per file other than guessing that 52.45GB ÷ 703KB per task = 74608 tasks. But how much overhead is involved with each task generation is unknown.

---

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

A proud member of the OFA (Old Farts Association)

From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

I don't know the exact number of tasks per file other than guessing that 52.45GB ÷ 703KB per task = 74608 tasks. But how much overhead is involved with each task generation is unknown.

Don't forget the overlap and the file info adds a few bytes per wu...

---

Do you Good Search for Seti@Home? http://www.goodsearch.com/?charityid=888957
Or Good Shop? http://www.goodshop.com/?charityid=888957

From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

That's a leftover from the old Arecibo only days. ;-)

It's also about time that the MB V7 part was put to sleep too.

Cheers.

It's also about time that the MB V7 part was put to sleep too.

Cheers.

I asked nicely for the website engineering staff years ago to deprecate the SSP page for the MB V7 data. It does nothing but take up space and make clutter. Nothing ever came of that.

---

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

A proud member of the OFA (Old Farts Association)

OK, I think I have this straight now :D

You want:
- 10 day cache, CPU + GPU, AP Only
- 1 day cache, GPU Only, AP + MB

The problem is with how (and when) the server tells the client about the change. When you tell the server you want to change to GPU only, the client does know that - so the next request will be asking for CPU + GPU tasks. I have run into this before, and it's a pain!

The way around it is to make the server change DURING the 5 minute timer, and then do a manual update BEFORE the timer expires. Since it is less than 5 minutes between server contacts it will NOT send you work for this request, but it will update the client settings from the server.
You could do - manual update, change server setting, manual update. That should work for you.

I'm not sure about honoring the cache size though, I have never tried that part.
But you would have to make sure the CLIENT is set to use WEB Preferences.

some news after 12 days without changing location, Cpu WU tasks down to 7 in cache ...

requesting only GPU wu from server

---

Good to hear it's working now.

Another request for someone to hang (or equivalent...) one or more "tapes" for Beta... perhaps Beta could use some Greenbank data?

---

.

Hello, from Albany, CA!...

Hi Stephen . . . . yes, fingers-crossed. I think my 1600-1800 channel per day is probably pretty good for baseline, mostly BLC task, end of the normal week once we are out of the 'everyone at the feeding trough' post outage Tuesday-early Wednesday demands.

Will have to check my numbers come early Tuesday morning before the outage starts to see if I have to revise my estimate. I think this is the first time on predominantly BLC work that we will have enough tapes loaded post-outage to not need any remedial work added before the next outage.

. . Not a bad milestone to achieve.

Stephen

:)