Total pendings are 556, so those two batches are ~8% of the total. If every host has similar, then almost a million workunits are stuck until there deadlines hopefully trigger another validation sequence. Put another way that is 2 million of the tasks in the "Results returned and awaiting validation" entry on the Server status page.

The server problems just before christmas produced lot of those missed validations.

(what's wrong with my spelling of christmas? My browser highlights it as misspelled)

---

Looks like the noise bombing blc35 files are not being split any more. Either they got completed or they have been removed. I'm micromanaging my client to make it process the remaining noise bombs first.

---

(what's wrong with my spelling of christmas? My browser highlights it as misspelled)

Christmas

Total pendings are 556, so those two batches are ~8% of the total. If every host has similar, then almost a million workunits are stuck until there deadlines hopefully trigger another validation sequence. Put another way that is 2 million of the tasks in the "Results returned and awaiting validation" entry on the Server status page.

The server problems just before christmas produced lot of those missed validations.

(what's wrong with my spelling of christmas? My browser highlights it as misspelled)

I think that problem is caused when one task is completed just before a Maintenance, and the other task completed just after the Maintenance. The validator can't handle the outrage.
Try a Capital C.

Christmas

Thanks. Christmas happens every year so my native language doesn't consider it a proper noun identifying a specific unique thing.

---

Then re-release some of the BLC35s in small batches ...

If we're going to stress test it, we might might as well really stress test it.

I'd prefer to stress-test one problem at a time. We've got...

1) The concession to pester-power with the raised in-progress limits
2) The overdue server software update that was pulled because of Anonymous Platform
3) The faulty cards and drivers requiring extra verification
4) The noisy data from both Green Bank and Arecibo

Yep, that's why it was at the end of my list.

---

Grant
Darwin NT

Total pendings are 556, so those two batches are ~8% of the total. If every host has similar, then almost a million workunits are stuck until there deadlines hopefully trigger another validation sequence. Put another way that is 2 million of the tasks in the "Results returned and awaiting validation" entry on the Server status page.

Add to that the fact that the Validators just aren't keeping up, hence their increasing backlog (although that has dropped slightly over the last few hours (but only by by less than 2%. ie bugger all).
Although my Linux System spends much of it's day without any GPU work, and occasionally runs out of CPU work as well, it's RAC is actually increasing from it's post outage low point- due to the huge backlog of work waiting to be Validated slowly being done.

---

Grant
Darwin NT

My RAC is now actually higher than it has ever been before the Christmas outage when everything was working normally. CreditScrew has given us quite variable credit per flop and apparently this variation is now peaking up. About a week ago between the two very long outages my RAC was even higher and that was my new all time high! A bit over 140000 when my long time average during the time I have been using my current crunching hardware has been about 125000 and the previous all time high had been about 135000.

I have a program that calculates the predicted credit per day of my current work queue using the average credit per processing time I have recently got for each task type (Arecibo/BLC, BLC number, vlar or not, CPU/GPU and host) and this prediction is now 173000!

When things have been stable for long enough time for RAC to reflect the true credit per day, this prediction and my RAC have been pretty close together. RAC usually a little bit lower. The difference reflecting the processing power I have used for non boinc computer usage.

---

Looks like the situation is returning to normal. The noise bomb files are no longer being split, the splitters have now been running continuously for over three hours and the sum of result counts on ssp has been slowly going down despite of this. The queues of my hosts are filling up rapidly.

---

Looks like the situation is returning to normal. The noise bomb files are no longer being split, the splitters have now been running continuously for over three hours and the sum of result counts on ssp has been slowly going down despite of this. The queues of my hosts are filling up rapidly.

I'm glad that you think that there's no more noise bombs being split, but I can tell you otherwise.

Cheers.

Looks like the situation is returning to normal. The noise bomb files are no longer being split, the splitters have now been running continuously for over three hours and the sum of result counts on ssp has been slowly going down despite of this. The queues of my hosts are filling up rapidly.

Get some WU. But not enough to start refill the cache.

---

Looks like the situation is returning to normal. The noise bomb files are no longer being split, the splitters have now been running continuously for over three hours and the sum of result counts on ssp has been slowly going down despite of this. The queues of my hosts are filling up rapidly.

I'm glad that you think that there's no more noise bombs being split, but I can tell you otherwise.

Yep.
Although the percentage of BLC35s that are noise bombs is a lot less than over the last few weeks, there's still plenty of noise bombs there.

---

Grant
Darwin NT

Looks like the situation is returning to normal. The noise bomb files are no longer being split, the splitters have now been running continuously for over three hours and the sum of result counts on ssp has been slowly going down despite of this. The queues of my hosts are filling up rapidly.

I'm glad that you think that there's no more noise bombs being split, but I can tell you otherwise.

Cheers.

I agree. Over 50% of the BLC35 tasks I receive are still noise bombs.

---

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

A proud member of the OFA (Old Farts Association)

I agree. Over 50% of the BLC35 tasks I receive are still noise bombs.

Still way better than 95%+
:-)


Edit- although when you get BLC35 resends, it's back to 95%+ noise bombs.

---

Grant
Darwin NT

blc35 from 27th of July before 8pm (MJD 58691, seconds < 70000) were about 95% noise bombs. I haven't observed any significant amount of overflows from any blc35 later than that. And the only blc35 from the noise window I have received after those disappeared from the splitter list have been _2 ones (resends).

And the constantly running splitters are diluting the stream of those resends. The current queue of my faster host has 0.6% of them. The slower host has 3% because its queue is longer so the time window the stuff in there has been downloaded extends further to the past.

Both queues are now about two thirds Arecibo.

---

I see that we've now hit the point again where the replica is falling behind again. :-(

Cheers.

I see that we've now hit the point again where the replica is falling behind again. :-(

It can fall - there's only 36 hours to Tuesday downtime.

---

21ja20af is providing plenty of noise bombs of it's own to offset the reduction in BLC35 noise bombs.

---

Grant
Darwin NT

Stuck Uploads....ALL my machines have Many Uploads waiting Retry.

Replica db is catching up! It was 2993s behind four ssp updates ago has been slightly less in each update after that. Now 2755s.

---