I just noticed that the credit for a work unit has been reduced from 420 points to 400 points. It would be nice to get an explanation for that.

Best regards
Berthold

I just noticed that the credit for a work unit has been reduced from 420 points to 400 points. It would be nice to get an explanation for that.

Best regards
Berthold

Credits are based on average run times. The WUs in the newer dataset run faster (ratio of the run times is 400/420).

Hi

I'm currently getting 194 credit per task with high variability, from 40mn up to almost 5 hours.....



It's a bit sad.

Eric beat me to it- i was just about to suggest an increase in Credit due to the increased processing time for the new Tasks and decided to check my results- but Eric's already bumped up the Credit per Task to offset the increased runtime.
Nice work, thank you.

---

Grant
Darwin NT, Australia.

Has anyone else noticed a drop in their RAC over the last 2 days?

As far as a i can tell, run times are unchanged, Credit per Task is unchanged, Estimated completion times are around the same, but the RAC on both of my systems has dropped by roughly 5,000 on one and 4,000 on the other (roughly the same percentage drop on both).
RAC was pretty much steady up to the 30/4, then since the 1/5 the drop.

---

Grant
Darwin NT, Australia.

Has anyone else noticed a drop in their RAC over the last 2 days?

As far as a i can tell, run times are unchanged, Credit per Task is unchanged, Estimated completion times are around the same, but the RAC on both of my systems has dropped by roughly 5,000 on one and 4,000 on the other (roughly the same percentage drop on both).
RAC was pretty much steady up to the 30/4, then since the 1/5 the drop.

I haven't looked at my RAC so I don't know if it's dropped. But there was a power outage on April 30th at the building housing the server and it took about 5 hours to restore. I keep about a days worth of tasks on my computers so I had plenty of work during the outage. If you only keep an hour or two of tasks then you may have run out of tasks and that would have affected your RAC.

I also noticed the ETA on the batch status page went up .2 days (~5 hours) - much of that was recovered when users eventually returned the backlog of results, but it didn't completely recover, possibly because some users were starved of tasks during the outage (but there could be other explanations).

I haven't looked at my RAC so I don't know if it's dropped. But there was a power outage on April 30th at the building housing the server and it took about 5 hours to restore.

That would explain it.
I only keep a small cache (less than 2hrs). One system was down for 45min or so to fix a noisy radiator fan, so i was expecting a slight drop on that one, but was surprised when there was a noticeable drop on both.
But with a 5hr server outage, and the increasing backoffs that occur when BOINC can't contact a project server, the systems could have easily been out of work for 8 hours (or more). This morning i noticed that the RAC is starting to climb again, so the server outage does explain the hiccup.

---

Grant
Darwin NT, Australia.

Could you re-check the current value of Credit for completed Tasks?

When this batch first came out, there were a lot of very short running takes, and quite a few extremely short running Tasks. So RAC would have jumped up noticeably, but i saw that you trimmed back the amount of Credit per Task.
Since then, the number of shorter running Tasks has declined significantly, the number of extremely short running Tasks has dried up completely, and i'm getting more & more much longer running Tasks.


End result- My RAC has fallen noticeably, and is continuing to fall; quite steeply now.

---

Grant
Darwin NT, Australia.

Could you re-check the current value of Credit for completed Tasks?

When this batch first came out, there were a lot of very short running takes, and quite a few extremely short running Tasks. So RAC would have jumped up noticeably, but i saw that you trimmed back the amount of Credit per Task.
Since then, the number of shorter running Tasks has declined significantly, the number of extremely short running Tasks has dried up completely, and i'm getting more & more much longer running Tasks.

End result- My RAC has fallen noticeably, and is continuing to fall; quite steeply now.

I run 500 tasks offline in advance and get an average runtime, and the credit is based on this average. For example, if the average goes up 50% from 1 case to the next, then I increase the credit by 50%. I just checked and the ratios are in agreement.

The current case has a larger standard deviation than usual, so you will see greater fluctuations in your run times and RAC, but it should not be a huge difference. The remaining time on an unstarted WU in the manager will give you an idea of what the average runtime is. Comparing that with what it used to be for the previous case, should be in agreement with the drop in credits per task. It is for me - my average went from 59 minutes to 53 minutes per task.

