Think about a computer with a 100k RAC suddenly starting to throw invalids, set the trigger at 1% - it needs to throw 1000 before it is trapped.

Now you're the one muddling the units!

A RAC of 100K - measured in credits, that's what the 'C' stands for - is probably a count of ~1K. So a 1% trigger is only ~10 tasks.

Or so a pedant might say. The underlying principle of keeping the maths as simple as possible for a server which has to process 150,000 tasks per hour is still valid.

Why then did YOU mention RAC? - It is YOU who proposed a system based on the RAC of a host.

Where did I mention that? The the first time in this discussion 'RAC' appears in any of my posts is when I was replying to YOU bringing that up.

If the host produced only invalids, then its invalid score would rise very fast!

Yes, its invalid COUNT would rise, use that as the control, not some derived variable - far simpler, and far more able to catch the event early.

And the count would stay high forever after the host stops producing invalids. That's why a decay mechanism is needed.

Think about a computer with a 100k RAC suddenly starting to throw invalids, set the trigger at 1% - it needs to throw 1000 before it is trapped - now consider a computer with a RAC of 1M (and they do exist) - that figure now becomes 10k - both of which are far more than "just a few"

RAC would have absolutely nothing to do with it. Higher RAC host would trigger it faster because it chews through the tasks faster but any host would trigger it after the exact same number of tasks.

If we assume the decay multiplier 0.999. the limit 1%, the host producing only invalids and the value starting form zero, then the value would evolve like this:
0.001, 0.001999, 0.002997. 0.003994, 0.004990, 0.005985, 0.006979, 0.007972, 0.008964, 0.009955, 0.010945. So 11th consecutive invalid result would trigger the trap.

---

But a host will probably be producing good results on the CPU and if fitted other GPU's.

Sorry, but noise is a thing only coming our way, for being a radio telescope being pointed at the sky, for detecting radio signals which also could be intelligent in nature.

Therefore the blc35_2bit_guppi tasks among these, for only a bit of noise, except also the possible transmission that also could be meant to be.

Again just sorry for only the discussion of that of RAC for also credit it should be here, for also the scheduled maintenance happening at times.

But a host will probably be producing good results on the CPU and if fitted other GPU's.

Even those buggy GPUs/drivers only fail on some tasks. Not all of them.

---

Thanks Richard - I had a look at that post and thought "there's something wrong there, but what...."

---

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

Thanks Richard - I had a look at that post and thought "there's something wrong there, but what...."

I was trained - a long, long, time ago - at the Cavendish lab, Cambridge university. Two pieces of teaching stuck:

* No number has a meaning unless the units are stated.
* Do every calculation twice. Once, using the most accurate mechanical/electronic device available - and then again, on the back of an envelope or a chalk board. The second only has to be done using order-of-magnitude approximations, but it proves that the decimal point hasn't slipped in the first one.

Sunday, and the replica if falling behind again.
As of now, 3,176 seconds (53 minutes) behind, and that number is getting bigger fast.
(no wonder it looks as if I had not returned anything for a while, when looking at my task list)

This has happened on many weekends. At approximately the same time the total outages we experienced on many consecutive Sundays in last September and October. I wonder if the causes are related.

---

The Replica has had it's break & is now catching up again.

---

Grant
Darwin NT

A few noisy WUs in the current Arecibo group, and more than the usual number of uploads timing out instantly.

---

Grant
Darwin NT

Assimilation queue is still going down at a steady rate. If the same rate continues, the backlog is gone in about 8 days.

---

Did anyone get anything other than noise bombs for ap_29ja16ad? Must have been something going on that day.

Edit: only thing I see on any cosmic calendars is the moon being at its apogee.

Did anyone get anything other than noise bombs for ap_29ja16ad? Must have been something going on that day.

Edit: only thing I see on any cosmic calendars is the moon being at its apogee.

Haven't done any of them yet. Still in progress.

It could be caused by any number of things. The radar could have been on. Terrestrial interference. Any number of transmitting satellites could have passed by in the aperture capture window. etc. etc.

---

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

A proud member of the OFA (Old Farts Association)

It could be caused by any number of things. The radar could have been on. Terrestrial interference. Any number of transmitting satellites could have passed by in the aperture capture window. etc. etc.

Thanks, just unusual to get an sse, sse2, and 4 OpenCL_ati_mac WUs, just to have them all bomb out.

It could be caused by any number of things. The radar could have been on. Terrestrial interference. Any number of transmitting satellites could have passed by in the aperture capture window. etc. etc.

Thanks, just unusual to get an sse, sse2, and 4 OpenCL_ati_mac WUs, just to have them all bomb out.

It's nothing uncommon when the tasks are 100% blanked.

Cheers.

It could be caused by any number of things. The radar could have been on. Terrestrial interference. Any number of transmitting satellites could have passed by in the aperture capture window. etc. etc.

This will become more and more common over time as Elon Musk and his competitors are spamming the low Earth orbit with thousands of internet satellites.

---

Milestone As of 11 Feb 2020, 7:30:05 UTC

"Results returned and awaiting validation" is below 10,000,000.
exact figure 9,990,238.

Milestone As of 11 Feb 2020, 7:30:05 UTC

"Results returned and awaiting validation" is below 10,000,000.
exact figure 9,990,238.

Only another 5.2 million to go (and another 2.41 million to go to clear the Assimilation backlog).

---

Grant
Darwin NT

Only another 5.2 million to go (and another 2.41 million to go to clear the Assimilation backlog).

Those are essentially the same thing. Each workunit in assimilation queue is preventing on average about 2.2 results from transitioning to 'waiting for db purging' state. 5.2/2.41=2.16

---

and we are back....

---