I've been running dual GPU's since MB V6 and towards the end of that run my then Q6600 with dual GTX 660's, an Athlon X4 630 with dual GTX 550 Ti's and an C2D E6300 with a GTX 560 Ti were producing a RAC of 120K, things have been going backwards ever since.

Cheers.

https://setiweb.ssl.berkeley.edu/beta/

Beaten to it, but made a linky.....

---

I not see any credit complains on E@H who uses a fix credit per WU crunched.

Very easy there, as you know each WU on a given host has the same run time.

ThatÅ› is exactly the same who happening in Seti (WU of the same type & with similar AR) if you look one host or i'm wrong?

Anyway that's why i post:

Will need to adjust the base value according the WU type (blc, Arecibo, AP, Vlars, etc) due the differences on crunching times, but that is easily to do

Not a hard task to do a WU Type x AR x Credit simple table.......

---

Just need a bit of calibration to produce a linear regression line for each of the "main" types of task (currently two, maybe three - VLAR, normal, VHAR) - then there's only two parameters needed for each type (slope & intercept). So simple....
The "big" fun is in setting the AR ranges for the types, as with the current data sets they are all low.

What we need is a big pile of run times and ARs for CPU tasks, all on "simple" processor system running the stock application. Then spend a bit of time doing the banding and correlation. before getting the pruning shears out on the code and binning a lot of the complexity that is CreditScrew.

Why stock application? - its the foundation on which all the others are built.

Use a "low end" CPU to do the calibration, this will more readily show the (dis)advantages of using optimised applications and/or high performance processors.

With a stable credit system it becomes easier to do comparisons between users and systems

As others have either said or implied, driven from the data the credit reward per task is not going to be upset by the vagaries of the user.

---

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

Simple, transparent & eficient.

---

Isn't the problem that the BLC splitters are just not assigning the proper flops estimate as compared to what the Arecibo ones did/do? Since the system was 'tuned' (using the term loosely) to only Arecibo tasks being present that would be the so called baseline. If the BLC tasks were assigned a lower flop estimate, we wouldn't be finishing them in less time than estimated, which should stabilize 'normality' ??

Isn't the problem that the BLC splitters are just not assigning the proper flops estimate as compared to what the Arecibo ones did/do? Since the system was 'tuned' (using the term loosely) to only Arecibo tasks being present that would be the so called baseline. If the BLC tasks were assigned a lower flop estimate, we wouldn't be finishing them in less time than estimated, which should stabilize 'normality' ??

No. The problems with CreditScrew were easy enough to see well before GBT work was even thought of (although D.A. refused to want to see the problem or the evidence with it back then). Then GBT work, when it came along, just made the problem so much more easier to see (but still D.A. insisted he was right and we were wrong), but now with just GBT work available even a blind monkey can see the problem and so D.A. had to finally admit that his CreditNew was badly flawed.

Cheers.

Heck, as long as it provides consistent credit for a given amount of work done, you can call it kibbles for all I care. All I want is consistency, I really don't care about the actual number. 100, 1000, whatever. Just make it Consistent!

That was the system that preceded Credit New.

---

Grant
Darwin NT

Isn't the problem that the BLC splitters are just not assigning the proper flops estimate as compared to what the Arecibo ones did/do? Since the system was 'tuned' (using the term loosely) to only Arecibo tasks being present that would be the so called baseline. If the BLC tasks were assigned a lower flop estimate, we wouldn't be finishing them in less time than estimated, which should stabilize 'normality' ??

The splitters have nothing to do with how the flops estimate is generated. Their task is simply splitting the tapes. The CreditNew algorithm in the main server code is what determines the flops estimate according the math and logic posted in the CreditNew Wiki link that has been posted many times now. I think the main key is to focus on these parts of the Wiki:

Notes:

