I think I have an ant in my pants and it bugs me.:)......... But don't kick Me there to help Me.

[sarcasm]
Maybe the projects who give to much credit can make a slow official app which claim lower credit and make it open course so third party optimized apps can be created to crunch the units faster.
[/sarcasm]

My point is: Seti should not allow third party apps to inflate the output.
And
At the same time compare other official project apps with the official Seti app who's claiming to give a standard credit.

Yes I also run optimized apps and I like them but I think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

The optimized Seti apps don't inflate anything, WU for WU all they do is do work faster and per WU they claim the same amount of credit as any other would as long as their paired with a Boinc Client that does flop counting(5.2.6 and Newer) and not benchmarking(5.2.5 and earlier claim less per WU than is normal and acceptable).

Sorry for the delay
And thank you for the spelling corrections in my previous post (now we can both understand what i've wrote)

According my own simplistic twisted mind and logic.

Let Me explain with an example:
For the sake of argument cpu_sec/credits 1:1

Golden@home cpu_sec/wu 100 credits/wu 105...... (ultra optimized official app)
Sneaky@home cpu_sec/wu 100 credits/wu 90...... (official app with waisting time loop)
So far so good Sneaky@home get less credit for the same cpu time.

But Sneaky cant be sneaky if it claims less credit, so to honor his project name it release the course code to the pubic.
Peeky the Poke looks at the code and find this yelling "remove me to improve me" waisting_loop.... compilles it and an non official optimized app who decrease the cpu time with 50%.is born.
Peeky the Poke proudly present his new born unofficial Sneaky@home app to the users.
Happy Chap now crunch with the optimized app and.....and....and.... Hey i crunch the same unit and have the right to get the same credit/wu like the official app granted credit/wu
.
Look out here it commes.....no...no...no...not this song about the man eater

Yummy, yummy... now Sneaky@home gets 90 credits for 50 cpu_sec/wu with other words 180 credits for 100 cpu_sec.

Now I invite you to pull one of my twisted logic strings.to show Sneaky@home unofficial app isn't inflating the credits.(not intentionally I must admid)

AAuuuuwww my brain hurts.
And i still have to read the things msattler wrote

I think I have an ant in my pants and it bugs me.:)......... But don't kick Me there to help Me.

[sarcasm]
Maybe the projects who give to much credit can make a slow official app which claim lower credit and make it open course so third party optimized apps can be created to crunch the units faster.
[/sarcasm]

My point is: Seti should not allow third party apps to inflate the output.
And
At the same time compare other official project apps with the official Seti app who's claiming to give a standard credit.

Yes I also run optimized apps and I like them but I think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

The optimized Seti apps don't inflate anything, WU for WU all they do is do work faster and per WU they claim the same amount of credit as any other would as long as their paired with a Boinc Client that does flop counting(5.2.6 and Newer) and not benchmarking(5.2.5 and earlier claim less per WU than is normal and acceptable).

Sorry for the delay
And thank you for the spelling corrections in my previous post (now we can both understand what i've wrote)

According my own simplistic twisted mind and logic.

Let Me explain with an example:
For the sake of argument cpu_sec/credits 1:1

Golden@home cpu_sec/wu 100 credits/wu 105...... (ultra optimized official app)
Sneaky@home cpu_sec/wu 100 credits/wu 90...... (official app with waisting time loop)
So far so good Sneaky@home get less credit for the same cpu time.

But Sneaky cant be sneaky if it claims less credit, so to honor his project name it release the course code to the pubic.
Peek the Poke looks at the code and find this yelling "remove me to improve me" waisting_loop.... compiles it and an non official optimized app who decrease the cpu time with 50%.is born.
Peeky the Poke proudly present his new born unofficial Sneaky@home app to the users.
Happy Chap now crunch with the optimized app and.....and....and.... Hey i crunch the same unit and have the right to get the same credit/wu like the official app granted credit/wu
.
Look out here it comes.....no...no...no...not this song about the man eater

Yummy, yummy... now Sneaky@home gets 90 credits for 50 cpu_sec/wu with other words 180 credits for 100 cpu_sec.

Now I invite you to pull one of my twisted logic strings.to show Sneaky@home unofficial app isn't inflating the credits.(not intentionally I must admit)

AAuuuuwww my brain hurts.
And i still have to read the things msattler wrote

Well all things said, An Optimized app just does the work faster without skipping any part of the work and the Optimized apps will not inflate a result as long as the optimized app in question uses the same multiplier as the stock app which is 2.85 at the moment and the optimized apps that use the 2.85 multiplier are the 2.4(Chicken) or 2.4V(Crunch3r) apps and barring problems in ones hardware or server problems at Berkeley they do make valid results, Just faster thats all, If the optimized apps didn't make valid results no one would use them. The only users who under claim are using outdated Boinc Clients and has nothing to do with the Seti app as one could underclaim and still use either the stock 5.27 stock app or the Optimized apps, Which I won't get into as that has been talked about in some other thread a lot.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Thank you for the answer

I think I have an ant in my pants and it bugs me.:)......... But don't kick Me there to help Me.

