No, I am doing the exact same thing on the FX rigs. I haven't been able to fathom why the 8370 has fallen so far behind the 8350.

Different work mix?
Today my C2D has been getting just Arecibo Work, with the odd GBT WU thrown in (just got a dozen GBT WUs- most in ages) > Even over the last week it has been heavily Arecibo work.
My i7 while been getting mostly Arecibo work has had periods of batches of GBT work coming through.

That is the likely scenario but I haven't detected a large difference in the Arecibo/GBT mix of work between the two systems at casual glance. I haven't conducted an extensive forensic analysis with antenna origin cataloging. The same here with mostly Arecibo work on all three systems with brief spurts of GBT work. The 8370 is SLOWLY coming back to its normal RAC.

How is the project RAC determined? I always thought the project pulled the stats for the host out of the statistics_setiathome.berkeley.edu.xml file on each computer. And that file is what is used to plot the statistics curve on the Statistics tab in the Manager. As I stated, my Statistics curve has been flatlined at 50K for the last month. It never showed the precipitous plummet in my RAC that the project is showing on my Host numbers for the 8350 host.
Keith-Windows7 statistics

---

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

A proud member of the OFA (Old Farts Association)

No, I am doing the exact same thing on the FX rigs. I haven't been able to fathom why the 8370 has fallen so far behind the 8350.

Different work mix?
Today my C2D has been getting just Arecibo Work, with the odd GBT WU thrown in (just got a dozen GBT WUs- most in ages) > Even over the last week it has been heavily Arecibo work.
My i7 while been getting mostly Arecibo work has had periods of batches of GBT work coming through.

That is the likely scenario but I haven't detected a large difference in the Arecibo/GBT mix of work between the two systems at casual glance. I haven't conducted an extensive forensic analysis with antenna origin cataloging. The same here with mostly Arecibo work on all three systems with brief spurts of GBT work. The 8370 is SLOWLY coming back to its normal RAC.

How is the project RAC determined? I always thought the project pulled the stats for the host out of the statistics_setiathome.berkeley.edu.xml file on each computer. And that file is what is used to plot the statistics curve on the Statistics tab in the Manager. As I stated, my Statistics curve has been flatlined at 50K for the last month. It never showed the precipitous plummet in my RAC that the project is showing on my Host numbers for the 8350 host.
Keith-Windows7 statistics

BOINC updates recent average credit "RAC" when new credit is granted. A decay value is factored in so that it is "recent".

function decay_average($avg, $avg_time, $now = 0) {
   $M_LN2 = 0.693147180559945309417;
   $credit_half_life = 86400 * 7;
   if ($now == 0) {
       $now = time();
   }
   $diff = $now - $avg_time;
   $weight = exp(-$diff * $M_LN2/$credit_half_life);
   $avg *= $weight;
   return $avg;
}

Sometimes I think the decay function pulls numbers out of nowhere when I see a host RAC drop 50% for seemingly no reason.

I believe that each time the BOINC client does a project update it also updates the statistics_PROJECT.xml file.
Then BOINC Manager will read the xml and make a neat little graph based on the stored values.
If you want you can read the expavg values directly from the xml file.
<daily_statistics>
<day>1499731200.000000</day>
<user_total_credit>168746186.262877</user_total_credit>
<user_expavg_credit>60883.935743</user_expavg_credit>
<host_total_credit>11508519.704933</host_total_credit>
<host_expavg_credit>6851.901127</host_expavg_credit>
</daily_statistics>

At the super compressed scale of your image each one of the vertical lines in the chart would possibly be a difference of ~5000. So it looks like on 2017-07-04 your RAC was ~45,000 & on 2017-06-18 it was ~55,000.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Thanks for the explanation on how RAC is calculated Hal. Yes, you are correct. I never considered the compression in the vertical height in the graph to fit all projects. I remembered that you can plot individual projects separately. I did in fact hit the low spot you mention.
SETI statistics

I guess I just had a particularly poor paying mix of work on that host compared to the 8350 host over the last month.

---

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

A proud member of the OFA (Old Farts Association)

Thanks for the explanation on how RAC is calculated Hal. Yes, you are correct. I never considered the compression in the vertical height in the graph to fit all projects. I remembered that you can plot individual projects separately. I did in fact hit the low spot you mention.
SETI statistics