One explanation for the drop could be the recent Formula BOINC competition. Some participants "cherry pick" the tasks by aborting those that start off slow and keep the quickies (those that jump quickly to 50% or higher completion). This means there are fewer quick cases available for the rest of us, and as a result the average gets skewed. The competition ended on Sept 7th, so this effect should have worked itself out by now, and you should see your RAC start going up again (assuming this was the cause). Other than that, the only other explanation I can think of is resource contention on one or more of your computers, or maybe one of your computers was starved of WUs?

Around the time the new batch came out, we had a city-wide power outage for several hours, which caused a big drop. In the past, over the next few weeks the RAC slowly makes it's way back to around where it was.
This time the RAC dropped, and it's been dropping even further since then- its' been dropping more on my RTX 4080 system (that card runs 3 Tasks at a time; the new ones might be loading it more than the earlier batch and reducing it's output). However, the other system (RTX 4070 Ti Super with 2 Tasks running) and it too is dropping it's RAC- just not as much or as quickly.

When things get funny i always check Task Manager in case something's going on that shouldn't be, and both systems show no signs of other processes sucking up CPU time.
The RTX 4070 Ti Super has gone from 254,000 to 248,000. The RTX 4080 has gone from 300,600 to 295,000 (i've set my stats so that in the BOINC Manager it keeps them for several years so i can see how thing are on the Statistics tab over a long period of time).


I have noticed a lot of resends over the last couple of days, but they're often processing faster overall than the current initial release Tasks.

The current case has a larger standard deviation than usual, so you will see greater fluctuations in your run times and RAC, but it should not be a huge difference. The remaining time on an unstarted WU in the manager will give you an idea of what the average runtime is.

Yeah, the initial Remaining (estimated) times have dropped for both the CPU and GPU Tasks, although for the RTX 5080 just over the last day or two they have climbed back up to almost where they were before.
And the CPU & other GPU times are higher than what they were after the initial release of the batch, but still much lower than what they were with the previous batch.


I'll just see how things go over the next couple of weeks.

---

Grant
Darwin NT, Australia.

Around the time the new batch came out, we had a city-wide power outage for several hours, which caused a big drop. In the past, over the next few weeks the RAC slowly makes it's way back to around where it was.
This time the RAC dropped, and it's been dropping even further since then- its' been dropping more on my RTX 4080 system (that card runs 3 Tasks at a time; the new ones might be loading it more than the earlier batch and reducing it's output). However, the other system (RTX 4070 Ti Super with 2 Tasks running) and it too is dropping it's RAC- just not as much or as quickly.

When things get funny i always check Task Manager in case something's going on that shouldn't be, and both systems show no signs of other processes sucking up CPU time.
The RTX 4070 Ti Super has gone from 254,000 to 248,000. The RTX 4080 has gone from 300,600 to 295,000 (i've set my stats so that in the BOINC Manager it keeps them for several years so i can see how thing are on the Statistics tab over a long period of time).

I have noticed a lot of resends over the last couple of days, but they're often processing faster overall than the current initial release Tasks.

The current case has a larger standard deviation than usual, so you will see greater fluctuations in your run times and RAC, but it should not be a huge difference. The remaining time on an unstarted WU in the manager will give you an idea of what the average runtime is.

Yeah, the initial Remaining (estimated) times have dropped for both the CPU and GPU Tasks, although for the RTX 5080 just over the last day or two they have climbed back up to almost where they were before.
And the CPU & other GPU times are higher than what they were after the initial release of the batch, but still much lower than what they were with the previous batch.

I'll just see how things go over the next couple of weeks.

I think I figured out the root cause of what you are seeing. I am basing the credit on the ratio of average CPU times from one batch to the next. So the RAC for just the CPU will be almost dead on. However, it appears the efficiency of the GPU app went down a little bit for this latest batch compared to the previous batch.

Going forward, after the current batch, I will use the better of the two ratios to determine credit. That way, if the RAC changes it will increase instead of decrease. It would be best to have different credits for CPU and GPU, but I can't do that since the same WUs are interchangeable between the two platforms and hence a single credit is associated with the WU.

I think I figured out the root cause of what you are seeing. I am basing the credit on the ratio of average CPU times from one batch to the next. So the RAC for just the CPU will be almost dead on. However, it appears the efficiency of the GPU app went down a little bit for this latest batch compared to the previous batch.

That makes sense.

Going forward, after the current batch, I will use the better of the two ratios to determine credit. That way, if the RAC changes it will increase instead of decrease. It would be best to have different credits for CPU and GPU, but I can't do that since the same WUs are interchangeable between the two platforms and hence a single credit is associated with the WU.

Or even split the difference between the two, with a bias towards the one most affected.
That way with the change in batches, even if one Compute resource is affected more than another, the RAC should still end up being relatively steady with just a small boost or cut instead of getting a larger boost or cut.

---

Grant
Darwin NT, Australia.

Overall, my RAC has dropped by 11,000- which is only 2% but looking at it on a graph, it looks so much larger.
Prior to this batch, since i joined up here back in early January the variation in RAC (other than issues with the project or my systems) has been around 0.6% which is very good IMHO (and probably why the present change in RAC stands out so much).
And with the initial Tasks over the first few days may more of them were completing much sooner than the present ones, so if the Credit per Task hadn't changed then the boost in RAC while significant, wouldn't have been as much as it first looked as though it would be.

Splitting any difference between the two ratios, with a weighting towards the more affected of the two (the bigger the difference, the greater the weighting) should result in a similar RAC with different batches, even if one compute resource is affected more than the other (either up or down).

---

Grant
Darwin NT, Australia.

Overall, my RAC has dropped by 11,000- which is only 2% but looking at it on a graph, it looks so much larger.
Prior to this batch, since i joined up here back in early January the variation in RAC (other than issues with the project or my systems) has been around 0.6% which is very good IMHO (and probably why the present change in RAC stands out so much).
And with the initial Tasks over the first few days may more of them were completing much sooner than the present ones, so if the Credit per Task hadn't changed then the boost in RAC while significant, wouldn't have been as much as it first looked as though it would be.

Splitting any difference between the two ratios, with a weighting towards the more affected of the two (the bigger the difference, the greater the weighting) should result in a similar RAC with different batches, even if one compute resource is affected more than the other (either up or down).

I looked at my timing data on the GPU and am now remembering I was only testing for stability and not for precision timing, so I don't think I should use the GPU timing data to adjust credits. In particular, sometimes I ran with 2 concurrent threads and sometimes 3; and sometimes I adjusted the gpuLookupTable.txt file - in short, the data can't be used to compare changes over batch. I will have to wait until the batches start running and then make an adjustment to credit if necessary.

It's probably still worth doing a pre-release run; little to no change in times then all is good. If there is a significant bump or drop in runtimes, then you've got advance warning that you'll need to take a closer look once the batch is being returned in large numbers.

---

Grant
Darwin NT, Australia.

Further thoughts on why the Initial Remaining (estimated) times have dropped down as much as they have-

Statistics is definitely not my thing, but i did remember some of it, and found the info i was looking for on the BoM (Bureau of Meteorology) web site in relation to rainfall.

Mean rainfall (mm)
The arithmetically averaged total amount of precipitation recorded during a calendar month or year. Both mean and median (decile 5) rainfall are included in these statistics, although from the meteorological point of view the median is usually the preferred measure of 'average' or 'typical' rainfall. This is because of the high variability of daily rainfall - one extreme rainfall event (such as a slowly moving, severe thunderstorm) will have less affect on the median than it will have on the arithmetic mean.

The Initial Remaining (estimated) times are based on the average (arithmetic mean) of previous completed Tasks.
And as that information with regards to rainfall points out- one extreme value will have an outsized impact on the average.
So the even though they are only very, very occasional, those extremely short runtime Tasks skews the average down much lower than it would be without those outliers in there.

---

Grant
Darwin NT, Australia.