A quick and dirty band-aid would still be more appealing than what we have now. But agree that it still would suffer the same degrading over time that the current algorithm inflicts.

---

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

A proud member of the OFA (Old Farts Association)

The other option is to do nothing and hope that the credit level drops to such a point that enough switch to other projects to cause enough of a backlog of work that causes those that administer Seti to start looking for reasons for why processing is slowing.

Has anyone got any form of detailed stats on the number of active users and active hosts going back over a number of years to see if there is a drop in users and hosts.

I have just had a good look around in the Boinc Stats pages for Seti and it looks that at least over the last 60 days there is a drop in active hosts and users and also a drop in credit per day issued over the same period.

The chart for my I7 machine that I said was embarrassing I have reproduced below thanks to TBar for providing enough clues for me to work out how to do so.

It really shows how bad the credit is being issued for the amount of work being done, This machine is running 4 CPU WU's and 1 GPU WU for Seti against 1 GPU for Einstein, Ignore the blip for CPND that project has not been run over that period the blip was caused by them working on their servers.



If I switched this over to just Seti my Seti RAC for that machine would rise from 24K to about 40K.

---

Kevin

I can't believe how fast my RAC dropped just from the two days the systems were off because I had to turn them off because I lost air conditioning. I've dropped from 5th to 6th on the Top Participants list. My fastest cruncher dropped from 3rd to 4th. The credit awarded for BLC tasks is now normalized at 50 credits or less. Half the Arecibo credit.

My new cpu block is working quite well however. I gained the 2-3° C. that was told to expect. Have been able to push the cpu clock a bit more now that I have more headroom.

---

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

A proud member of the OFA (Old Farts Association)

IThe credit awarded for BLC tasks is now normalized at 50 credits or less. Half the Arecibo credit..

