I've decided after fall of RAC to run other projects and not focas on RAC with just 1 laptop was bound to happen,
running Milkyway@Home what others are good?

I run Seti for the science, not for the Credit (yes, it would be nice to have our contributions acknowledged, but i'm doing the work because I like the concept of the project. Is there anyone else out there? Won't know if we don't look).

. . Sums it up.

Stephen

:)

Is it pure coincidence that we are all seeing our RAC drop after probably installing a certain patch from Microsoft in the last 7 days that was headlined to slow PC's down by up to 30% ????

. . The drop in RAC is even more pronounced on my Linux machines than on my Windows machine.

Stephen

:(

I watch my machines quite closely and have not noticed sub 50s credit awards like this in the past. I did try something different in the latest work shortage. I decide to try the rescheduler for the first time. I used it to move several hundred GPU tasks to CPU. Since I knew the machine would completely run out of work, I decided on a strategy to keep it fully loaded. I moved enough GPU tasks to CPU to make sure the CPU would be fully loaded while I slept my Sunday evening. I then enabled mining on the GPUs. In the morning, I stopped mining and un-suspended GPUs. Everything looked normal. Only thing that doesn't make sense is that it is not the rescheduled work that is getting the lower credit. It is the work that actually ran afterward on the GPUs. Anyone think this is the cause?

No that is NOT the cause. CreditScrew is the cause. Think about it. You moved tasks assigned originally to the gpus on your system. The scheduler took into account the APR for the gpu application. You moved the gpu tasks temporarily to the cpu for bunkering. The scheduler and server has no knowledge of this action. You then move your gpu tasks temporarily stored in the cpu cache back to the gpu cache where you process them during the outrage.

What has changed? Nothing. You processed the originally assigned gpu tasks on the gpu as intended. You get 50 credits per task. Thank you CreditScrew.

---

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

A proud member of the OFA (Old Farts Association)

You get 50 credits per task. Thank you CreditScrew.

You're getting 50 credits per task?? Who did you pay off?? WHO!!!!

edit...

Tell me!!

---

He has acknowledged a problem with credit, though: credit is a BOINC-wide problem, not a SETI problem. Issue #2132

Issue #2132 (Fixed URL)

---

No that is NOT the cause. CreditScrew is the cause. Think about it. You moved tasks assigned originally to the gpus on your system. The scheduler took into account the APR for the gpu application. You moved the gpu tasks temporarily to the cpu for bunkering. The scheduler and server has no knowledge of this action. You then move your gpu tasks temporarily stored in the cpu cache back to the gpu cache where you process them during the outrage.

What has changed? Nothing. You processed the originally assigned gpu tasks on the gpu as intended. You get 50 credits per task. Thank you CreditScrew.

In my case, I am not doing "bunkering". I moved a bunch of WUs to CPU and left them there. I was not trying to get more tasks, only keep my CPU fully loaded during the outage. I only run SETI and LHC, and LHC doesn't have GPU tasks, so my plan was to move tasks from GPU to CPU to keep the CPU loaded during the outage and use the GPUs for mining. But if this is messing up credit calculations for work done, then I won't do it.

Low consistent credit is not an issue for me. What I like about LHC is that credit is also very low, perhaps even more difficult than SETI. This makes the competitive computing aspect of it even more meaningful. I only raised the concern in this thread since some of the observations after rescheduling seemed extreme. Even some tasks below 20credits, so still concerned that rescheduling is a factor. In this case, there is also a shift in work unit types, so still uncertain what happened.

---

GitHub: Ricks-Lab
Instagram: ricks_labs

You can find out all about Credit new here.

---

Grant
Darwin NT

You get 50 credits per task. Thank you CreditScrew.

You're getting 50 credits per task?? Who did you pay off?? WHO!!!!

edit...

Tell me!!

Chuckle! It looks like that brief tail-end of the tapes yesterday in between the BLC05's and the new BLC02's, specifically the BLC13/14/25's are awarded more credit than the fast BLC05's. I'm seeing shadows of the normal Arecibo credits in the 70's and 80's.

---

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

A proud member of the OFA (Old Farts Association)

Rick, I misunderstood your move was not bunkering, but in fact just rescheduling. Since that was the case, your APR for the original gpu tasks and the CreditNew algorithm are not in sync since you processed them on the cpu with an entirely different APR. That explains the discrepancy in credit awarded.

---

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

A proud member of the OFA (Old Farts Association)

You can find out all about Credit new here.

Always good to provide the link to the explanation of CreditNew when the question arises anew. Thanks, Grant.

---

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

A proud member of the OFA (Old Farts Association)

If somebody has some hard data showing just what the impact of rescheduling is on granted credits, or can run some new tests to generate a comparison, I think it would be very useful. When I first experimented with rescheduling in June of 2016, there were some people who said it did affect credit and others who said that was a myth that had already been put to rest long before.

So, just to make sure that my own rescheduling wasn't messing up other people's credit, I did some fairly extensive comparisons. My results were posted in Message 1799300. The conclusion I reached, based on those results, was that rescheduling had "no more impact to the credits than is caused by the random number generator that assigns them in the first place."

Rescheduling at that time simply meant moving Guppi VLARs that were originally assigned to the GPUs over to the CPUs, and moving non-VLAR Arecibo tasks that were originally assigned to the CPUs over to the GPUs. So, yes, tasks were being run on a different device than what they were originally assigned to, which is the issue that is being raised again here.

Now, perhaps things have changed in some way in the last year and a half, such that my previous conclusion is no longer valid. If so, I think new testing and documented results would be needed to demonstrate it.

How would you test for that. Easy enough to run the same task in the benchmark apparatus with a cpu and then gpu. But how do you submit the same task to the project for validation and credit award?

---

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

A proud member of the OFA (Old Farts Association)

Thanks for the link Jeff. I guess I missed that thread entirely and see it was the inception of the rescheduler concept.

---

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

A proud member of the OFA (Old Farts Association)

If somebody has some hard data showing just what the impact of rescheduling is on granted credits, or can run some new tests to generate a comparison, I think it would be very useful. When I first experimented with rescheduling in June of 2016, there were some people who said it did affect credit and others who said that was a myth that had already been put to rest long before.

So, just to make sure that my own rescheduling wasn't messing up other people's credit, I did some fairly extensive comparisons. My results were posted in Message 1799300. The conclusion I reached, based on those results, was that rescheduling had "no more impact to the credits than is caused by the random number generator that assigns them in the first place."

Rescheduling at that time simply meant moving Guppi VLARs that were originally assigned to the GPUs over to the CPUs, and moving non-VLAR Arecibo tasks that were originally assigned to the CPUs over to the GPUs. So, yes, tasks were being run on a different device than what they were originally assigned to, which is the issue that is being raised again here.

Now, perhaps things have changed in some way in the last year and a half, such that my previous conclusion is no longer valid. If so, I think new testing and documented results would be needed to demonstrate it.

My results also show that rescheduled work from GPU to CPU gets normal if not higher credit. See this example 6317203128. My observation is that non-rescheduled WU's that ran after the rescheduling event get lower credit. This could be the result of the WUs post outage are very different than WUs before. But I was concerned that something is going on with credit calculation after the rescheduling. Did the rescheduled work somehow change the reference for credit calculation of new WU's? Can information be extracted for the 2 WUs I referenced to verify this?

---

GitHub: Ricks-Lab
Instagram: ricks_labs

As I love doing Seti@home would doing the Beta version be good idea or waste of time?

Cheers in advance
Steve

when i've a look at my validated Wu , i can notice shorter crunch times for theses BLC WU , perhaps lot of BLC shorties all Vlar_0 or Vlar_1 for GPU /CPU ??
normal GPU BLC wu takes about 100 credits in 40min (longer than arecibo wus ), theses ones takes 30min for 50-75 credits ..

for my cpu, last "normal" BLC takes about 280mins /Wu ( Arecibo more than 300min) , now, they takes 180 to 300mins for 50-75 credits ..

---

Beta is only a test platform for new applications (server or cruncher), it does not directly contribute to the science of SETI@Home.
As such Beta does tend to "pay" lower than one would expect, and can result in some very strange behaviour....

---

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

I don't think you can draw any valid conclusions yet, Rick. I think you have to run the test for a much longer period to stabilize the APR for rescheduled tasks and also to have a much bigger variety of task types. We've already seen that there is a large difference in task times between BLC types and even changes in task times between the same type, specifically the early BLC04's and BLC13's of past months and the more recent versions.

It all comes down to how BOINC interprets the "difficulty" of the task. I've posted about the very large difference in credit awards I see over at GPUGrid.net for CPU tasks. Some tasks got 180 credits and the some other tasks got 7 credits for basically the same running time. It was explained the difference was the size of the molecule involved and therefore the "difficulty" assigned by BOINC in awarding credit.

---

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

A proud member of the OFA (Old Farts Association)

How would you test for that. Easy enough to run the same task in the benchmark apparatus with a cpu and then gpu. But how do you submit the same task to the project for validation and credit award?

For this type of test, there's really nothing an offline bench can tell you. You actually have to move one group of tasks from CPU to GPU and another group from GPU to CPU. Then just match the task types and ARs as closely as possible and record the amount of credit awarded.

In the tables that I linked to, you can see that I included 46 different tasks, all grouped by task type (Guppi VLAR and Arecibo non-VLAR), with ARs as closely matched as I could get them over the period that I was monitoring. Then each group is further broken down based on the device originally assigned vs. the device where the tasks actual ran, with unrescheduled tasks on both CPU and GPU as controls.

Since we currently have very few Arecibo non-VLARs showing up, any current test could only compare similar Guppi VLARs, but that could still be informative.

Of course, all that is dependent on actually receiving new tasks of any kind sometime later this year. ;^)

I participate in the tests done in the past, you could compare the crunching times etc but not really the credits since the credit depends on your wingmate hosts performance too. That's one of the problems of CreditScrew. You can't really control the test environment to be sure if your results have really meaning or no.

---