Version normalization is only applied if at least two versions are above sample threshold.
Version normalization addresses the common situation where an app's GPU version is much less efficient than the CPU version (i.e. the ratio of actual FLOPs to peak FLOPs is much less). To a certain extent, this mechanism shifts the system towards the "Actual FLOPs" philosophy, since credit is granted based on the most efficient app version. It's not exactly "Actual FLOPs", since the most efficient version may not be 100% efficient.
If jobs are not distributed uniformly among versions (e.g. if SETI@home VLAR jobs are done only by the CPU version) then this mechanism doesn't work as intended. One solution is to create separate apps for separate types of jobs.
Cheating or erroneous hosts can influence app_version.pfc_avg to some extent. This is limited by the "sanity check" mechanism, and by the fact that only validated jobs are used. The effect on credit will be negated by host normalization (see below). There may be an adverse effect on cross-version normalization. This could be eliminated by computing app_version.pfc_avg as the sample-median value of host_app_version.pfc_avg

I think the host normalization function is very broken.

The second normalization is across hosts. Assume jobs for a given app are distributed uniformly among hosts. Then the average credit per job should be the same for all hosts.

To achieve this, we scale PFC by the factor

app_version.pfc_avg / host_app_version.pfc_avg

This scaling is only done if both statistics are above sample threshold.

There are some cases where hosts are not sent jobs uniformly:

