The status page numbers have some lag. I'm not sure if it is a sign of a problem or not.

edit to add... it was a false alarm. All is well.

So what is going on now? Just looked and all hosts are out of gpu work. Reporting and getting nothing in return.

---

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

A proud member of the OFA (Old Farts Association)

Mine aren’t out of work, but it does seem to be falling from the max queue that they usually hold.

---

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

It looks like hit and miss over a dozen request cycles whether you get any work or not. My big iron has been empty for half an hour and just got a slug of 114 tasks 5 minutes ago. But that is almost half completed by now. My other crunchers are getting nothing and are now working on the backup projects.

---

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

A proud member of the OFA (Old Farts Association)

I have been loading up on tasks here, and it has been hit-and-miss for the last 10-15m.
But certainly not long enough to run out of work.

The results out in the field looks about normal at 4.4 million. The results ready to send is a bit low, but holding steady in the 470k range. The results received in the last hour seems high at 140K.

Are we getting noise bombs again?? is this just the noise bombs filtering through the slower machines?

edit to add : we are now getting 30oc18aa, so that might help.

That could be the effect of the noise bombs filtering though the slow hosts. I think it more likely that the "shorty" BLC01 tasks are the cause. Mine are processing in 30-60 seconds. So the gpus make quick work of them. The Arecibo file will slow things down a bit.

---

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

A proud member of the OFA (Old Farts Association)

That could be the effect of the noise bombs filtering though the slow hosts. I think it more likely that the "shorty" BLC01 tasks are the cause. Mine are processing in 30-60 seconds. So the gpus make quick work of them. The Arecibo file will slow things down a bit.

The BLC01 tasks run quick on CPUs as well as GPUs, and on GPUs they run not much over half the runtime of the recent BLC22/23 run. So to a first approximation, we would expect roughly double the return rate for a while. Caches (apart from those bumping the hard limit) will also grow as as initial runtime estimates adjust to the new normal, increasing the drawdown rate from RTS.

That could be the effect of the noise bombs filtering though the slow hosts. I think it more likely that the "shorty" BLC01 tasks are the cause. Mine are processing in 30-60 seconds. So the gpus make quick work of them. The Arecibo file will slow things down a bit.

. . They aren't 'shorties' they are normal but the 'new' format that started with a Blc04 series in October last year and runs in about the same time as Arecibo 'normal' tasks, and had been the norm until we got this recent run of '2x' series tasks that were old school and slow. The new format takes 105 secs on my top machine compared to 180 for the Blc22/23 series of late. And in usual form Credit Screw ignores the greater efficiency of the tasks (my APR jumped over 35%) and halved the awarded credit because they take only slightly more than half the time. But that is typical for Credit Screw. There was allegedly a 'committee' formed to ponder an upgrade/replacement for Credit New but that seems to have evaporated, I haven't heard anything for months, not since the initial 'rumour' was started. But then the same is true of Parkes, PMs are unanswered and when I asked to have the Parkes thread in News to be re-activated (it had been closed because of no activity) it was instead removed. There are less leaks in SETI than the government or the CIA.

. . As for the recent problem getting new work. I reviewed my logs for overnight and it only seems to have lasted from 2:20pm to 2:50 pm UTC. So maybe it was that glitch that is often mentioned but simply at a different time.

Stephen

<shrug>

... Welcome back to Earth Assimilator backlog - Pull up a chair and stay awhile.

... Welcome back to Earth Assimilator backlog - Pull up a chair and stay awhile.

Yep, good the see the Validation & Assimilation backlogs have finally cleared. Now all we need is for the Results & WU Purge backlogs to clear...

---

Grant
Darwin NT

... Welcome back to Earth Assimilator backlog - Pull up a chair and stay awhile.

Yep, good the see the Validation & Assimilation backlogs have finally cleared. Now all we need is for the Results & WU Purge backlogs to clear...