That`s one of the reasons why I love Creditscrew.

---

That's all OK, you two moved down in rank, I moved up :D

---

That's all OK, you two moved down in rank, I moved up :D

LOL. As Monty Python would sing . . . "always look on the bright side of life"

Ta dum. Ta dum, ta dum ta dum ta dum.

---

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

A proud member of the OFA (Old Farts Association)

As I said, you still get the warts.
Good luck getting them to use a completely different credit system, we've seen how well that works. A simple x2 to is very easy to apply to the current system, and is just as easy to remove. I would suggest doing it without any announcement, and certainly well before the WOW event...which isn't that far away.

. . A good point. With the credit at such an all time low the numbers for the WOW event will tell a very sad story ...

Stephen

:(

All it would take is adding a simple x2 to the equation.
Naw...to simple.

And it doesn't address the low amount of Credit awarded for Arecibo tasks, and it doesn't address the variability of Credit awarded depending on hardware, OS, driver & application, and doesn't address cross project comparisons.

Instead of implementing another kludge, that is just a patch & doesn't actually fix anything, why not fix the whole problem? Especially when it's as simple as paying out credit in accordance with the stated definition of the Cobblestone?
That's all that is required to fix everything, not just one of the many issues.

. . From what I gather the biggest issue is the accurate measurement of Flops per task. I have seen a "flop counter" number in some results but it is way lower than what I get using APR times run time in seconds. So either that flop counter doesn't work well or the APR numbers are way way off. The only thing I feel sure of is the actual run times. But even using the numbers reported by the flop counter credit should be higher than it is.

Stephen

? ?

. . From what I gather the biggest issue is the accurate measurement of Flops per task. I have seen a "flop counter" number in some results but it is way lower than what I get using APR times run time in seconds. So either that flop counter doesn't work well or the APR numbers are way way off. The only thing I feel sure of is the actual run times. But even using the numbers reported by the flop counter credit should be higher than it is.

There has been no FLOPs counting since the second system of determining Credit.

There is no issue with the FLOPs estimates for each WU (those of use running anonymous platform will never see the actual estimate as the value we get is modified in order to get runtime estimates close to reality).
The problem is with the way Credit New works out how much Credit to award for work done.

All that needs to be done is for Credit to be awarded in accordance with the definition of a Cobblestone- that's it. No further tweaks, modifications, re-designs or anything like that is necessary.

---

Grant
Darwin NT

But the trouble with the "Cobblestone" is that it is a scaled guesstimate for the FLOPs performed, relying on some "fictitious" processor that may have never existed.

---

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

But the trouble with the "Cobblestone" is that it is a scaled guesstimate for the FLOPs performed, relying on some "fictitious" processor that may have never existed.

It doesn't matter whether or not the processor exists or not.
It's not relevant to anything in any way shape or form.

All it says is you get so many Credits (200) when you process work for a given period (24hrs) with a machine capable of a given number of FLOPs (1 GFLOP).
That is the definition of a Cobblestone, and so all work should be paid according to that definition.

The number of FLOPs required to process a given WU determines how much Credit it is worth, according to the Cobblestone definition.

Any project that wishes to use BOINC must know how many calculations will be required to process their work to get a result for a given WU (in the case of Seti, different WUs have different computational requirements). They can either work that out manually or they can develop an application specifically to count the number of FLOPs required to produce a result. Either way, all that is required is a reasonably accurate estimate of the number of FLOPs required to process a WU- this being done with no optimisations, algorithmic shortcuts or other optimisations. Effectively it is the number of FLOPs required to produce a valid result, were it being done by hand.
And as long as the estimated (or counted) FLOPs for a given WU is reasonably close to the true value, then the amount of Credit awarded will be consistent with the Cobblestone definition.

And guess what? All the stated goals of Credit New are met bar one- penalising cherry picking. Which can be done using a more effective method, unrelated to Credit granted.


It really is that simple.
Seriously- just think about it people.

What is Credit New trying to do?
It is trying to allocate Credit for work done over a given period of time. Whether it is done over 3 days or 30 seconds the amount of Credit for a given WU should be the same- the same amount of work needs to be done- that is what the Credit mechanism is trying to do. But what value is it trying to award?
It is trying to award a value inline with the definition of a Cobblestone.

So instead of having a convoluted mess that doesn't do what it is supposed to, why not use a much simpler system, that actually meets the goals as stated for Credit New?
It really is that simple.

---

Grant
Darwin NT

Which OS?

---

A proud member of the OFA (Old Farts Association).

. . From what I gather the biggest issue is the accurate measurement of Flops per task. I have seen a "flop counter" number in some results but it is way lower than what I get using APR times run time in seconds. So either that flop counter doesn't work well or the APR numbers are way way off. The only thing I feel sure of is the actual run times. But even using the numbers reported by the flop counter credit should be higher than it is.

There has been no FLOPs counting since the second system of determining Credit.

. . Then why does the AVX-CPU app report this ??

Flopcounter: 23700202793591.930000

. . Though in re-examining it, it is actually much worse than the credit we are getting. 23700GFlops/864 = 27.43 cobblestones. yeeeoooouuu!

. . My CPU APR is 80GFlops and that task took 2392 secs making it 191,360 Gflops which is 221 cobblestones, and while I am only guessing here, I suspect that the reality lies somewhere in between.

. . Credit New gave that task 54.66 credits. Double the app flopcounter but only 1/4 of what the APR suggests. So what can we trust?

. . SoG gave a similar task

Flopcounter: 2315496861335.769500

. . That makes it 26.8 Cobs, that GPU APR is 125 GFlops and it took 1365 secs making it 170,625 GFs or 197.5 Cobs and Credit New gave it 56.33 credits.

. . Sadly I don't know for sure what flop estimate was assigned to either of those tasks but all the GPU tasks waiting show 28,632 and all the CPU tasks waiting show 8,868, and they are all Blc03 tasks. So where is the benchmark to assign an accurate estimate of actual flops required for each task type?

Stephen

? ?

There has been no FLOPs counting since the second system of determining Credit.

. . Then why does the AVX-CPU app report this ??
Flopcounter: 23700202793591.930000

Poor choice of terminology.

So where is the benchmark to assign an accurate estimate of actual flops required for each task type?

The project determines & assigns the number of FLOPs for a given WU.

---

Grant
Darwin NT

There has been no FLOPs counting since the second system of determining Credit.

. . Then why does the AVX-CPU app report this ??
Flopcounter: 23700202793591.930000

Poor choice of terminology.

So where is the benchmark to assign an accurate estimate of actual flops required for each task type?

The project determines & assigns the number of FLOPs for a given WU.

Yes, from what Richard has posted lately about the wrong rsc_fpops_bound value being posted for newly generated GPUGrid.net tasks which caused lots of errors because of time exceeded errors, each task is assigned a flops count that can be grossly off because of that rsc_fpops_bound value for the project. So no benchmark but there is an assigned value for the estimated flops count for each task and that is determined just by what the project scientists 'think' might be the value.

---

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

A proud member of the OFA (Old Farts Association)

Been busy, combination of work, weather and a very poorly dog.

Weather wise its not only the heat which has been the hottest we have seen for a very long time but also a high humidity which makes it even worse.

Lady, one of my dogs, she is not a youngster, is not handling the heat as well as she could and I am having to keep a constant eye on her to try to keep her as cool as possible.

Both computers are backed down a certain amount, again heat problems, Threadripper has locked up a couple of times, presuming heat related as every time if I reduce CPU processing she will carry on fine, been seeing loop temps 45 - 50C which is too hot.

@ Keith, sorry I have not got back to you, the answer is yes.

---

Kevin

If a Ryzen/TR locks up under heavy load, the usual reason is not enough cpu core voltage. Either increase the core voltage or back down the cpu clock. That will reduce the temps greatly too. The clock/voltage/temp curve is hyperbolic with Ryzen/TR.

---

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

A proud member of the OFA (Old Farts Association)

Its not just the load its the temps, it can handle the load when external temps are good but when they rise it locks, was thinking more of high temps on MB voltage regulators.

Will try playing with them settings after work.

---

Kevin

Unless the VRM temps are pushing 80° C. they shouldn't be a problem. The actual devices are rated to 125° C. What has come to light lately on the Ryzen /TR forums is that having the memory running at north of 40° C. is likely to cause instability. Solution seems to be putting a fan on the RAM or improving the case air flow in that area.

---

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

A proud member of the OFA (Old Farts Association)

Unless the VRM temps are pushing 80° C. they shouldn't be a problem. The actual devices are rated to 125° C. What has come to light lately on the Ryzen /TR forums is that having the memory running at north of 40° C. is likely to cause instability. Solution seems to be putting a fan on the RAM or improving the case air flow in that area.

Cases with door mounted fans have gone out of fashion, thats what I used to like about my old coolermaster case.

I will get a fan and blow air direct into case and see if it runs stable like that.

---

Kevin