Stuffed to zero in the food bucket...

Well, I've got about 400 in the cache so I'll just sit tight until they run out, then I'll turn something off and same a bit of CO2...

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

My GTX 470 (fast, but far from the fastest) has been working through a block of shorties, and is at DCF 0.0540 - that's even after the five-fold raise in the cap last night. I'm beginning to think we may need two more interim steps, not just one.

Quick question just received 30 short WU,s after outage all resend time outs for 27/09/2011

Should I leave these for an hour or two to let the replica data base catch up or will they be okay to crunch. (13,358 seconds)

Deadline for these 11/10/2011

Michael

The replica database is just that, a replica. It's status has no bearing on the activity of the project. It is used to supply data to the Stats sites and the web pages in order to take some load off the main db. So, if you got 'em, crunch 'em.

T.A.

Looks like something hit a snag...
Crickets have stopped singing.
The AP splitters appear to have stopped producing, even though they show as running as of the last server status update (4 minutes ago).

The GPUs on my top rig have gone cold.

---

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

Jeff just posted in the News thread...
The workunit storage server crashed, and that's why no work is being generated at the moment.

The kitties will crunch what they have in the kibble bowls for now.

Wish him luck getting it sorted and back online.

Meeeouch.

---

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

Extremely well behaved system now. I haven't experienced this smooth behaviour when it comes to uploading, reporting, requesting and getting new WU's, in many many months, if not years.

My computers immediately get what they ask for, and my caches are filled to the top with 10 days worth of work.

sarcasm mode on ? because everybody else gets the "server down for maintenance" response...

---

I got a bunch of APs this morning before the server crashed. Four didn't make it through the pipe before the server went down though. Going to suspend comms until that problem gets fixed.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I got a bunch of APs this morning before the server crashed. Four didn't make it through the pipe before the server went down though. Going to suspend comms until that problem gets fixed.

I have 41 MB's stuck in download as well. Do these downloads eventually just time out, or will they keep trying until either the servers come back up? I'm not going to abort them, as I can't report to the scheduler anyway, I was just wondering.

---

They will will download when the site comes back up

---

I have also still a few backlogged DLs in the transfers overview in my BOINC.
Nothing to worry about.
If the server will be again reachable, they will come down.

;-)


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

I got a bunch of APs this morning before the server crashed. Four didn't make it through the pipe before the server went down though. Going to suspend comms until that problem gets fixed.

I've also got a few AP stuck in download,

Claggy

My luck finally ran out, hehe. A few AP's stuck in download, and no other tasks. ah well, I know they'll be more work soon ;)

---

I have several AP units and a few others stuck in download. I set for NNT, and will crunch these when they get here, but I unleashed Einstein to build a full cache. The only problem is that with Einstein, hyperthreading makes a big difference, but with SETI, it gives me ragged GPU usage. I don't have than many Seti GPU units in download, so I may just go ahead and make the switch. It may mean backing off the clock speed for a bit, but I intend to do a lot of science until Seti can sustain my rig for more than a few minutes at a time.

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

I have also still a few backlogged DLs in the transfers overview in my BOINC.
Nothing to worry about.
If the server will be again reachable, they will come down.

;-)

O.K. - and now the DL work..

;-)


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

Jeff just posted this in the news section..........

The box is back up and the RAID is resync'ing. I have the project up to clear some of the queues but the feeder is idling until the resync is complete.

---

Cricket is maxed again. I let comms happen again and all four of my stuck APs began instantly.. at BLAZING speed.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Wouldn't you know. Right after I reconfigured for Einstein. I'll still wait a few days and see how it goes. If Seti holds strong, I'll switch back, but it would be helpful if I could build a full cache, which may take a couple of weeks acording to what Richard has indicated. I'm happy either way, as the more science I do, the happier I am!

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

I just connected to Rosetta so I can keep the CPU warm as I was out of CPU work. The GPU still has a few more units until it goes back to Einstein.

---

Periodically I feel compelled to make a suggestion. I have interest in only Einstein and Seti, with Seti as Numero Uno. Someone suggested to me that I set Einstein to have a resource share of 0 and to set seti at 100. Now, if seti is down long enough to purge my cache, then einstein fills the bill. But not until then. I have to be empty for seti before Einstein is asked for work. Seems to work.

Pretty soon, I'll be able to get some more work from einstein, it appears.

(BTW, any resource setting other than zero seems to let boinc work its wicked ways and produces balances that I don't want. The resource share has to be zero to be a true backstop.)

The resource share has to be zero to be a true backstop.)

Even then it may do something most folks might not want: load up your cache with so much work that once SETI resumes you'll face the choice between either trashing a large amount of Einstein work or forgoing a good bit of potential SETI output.

So I think folks trying this scheme who have queue lengths longer than a very few hours may be happier if they radically cut their requested queue time when they spot SETI work dropping below their danger level. Einstein has pretty good up time, so settings longer than just a couple of hours are seldom needed just to keep in work.

I agree that project requested balances such as 99 to 1 generate weird behaviors most users would not like, at least on versions I've tried on my hosts.

---