And with the Ready-to-send buffer empty, and splitter output at 18/s, it's going to be that way for a while.

Edit- looks like the splitters have woken up. Now cranking out 80/s. As long as they can keep at 55 or better, then things will improve, eventually.

Well something did wake up...suddenly my cache filled up, and I'm back to the steady hum of my GPU fans ;-)

---

Humans may rule the world...but bacteria run it...

And one of the splitters has started on a BLC01 file, so hopefully the number of noise bombs will start to decline as the BLC22 & BLC23 files are finally finished off, and the ther servers can clear the Validation/Assimilation backlog (now at 7.2/1.4 million).

---

Grant
Darwin NT

And one of the splitters has started on a BLC01 file, so hopefully the number of noise bombs will start to decline as the BLC22 & BLC23 files are finally finished off, and the ther servers can clear the Validation/Assimilation backlog (now at 7.2/1.4 million).

Just done a couple of them, they are fast, 55 seconds each compared with 90 seconds for normal BLC22 & BLC23 WU's.

---

Kevin

And one of the splitters has started on a BLC01 file, so hopefully the number of noise bombs will start to decline as the BLC22 & BLC23 files are finally finished off, and the ther servers can clear the Validation/Assimilation backlog (now at 7.2/1.4 million).

Just done a couple of them, they are fast, 55 seconds each compared with 90 seconds for normal BLC22 & BLC23 WU's.

. . They are the "new" GBT format which first appeared in a Blc04 data series 12 months ago and became the norm by about Christmas last year or January this year. The Blc22/23 series we have been wading through, noise bombs and all, are the "old" format from before that. At least, they conform to the run times that identifies each of what I call format (for want of a better term).

. . I like the new format much better :)

Stephen

:)

I don't want to tempt fate, but I have to say i'm impressed with the servers at the moment. The recovery from the weekly outage wasn't all that great, but now they have recovered they're holding up well.
There's been a sustained return rate of 130k, and the splitters have still been able to meet the demand, and build up a Ready-to-send buffer as well. On top of that effort, they've also been able to put a dent in the Validation & Assimilation backlogs.

---

Grant
Darwin NT

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.