job-size matching (smaller jobs sent to slower hosts)
GPUGrid.net's scheme for sending some (presumably larger) jobs to GPUs with more processors.
The normalization by wu.fpops_est handles this (assuming that it's set correctly).

Notes:

For apps with large variance of job sizes, the host normalization mechanism is vulnerable to a type of cheating called "cherry picking". A mechanism for defeating this is described below.
The host normalization mechanism reduces the claimed credit of hosts that are less efficient than average, and increases the claimed credit of hosts that are more efficient than average.

We just need to persuade DA to take action on the developer issue already logged instead of just kicking the can down the road.

---

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

A proud member of the OFA (Old Farts Association)

I not see any credit complains on E@H who uses a fix credit per WU crunched.

Very easy there, as you know each WU on a given host has the same run time.

???
I only do GPU work there, but I see a tremendous variation in runtime for that same 3450 points, anywhere from 3-4 minutes to as much as 30.
I turned off CPU work, as I very seldom run out of SETI CPU tasks.
But I don't care for the fixed approach, given the variations I see.

---

That was the system that preceded Credit New.

Yes, that was when an AP was worth 1344 credits and doing MB's over the same time period was worth just as much. Now those were the days.

In fact the credit received here wasn't that much below what Einstein paid at that time (and still pays), but now it's a huge difference between the 2 projects as Einstein didn't change over to CreditNew as even they at the time could see that there was a big problem with it way back then also.

Cheers.

The host normalization mechanism reduces the claimed credit of hosts that are less efficient than average, and increases the claimed credit of hosts that are more efficient than average.

We just need to persuade DA to take action on the developer issue already logged instead of just kicking the can down the road.

One of the major issues is the hang-up about efficiency, and how efficiency is determined. It uses a claimed value for GFLOPs for the device, and then a calculated (not actual counted) value for the FLOPS when processing a WU.
By this system, GPUs are considered extremely inefficient because their claimed FLOPS rating is much more than the estimated FLOPs when processing a WU. Yet by any normal measure of efficiency- WUs processed per hour, WattHours of power used to process a WU etc, GPUs leave CPUs for dead.
And remember when SoG was released on main how Credit took a hit? A more efficient GPU application than previously existed resulted in less Credit being granted, when it should have granted more for the increase in (theoretical) efficiency.

---

Grant
Darwin NT

I not see any credit complains on E@H who uses a fix credit per WU crunched.

Very easy there, as you know each WU on a given host has the same run time.

???
I only do GPU work there, but I see a tremendous variation in runtime for that same 3450 points, anywhere from 3-4 minutes to as much as 30.
I turned off CPU work, as I very seldom run out of SETI CPU tasks.
But I don't care for the fixed approach, given the variations I see.

I assume the 30 minute tasks are by the 750Ti??? Certainly not from the 980's.

---

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

A proud member of the OFA (Old Farts Association)

One of the major issues is the hang-up about efficiency, and how efficiency is determined. It uses a claimed value for GFLOPs for the device, and then a calculated (not actual counted) value for the FLOPS when processing a WU.
By this system, GPUs are considered extremely inefficient because their claimed FLOPS rating is much more than the estimated FLOPs when processing a WU. Yet by any normal measure of efficiency- WUs processed per hour, WattHours of power used to process a WU etc, GPUs leave CPUs for dead.
And remember when SoG was released on main how Credit took a hit? A more efficient GPU application than previously existed resulted in less Credit being granted, when it should have granted more for the increase in (theoretical) efficiency.

Exactly. Somewhere back in the cobwebs of my memory, I believe it was mentioned that the efficiency calculation was tied into the then new AVX applications. The AVX application FLOPS estimate might be somewhat correct for CPU tasks, but it falls down on the Lunatics optimized apps and most certainly, bears no resemblance to any of the GPU apps.

---

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

A proud member of the OFA (Old Farts Association)

By this system, GPUs are considered extremely inefficient because their claimed FLOPS rating is much more than the estimated FLOPs when processing a WU

I believe that the "Sanity Checking", "Cheat Prevention" and "Cherry Picking" parts of CreditNew are partly to blame for the reduced credits. The mechanisms believe that the real flops of a gpu is the result of a cheat or cherry picking scenario and the credits being reduced to what they believe the normalized fpops estimate should be.

The CreditNew algorithm can't comprehend the exponential increase in processing power performance of modern gpu's that has occurred since the algorithm was created.

---

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

A proud member of the OFA (Old Farts Association)

I not see any credit complains on E@H who uses a fix credit per WU crunched.

Very easy there, as you know each WU on a given host has the same run time.

???
I only do GPU work there, but I see a tremendous variation in runtime for that same 3450 points, anywhere from 3-4 minutes to as much as 30.
I turned off CPU work, as I very seldom run out of SETI CPU tasks.
But I don't care for the fixed approach, given the variations I see.

I assume the 30 minute tasks are by the 750Ti??? Certainly not from the 980's.

Yeah, due to power and real estate constraints I have a mix of 1 750ti and 1 or 2 980s in each machine.
But I think I've taken that into consideration in the statement I made ... perhaps i should look again.

---

I take it for granted, that they fixed or killed CreditScrew, during this extra long outage.
Hehe.....
LOL

MeowLOL.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Credits per hour on my Computer by project (plus or minus 10%)
Seti was calculated using BLC02...vlars

...510cr/hr ----- Seti@home - (Using 1 CPU & 1 GPU) Credit new
...600cr/hr ----- Skynet POGS - (Using 3 CPUs Only) Credit new, I think
.3,500cr/hr ----- Milkyway - (Using 1 CPU & 1 GPU) Set Credit/WU
15,200cr/hr ----- Einstein - (Using .5 GPU and .5 GPU) Set Credit/WU

I know its not Seti's fault or problem but if I want to share work with all the above projects simply using a straight credit value is no use at all. I would have use the above numbers as factors and that would work until WU were changes and the value and time for them changed, then you would have to recalculate it all over again once you have ran enough WUs for a benchmark.

Some form of consistency within and then across projects would be awesome.

My 2 cents

Bob

---

Sometimes I wonder, what happened to all the people I gave directions to?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SETI@home classic workunits 4,321
SETI@home classic CPU time 22,169 hours

Some form of consistency within and then across projects would be awesome.

My 2 cents

Bob

I would be more than pleased just to have it consistent within Seti's own borders.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Some form of consistency within and then across projects would be awesome.

My 2 cents

Bob

I would be more than pleased just to have it consistent within Seti's own borders.

+1