I am just curious to know why we need the work units purged results to clear? These will probably take 24 hours. Apart from people having lots of results in their accounts I cannot see any other major issue, unless we run out of disk space.

---

I am just curious to know why we need the work units purged results to clear? These will probably take 24 hours. Apart from people having lots of results in their accounts I cannot see any other major issue, unless we run out of disk space.

That's part of it- running out of disk space, not to mention the load on the database, and really, really, really long wait times when looking at the results on your computers- particularly for those with high output systems.
Think of it as being like the Recycle Bin on the windows desktop- once you delete the file, it's still there till you empty it. Same here- the files need to be purged after being deleted to finally free up that space, and reduce the size of the database.
And most of the issues we have with the servers relate to the size of the database.

---

Grant
Darwin NT

and really, really, really long wait times when looking at the results on your computers- particularly for those with high output systems.

That is my primary annoyance. The website is unusable when the Results and WU purge loads get large, especially after an outage and for several days later, typically running right into the next Tuesday outage. If the web page for one of my hosts doesn't display and times out, I just give up and look at it the next day. Makes it hard to keep on top of my hosts to make sure they are returning valid work and haven't had an upset I need to catch and rectify.

---

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

A proud member of the OFA (Old Farts Association)

I am just curious to know why we need the work units purged results to clear? These will probably take 24 hours. Apart from people having lots of results in their accounts I cannot see any other major issue, unless we run out of disk space.

It's more that records in the database tables need to clear - and in particular, the indexes to the records need to be shrunk until they fit in RAM (not on disk). Otherwise, they will be unutterably slow.

I am just curious to know why we need the work units purged results to clear? These will probably take 24 hours. Apart from people having lots of results in their accounts I cannot see any other major issue, unless we run out of disk space.

It's more that records in the database tables need to clear - and in particular, the indexes to the records need to be shrunk until they fit in RAM (not on disk). Otherwise, they will be unutterably slow.

Does purging affect the re-sending of timed out/ inconclusive WUs?
Over the last few days, I've noted very few re-sends in my caches. Often there will be groups of 2-5 with the odd one here & there but lately there's been only the odd one or two here & there. At present I've got 4 in one cache, and 0 in the other; normally i'd expect 1-2 dozen in each cache..

---

Grant
Darwin NT

It's more that records in the database tables need to clear - and in particular, the indexes to the records need to be shrunk until they fit in RAM (not on disk). Otherwise, they will be unutterably slow.

Does purging affect the re-sending of timed out/ inconclusive WUs?
Over the last few days, I've noted very few re-sends in my caches. Often there will be groups of 2-5 with the odd one here & there but lately there's been only the odd one or two here & there. At present I've got 4 in one cache, and 0 in the other; normally i'd expect 1-2 dozen in each cache..

. . I can only comment on my slow machines, the tasks on the faster units just come and go pretty quickly, I don't take much notice. But what I am seeing are small groups of resends from the end of August and early September, after the WOW event I am guessing. Not dozens but regular small groups of 2 or 3.

Stephen

. .

Purging is the tasks list we get to see after they have been validated assimilated and files removed.
I believe it is set to 7 days for MB and 2 days for AP.

It would be nice if the limit was 6 days, so that the big surge of tasks after maintenance is removed before the next round comes in.

Purging is the tasks list we get to see after they have been validated assimilated and files removed.
I believe it is set to 7 days for MB and 2 days for AP.

It would be nice if the limit was 6 days, so that the big surge of tasks after maintenance is removed before the next round comes in.

+1
I think that would be a splendid development too. I never can catch up since my previous week's task list runs into the next maintenance. The only time I see my task list diminish is when there is a long project upset.

---

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

A proud member of the OFA (Old Farts Association)

Purging is the tasks list we get to see after they have been validated assimilated and files removed.
I believe it is set to 7 days for MB and 2 days for AP.

It would be nice if the limit was 6 days, so that the big surge of tasks after maintenance is removed before the next round comes in.

How weird. my task list for validated tasks is only 24 hours long... MB or AP