I guess I just had a particularly poor paying mix of work on that host compared to the 8350 host over the last month.

With all the different factors it is sometimes hard to determine which of them cause the short term ups and downs.
So use a script to average the values in the stats file. Right now I read all of the values so it looks like this.
Host 8130144 Average: 26897 for 244 days
I think I'm going to add some other output as well. Like averages for the 30, 60, & 180 days as well as the total credit gained for each time period.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Just took over a minute for the web site to come up, and the last couple of Scheduler requests timed out with a "Couldn't connect to server" error.

EDIT- Now the Scheduler is responding, but it won't give me any more work.

EDIT- And then a whole load came down.
The randomness of WU allocation makes me suspect it's tied in with the randomness of Credit New's determination of credit to allocate to each WU.

---

Grant
Darwin NT

Just took over a minute for the web site to come up, and the last couple of Scheduler requests timed out with a "Couldn't connect to server" error.

EDIT- Now the Scheduler is responding, but it won't give me any more work.

EDIT- And then a whole load came down.
The randomness of WU allocation makes me suspect it's tied in with the randomness of Credit New's determination of credit to allocate to each WU.

And now back to not sending tasks.

---

Grant
Darwin NT

As a fairly recent user of using an NVidia GPU for the project (my first NVidia card was actually a new Riva TNT - that's a while ago!), the thing that annoys me most, is when a GPU task or even several tasks are completed and then I get a load of CPU tasks sent and no GPU tasks. I then end up, having to suspend GPU work, change to 100% CPU use, to deal with the ever increasing number of CPU tasks, periodically. I'd rather have no more CPU tasks being sent! More frustrating still, are the messages from the server that say that AMD/ATI GPU tasks are available, but my preferences are set not to accept them....why would I accept them if I don't have an AMD/ATI GPU in the thing? Yes, I also get the same message about the Intel GPU, but obviously, using that was not going to involve a 'free lunch'.

---

Don't take life too seriously, as you'll never come out of it alive!

Iona, If you use app_config to limit the number of running cores (reserve) while GPU tasks are running, the CPU cores will automatically be free to start crunching when GPU tasks run dry.

Ah, thanks for that, Brent. That's useful to know.

---

Don't take life too seriously, as you'll never come out of it alive!

Hmm, they're latter than normal for maintenance this week.

Famous last words, eh, Brent?

---

Don't take life too seriously, as you'll never come out of it alive!

Yeap, very soon after that .... POOF

Shortest data tape I have seen in a while 28ja08aa 2.76 GB. I wonder whether or not it will be full of shorties because of the short tape. I doubt it will be. Man would be funny if it was though

---

It will be the end of a tape that has already been part-processed.
As recorded the tapes are 50Gb, but if the processing get stalled part way through for any reason and then re-started the tape will appear to be under-sized.

---

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

It will be the end of a tape that has already been part-processed.
As recorded the tapes are 50Gb, but if the processing get stalled part way through for any reason and then re-started the tape will appear to be under-sized.

Thank you for the above information. Another piece of information would great to know when tape started to be split and when it ended/What tape is going to be split next. I cannot see the speech have been added anytime soon as probably not a lot of people would be interested in this information

---

Well, that was a fun run of APs for a couple weeks there. Looks like we're back to 2008 tapes again, so the 16 and 17 tapes seem like they're probably done.

Can you tell it's been a while since we had any of them?

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

OK, am I imagining this or did the project put more validators online this Tuesday? I was used to seeing about a 400 task difference between Valid tasks and Pending tasks. Now, on all three crunchers, the Valid tasks are almost equal to the Pending tasks. Is this just circumstance or did something change with the servers?

---

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

A proud member of the OFA (Old Farts Association)

I noticed that too awhile ago, but never really paid much attention to what the numbers were before, but definitely higher.
As I watch now, my numbers are going up again.

I noticed that too awhile ago, but never really paid much attention to what the numbers were before, but definitely higher.
As I watch now, my numbers are going up again.

Nope, you are correct. Things are going back to normal with about 400 tasks difference. Must have just been a happy convergence between the two functions for a brief moment.

---

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

A proud member of the OFA (Old Farts Association)

Guess such a thing is a "Probability" issue.