Spent the last couple of hours manually updating to get acks for the uploads that have gone through. The two slowest hosts reduced their uploads enough to clear the trip point and actually download new work. The other machines still have around 3000 tasks still in upload so no downloads for them yet. Today is definitely not a "set and forget" outage.

---

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

A proud member of the OFA (Old Farts Association)

Spent the last couple of hours manually updating to get acks for the uploads that have gone through. The two slowest hosts reduced their uploads enough to clear the trip point and actually download new work. The other machines still have around 3000 tasks still in upload so no downloads for them yet. Today is definitely not a "set and forget" outage.

. . and so endeth the lesson ... amen :(

Stephen

. . My slowest machine is managing to get work only because it only uploads about 1 task / 5 mins. The other three are all log jammed ... :(

Stephen

:(

Both my caches have been full for the last 90mins or so.

Cheers.

Both my caches have been full for the last 90mins or so.

Cheers.

. . Here uploads continue to fail but with much jiggery pokery I have managed get new work in the caches on my two Linux machines. Now if I can just manage that trick on the two Windows machines :(

Stephen

? ?

Making progress. Now only have the Threadripper host that still has a 1000 tasks in upload that isn't asking for work. All the other hosts have finally cleared the hurdle and are asking for new work? But they still only ask for work if I manually update since the stalled uploads prevent the automatic scheduler connection. But at least the stalled uploads are below the trip point for not asking for work no matter what. I wonder what the code tells the client is the trip point that prevents downloading of work if you have too many uploads in progress. Is it a hard number or a percentage or something. I guess I will have to walk the code to find out unless someone wants to chime in with the actual mechanism.

---

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

A proud member of the OFA (Old Farts Association)

2x number of CPU cores.

2x number of CPU cores.

Thanks very much Richard. I was always curious what the trip point was. Now I know.

---

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

A proud member of the OFA (Old Farts Association)

2x number of CPU cores.

so if you have more uploads than 2x CPU cores, it wont ask for work?

my systems wont ask for work automatically on the 5:03 cycle even if there are only 2-3 uploads in progress and thats on a system with like 32 cores. it will get work if i manually click the update button however.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

2x number of CPU cores.

so if you have more uploads than 2x CPU cores, it wont ask for work?

my systems wont ask for work automatically on the 5:03 cycle even if there are only 2-3 uploads in progress and thats on a system with like 32 cores. it will get work if i manually click the update button however.

I think there is another part to the algorithm. If you have any stalled upload, it ignores the 5:03 scheduler connection. The 2X number of cpu cores is just what trips the "unable to request work because too many uploads" and you report your tasks and get the 0:00 cpu seconds of work requested and 0:00 seconds of gpu work requested.

I still have to manually update hosts that can get work because the uploads are still slow.

---

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

A proud member of the OFA (Old Farts Association)

Are you automating it? Or manually clicking the button every 5 mins?

watch -n 310 ./boinccmd --project http://setiathome.berkeley.edu update

That will click the button for you every 310 seconds. Adjust as necessary. Make sure you run it from the BOINC directory

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Uploads seem to need ye olde plunger, while downloads don't here.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Are you automating it? Or manually clicking the button every 5 mins?

watch -n 310 ./boinccmd --project http://setiathome.berkeley.edu update

That will click the button for you every 310 seconds. Adjust as necessary. Make sure you run it from the BOINC directory

Ok so what file does that go in?

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

type that at the command prompt.

Are you automating it? Or manually clicking the button every 5 mins?

watch -n 310 ./boinccmd --project http://setiathome.berkeley.edu update

That will click the button for you every 310 seconds. Adjust as necessary. Make sure you run it from the BOINC directory

No I have just been manually updating via BoincTasks on the daily driver since I've been reading through the day's happenings on it anyway while I was at the movies.

Moot point now as the downloads finally cleared on the TR and it is starting to ask for work finally. If the upload problems had persisted, I would have put the watch command in play in a Terminal on the last recalcitrant child before heading off to bed.

---

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

A proud member of the OFA (Old Farts Association)

I was wondering why you were still up...lol

---

Yep very moot.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

I was wondering why you were still up...lol

I'm about ready to call it quits, eyelids getting heavy. Pillow is beckoning.

---

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

A proud member of the OFA (Old Farts Association)

Uploads are still rather iffy.
Just found a bit over a half dozen uploads on one of my systems counting down their backoffs.

---

Grant
Darwin NT

WU awaiting deletion is on the rise, splitter output & Ready-to-send buffer are on the decline.

---

Grant
Darwin NT

2x number of CPU cores.

so if you have more uploads than 2x CPU cores, it wont ask for work?
my systems wont ask for work automatically on the 5:03 cycle even if there are only 2-3 uploads in progress and thats on a system with like 32 cores. it will get work if i manually click the update button however.

. . Yeah I think that is the mechanism, if you have more than 2xCPU cores uploads 'in progress' (read stalled) you want get new work even when you give a manual kick. Less than that and you will get new work but only if you manually trigger the request.

Stephen

:(