I just noticed some of the numbers on the server status page. Ready to Send is soaring, results in the field is dropping surprisingly fast.

I guess one good thing about this.. when everything comes back online, there will be PLENTY of work for everyone. I'm going to go ahead and predict 8 solid days at 94mbit on the network graph, assuming the new servers will handle that kind of stress for that long, which they certainly should.

---

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

Why deleters are disabled? We can't look results anyway so better to delete all assimilated results/tasks to free disk spacebefore transition, not?

Also, completely disabling download servers not a way to go IMHO. Much better would be just to disable splitters. Then resends would provide some small work traffic that should not harm database server but would help to cleanup everything.

Why deleters are disabled? We can't look results anyway so better to delete all assimilated results/tasks to free disk spacebefore transition, not?

Also db_purge.x86_64 should be enabled to remove all validated workunits/results from the BOINC database before it will be copied to the new server.

---

Agreed that should disable the feeder.x86_64, and enable the deleters and purge. Makes no sense to assign work to clients if they can't download anything.

Agreed that should disable the feeder.x86_64, and enable the deleters and purge. Makes no sense to assign work to clients if they can't download anything.

I not so sure, but the feeder might need to be running for the scheduler to work, and then there's this changeset that appeared the other day: Changeset 22601

- scheduler/feeder: add a project config option <dont_send_jobs>.


If set, the feeder doesn't read jobs into shmem,
and the scheduler doesn't send jobs.
Intended for use when a project wants to process
a backlog of completed jobs and not issue more.

While there's no proof that this changeset has been applied here, it's the most obvious project that would require it,

Claggy

Work is not assigned to anyone... otherwise the results ready to send would be about 0 by now with the splitters turned off.

---

Work is not assigned to anyone... otherwise the results ready to send would be about 0 by now with the splitters turned off.

task to resend assigned even now. Lost task resend feature.
But it's impossible to download them.

I'm getting ever-closer to having a cold room. Only about a day and a half of APs left to crunch.

---

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

I'm getting ever-closer to having a cold room. Only about a day and a half of APs left to crunch.

LOL, So thats why I had to jack the thermostat up a notch, I turned off the P4 and the i7. I did blow out all the dust bunnies. The i7 didnt seem to have much dust in it, First time I have blown it out in 18 months.

---

[/quote]

Old James

Not only are the deleters and purging off
so are the "sah_assimilator's"

---

Well, two of them are on and they seem to be quick enough, yesterday we had 1.8M workunits waiting for assimilation, now it's down to 1.1M, so that's OK IMO.

---

Well, two of them are on and they seem to be quick enough, yesterday we had 1.8M workunits waiting for assimilation, now it's down to 1.1M, so that's OK IMO.

Ya they came back on shortly after my post that they had been disabled

Gee Isn't that funny

---

10 hours left on one AP and then I have a cold room for the next 3-4 weeks. The other cruncher finished its last AP early yesterday.

---

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

10 hours left on one AP and then I have a cold room for the next 3-4 weeks. The other cruncher finished its last AP early yesterday.

Run something else, you'll still be helping the scientific community. Run some MW@home units or something.

---

Last SETI MB WU's are Reported last Friday, only some ~100, now expired on 27october, are trying to UPLoad to SETI Bêta, which is still down.

Been crunching Einstein and GPUgrid on this host.

The 2 other QUAD's are doing a mix of Docking, CPDN, Leiden, MW, Collatz and DNETC (from time to time, it uses 2 GPU for 1 task, switched off, CPU tasks.)

SERVER Page isn't clear either, D'Load servers off, scheduling servers are on,
UPLoad servers and validators, also ON.
Probably to collect the last WU's, before everything, except 1 DataBase, is switched OFF, I think....

---

Last SETI MB WU's are Reported last Friday, only some ~100, now expired on 27october, are trying to UPLoad to SETI Bêta, which is still down.

Been crunching Einstein and GPUgrid on this host.

The 2 other QUAD's are doing a mix of Docking, CPDN, Leiden, MW, Collatz and DNETC (from time to time, it uses 2 GPU for 1 task, switched off, CPU tasks.)

SERVER Page isn't clear either, D'Load servers off, scheduling servers are on,
UPLoad servers and validators, also ON.
Probably to collect the last WU's, before everything, except 1 DataBase, is switched OFF, I think....

Slow down
WTF
are you saying

---

10 hours left on one AP and then I have a cold room for the next 3-4 weeks. The other cruncher finished its last AP early yesterday.

Run something else, you'll still be helping the scientific community. Run some MW@home units or something.

I wasn't saying it like everyone else does where they get mad and think they deserve to always have work. This is the only project that interests me. I support the current server situation. I'm fine with idle time, because I'm in it for the science, not the points.

---

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