[sarcasm]
Maybe the projects who give to much credit can make a slow official app which claim lower credit and make it open course so third party optimized apps can be created to crunch the units faster.
[/sarcasm]

My point is: Seti should not allow third party apps to inflate the output.
And
At the same time compare other official project apps with the official Seti app who's claiming to give a standard credit.

Yes I also run optimized apps and I like them but I think Seti should implement this code in a official app like Einstein@home did.
Or use the Seti optimized app credits to compare between projects.

The optimized Seti apps don't inflate anything, WU for WU all they do is do work faster and per WU they claim the same amount of credit as any other would as long as their paired with a Boinc Client that does flop counting(5.2.6 and Newer) and not benchmarking(5.2.5 and earlier claim less per WU than is normal and acceptable).

Sorry for the delay
And thank you for the spelling corrections in my previous post (now we can both understand what i've wrote)

According my own simplistic twisted mind and logic.

Let Me explain with an example:
For the sake of argument cpu_sec/credits 1:1

Golden@home cpu_sec/wu 100 credits/wu 105...... (ultra optimized official app)
Sneaky@home cpu_sec/wu 100 credits/wu 90...... (official app with waisting time loop)
So far so good Sneaky@home get less credit for the same cpu time.

But Sneaky cant be sneaky if it claims less credit, so to honor his project name it release the course code to the pubic.
Peeky the Poke looks at the code and find this yelling "remove me to improve me" waisting_loop.... compilles it and an non official optimized app who decrease the cpu time with 50%.is born.
Peeky the Poke proudly present his new born unofficial Sneaky@home app to the users.
Happy Chap now crunch with the optimized app and.....and....and.... Hey i crunch the same unit and have the right to get the same credit/wu like the official app granted credit/wu
.
Look out here it commes.....no...no...no...not this song about the man eater

Yummy, yummy... now Sneaky@home gets 90 credits for 50 cpu_sec/wu with other words 180 credits for 100 cpu_sec.

Now I invite you to pull one of my twisted logic strings.to show Sneaky@home unofficial app isn't inflating the credits.(not intentionally I must admid)

AAuuuuwww my brain hurts.
And i still have to read the things msattler wrote

First, let me give an oversimplified example.

Lets' say you have a calculation X=N*2.

A multiply instruction takes 10 clock cycles, so doing this takes 10 clocks.

If you do X=N+N, that gives the same result, but an "add" only takes 3 clocks.

Since 2 is a constant and an even multiple of 2, I know that X=N*2 is the same as X=N<<1 (a left shift one position).

Shift only takes one clock.

If the original program said "X=N*2" and I make a new science app. with X=N<<1, my new client will run faster.

... but the work done is exactly the same.

If you use the original science app. and get 50 credits, and I use my new very fast science app. and crunch the same work with the same result, shouldn't I get 50 credits?

I'm working faster because my client is smarter, but isn't working smarter good, shouldn't it be rewarded??

(For the potential critics: yes, I know, an optimizing compiler will take the same optimization -- I'm talking about the concept).

Note that this doesn't use delay loops to "slow down" a standard app. It just picks more efficient equivalent instructions. It also doesn't depend on any form of SSE or any of the other tricks that are processor specific. This will be true at some level on every chip.

This was not the issue that the original poster complained about: his argument is that an hour of processing should give the same credit regardless of which project is being crunched. I agree with that.

He went on to say that an hour of SETI gives less credit than any other project he crunches, therefore SETI is wrong in their credit calculations -- without looking at how SETI grants credit, and what the standard should be.

---

...
I agree with you when you say that an hour of SETI and an hour of Tanpaku should grant the same credit.

Where we part company is when you say "SETI pays the lowest, so they should fix it." I say, "There is a standard, and every project should follow the documented standard."
...

Interestingly, for the 3503 hosts crunching both SETI and TANPAKU, the average credit/time rate is within 2%. See the cross-project credit rate comparison page. Given that nearly equal value, there's no reason either project should make a change.

It has been noted many times that certain kinds of systems do better on some projects than others, and those competing in some credit race should certainly choose the projects which best match their systems.

                                                                Joe

...
I agree with you when you say that an hour of SETI and an hour of Tanpaku should grant the same credit.

Where we part company is when you say "SETI pays the lowest, so they should fix it." I say, "There is a standard, and every project should follow the documented standard."
...

Interestingly, for the 3503 hosts crunching both SETI and TANPAKU, the average credit/time rate is within 2%. See the cross-project credit rate comparison page. Given that nearly equal value, there's no reason either project should make a change.

It has been noted many times that certain kinds of systems do better on some projects than others, and those competing in some credit race should certainly choose the projects which best match their systems.

                                                                Joe

I've looked at TANPAKU in the past and checked it again a few minutes ago.

What I looked at in particular were hosts crunching with the same E6600 that I have for a comparison.

After looking at several of the E6600's on TANPAKU I found that they don't 'pay' as well as many other projects including SETI, something in the area of 250 - 300 seconds for a credit.

That is a significantly higher crunch time per credit than my E6600 on SETI on good angles at ~100 seconds for a credit, and even on the low paying angles (~150 seconds for a credit).

---