Jose please don't rehash discussions which have already took place and in which all arguments have been presented. This applies to an optimized application for the Altivec architecture.

Please don't accuse people of readdressing the backdating discussion, when they point out inaccuracies in the presented RAC or some other facts.

Please don't restate that you and your team felt treated badly, that you feel angry and that you are now biased against the project and certain participants. That has been stated several times already.

If you don't stop posting only negative comments about the project and its decision I will delete any further post from you without explanations.

---

I am a forum moderator! Am I?

Jose please don't rehash discussions which have already took place and in which all arguments have been presented. This applies to an optimized application for the Altivec architecture.

Please don't accuse people of readdressing the backdating discussion, when they point out inaccuracies in the presented RAC or some other facts.

Please don't restate that you and your team felt treated badly, that you feel angry and that you are now biased against the project and certain participants. That has been stated several times already.

If you don't stop posting only negative comments about the project and its decision I will delete any further post from you without explanations.

I have participated in a very calm and reasonable dialogue with Mats, tralala and Norbert regarding the issue of fairness in the credit systems when it comes to certain cpus and certain OS and some improvements that could be made to make the projects more attractive.

When it was pointed out to me that my bias may be showing, I admitted it, plain and simple. So I am not rehashing anything.

As to power to delete, you have it and you have used it

So are you arguing for optimizers?

No. I think the ideal solution is "pay per work", which is what Rosetta has implemented a variation of.

The generic BOINC solution certaily has flaws - it doesn't take into account factors such as cache-size (because the benchmark nicely fits in even the smallest of caches, both Whetstone and Dhrystone will fit in 16KB of cache quite easily), optimization level of the actual project executable[1] (BOINC is a different build from the project executable, so it will most likely have a different set of optimization), memory speed (in relevant cases where the application + its data doesn't fit entirely in the cache), etc, etc.

Equal pay for equal work is the right way to go. If a user can produce X results, then it's worth Y credits. Someone else producing 2X results should get 2Y credits. How you got the actual results shouldn't make any difference - using two processors, using a faster project executable (compiled with more optimization levels), having a faster processor or using "the right operating system" [assuming Linux clients actually DO calculate slower than the Windows client of the same project, then Windows clients should get more credit - but not if it's only the benchmark that runs faster!]

[1]The rosetta, SETI or Einstein executable, rather than the BOINC.EXE application that does the benchmark.

--
Mats

---

So are you arguing for optimizers?

No. I think the ideal solution is "pay per work", which is what Rosetta has implemented a variation of.

The generic BOINC solution certainly has flaws - it doesn't take into account factors such as cache-size (because the benchmark nicely fits in even the smallest of caches, both Whetstone and Dhrystone will fit in 16KB of cache quite easily), optimization level of the actual project executable[1] (BOINC is a different build from the project executable, so it will most likely have a different set of optimization), memory speed (in relevant cases where the application + its data doesn't fit entirely in the cache), etc, etc.

Equal pay for equal work is the right way to go. If a user can produce X results, then it's worth Y credits. Someone else producing 2X results should get 2Y credits. How you got the actual results shouldn't make any difference - using two processors, using a faster project executable (compiled with more optimization levels), having a faster processor or using "the right operating system" [assuming Linux clients actually DO calculate slower than the Windows client of the same project, then Windows clients should get more credit - but not if it's only the benchmark that runs faster!]

[1]The Rosetta, SETI or Einstein executable, rather than the BOINC.EXE application that does the benchmark.

--
Mats

Ty.

So am I right then that one of the issues left to solve is reflected in your statement "[assuming Linux clients actually DO calculate slower than the Windows client of the same project, then Windows clients should get more credit - but not if it's only the benchmark that runs faster!]" ?

Is there a way to prove if Linux does indeed calculate work units slower than windows and that the problem is not in the "benchmarks calculation/computation"?

Re benchmarks: What is your position on the fact that participants can re calculate their benchmarks at will ( thus they can manipulate their rig in ways that can result in higher benchmarks)? Doesn't this affect the credit granting?

Is there a way to prove if Linux does indeed calculate work units slower than windows?

Yes, it's quite easy. Run the SAME work on a Windows and Linux machine, and compare the amount of time it takes... However, Rosetta makes this a bit difficult, since Rosetta WU's do not run a set amount of work, but rather a set amount of time. In this case, the best way to compare is "credit per core per GHz", which I've posted in the "Credit per hour" discussion. I can say that Rosetta doesn't seem to be noticably slower/faster on Linux than on Windows.

I haven't done comparisons on other projects...

--
Mats

---

Is there a way to prove if Linux does indeed calculate work units slower than windows?

Yes, it's quite easy. Run the SAME work on a Windows and Linux machine, and compare the amount of time it takes... However, Rosetta makes this a bit difficult, since Rosetta WU's do not run a set amount of work, but rather a set amount of time. In this case, the best way to compare is "credit per core per GHz", which I've posted in the "Credit per hour" discussion. I can say that Rosetta doesn't seem to be noticably slower/faster on Linux than on Windows.

I haven't done comparisons on other projects...

--
Mats

So if you were to have a large sampling of work units you could do a stats analysis to see if the Linux issue is an urban legend or fact.

Define "noticeably" :) .

I will be out for a while. I am going to do something that noticeably slows my life's time continuum : a visit to the dentist [Haven't you notice that time slows down a lot when you visit a dentist but goes so fast when eating an Ice Cream?] . I will keep this very interesting dialogue when I come back.


Pax

Is there a way to prove if Linux does indeed calculate work units slower than windows?

Yes, it's quite easy. Run the SAME work on a Windows and Linux machine, and compare the amount of time it takes... However, Rosetta makes this a bit difficult, since Rosetta WU's do not run a set amount of work, but rather a set amount of time. In this case, the best way to compare is "credit per core per GHz", which I've posted in the "Credit per hour" discussion. I can say that Rosetta doesn't seem to be noticably slower/faster on Linux than on Windows.

I haven't done comparisons on other projects...

--
Mats

So if you were to have a large sampling of work units you could do a stats analysis to see if the Linux issue is an urban legend or fact.

Define "noticably" :) .

Linux clients were disadvantaged with the old credit system since the BOINC benchmark ran slower under Linux. They are no longer disadvantaged with the new credit system since they do crunch the same amount as windows boxes and thus receive the same credit (true for Rosetta, not necessarily for all projects).

This was all discussed and pointed out several times, you should spend more time reading posts and less writing.

Linux clients were disadvantaged with the old credit system since the BOINC benchmark ran slower under Linux. They are no longer disadvantaged with the new credit system since they do crunch the same amount as windows boxes and thus receive the same credit (true for Rosetta, not necessarily for all projects).

This was all discussed and pointed out several times, you should spend more time reading posts and less writing.

Point well taken. I will do that when I come back from the dentist.

Ah but my friend tralala...how about that nice and desirable Cross Boinc Parity? Shouldn't we be striving for a systems where linux recieves the same amount of credits across Boinc projects?

Or was I wrong in reading that itr has been argued Cross Boinc Parity is an integral part of a fair credit system?

Again: I will do the homework and read.

It is to the dentist I go.

Pax

Linux clients were disadvantaged with the old credit system since the BOINC benchmark ran slower under Linux. They are no longer disadvantaged with the new credit system since they do crunch the same amount as windows boxes and thus receive the same credit (true for Rosetta, not necessarily for all projects).

This was all discussed and pointed out several times, you should spend more time reading posts and less writing.

Point well taken. I will do that when I come back from the dentist.

Ah but my friend tralala...how about that nice and desirable Cross Boinc Parity? Shouldn't we be striving for a systems where linux recieves the same amount of credits across Boinc projects?

Or was I wrong in reading that itr has been argued Cross Boinc Parity is an integral part of a fair credit system?

Again: I will do the homework and read.

It is to the dentist I go.

Pax

Cross Boinc Parity is about the average granted credit being similar in all BOINC projects, which means a comparable set of different computers should receive similar credits/hour on project a and project b. That does not mean that each box should receive the same. If it happens, that application a runs very slow on IBM-Macs it should receive less credit than on project b, which for example has a ALTIVEC-optimized app. The same is true for Linux: if Linux and Windows perform the same on project A they should receive the same credit, but if Linux performs worse on Project B compared to Windows it should receive less credit. so it does not violate Cross Boinc Parity if a specific OS or CPU-type receives different credits/hour on different projects. To keep Cross Boinc Parity however one should adjust the average credits/work over all hosts to comparable values.

Btw. I don't think Cross Boinc Parity is an integral part of a fair credit system and I don't remember anyone stating such a thing. The basic rule for a fair credit system is that you receive same credits for same work across all hosts and independent from which OS or BOINC client you use (multiplying the granted credits by 10 on Rosetta would not make it an unfair system). Cross Boinc Parity is independently from a fair credit system a good think, as I explained here.

How are your teeth?

I averaged all the results turned in for the week that's visible in the results for a number of machines
here..

P4s were getting between 1.6-1.86 times their old credit numbers; while a P4 with HT on got 1.98 times the old credit numbers. My Athlon 64 2Ghz cpu got a speed up of around 1.15.

It's interesting to see the change in the graphs when a system runs the benchmarks in the middle of the graph.

David Kim's mac was getting 0.545 times the old credit numbers; while older Macs were getting in the 0.30 range.

Dave Wilson's systems were running optimized clients so the results can't directly compare to the standard client. About 0.26 for the PPC machines and 0.15 for the other machines.

The Linux issue seemed taken care of; as did the P4 vs AMD issue.

This was done with a small sample size of all the week's results from 1 to 4 machines of each type.

---

Jose, glad to see you back posting regularly. Are you saying your house was hit by lightening?? YICKS! I had 74MPH winds at my place 2 weeks ago... am still cleaning up sticks, branches and trees that aren't where they should be.

I for one, wish you would stop with the taunting, but am glad to see them passing under the bridge. If you have some specific situations where the new credit system doesn't work, that is what this thread is for. But you seem to be making vague assertions, especially about Linux and Mac, and as such they feel more like bait then offering any new information or perspective on the credit system.

As for taking an informative perspective, it sounds like you feel a Mac should be given more credit per model then other systems... apparently you take that perspective because Rosetta's compiled code does not take full advantage of the hardware available on the Mac. And so you seem to be saying that it's not the contributor's fault that they didn't produce more useful work to the project. And that's certainly true. But it's not how the credit system works. It doesn't grant credit based on the work your machine could have done. It grants credit for actual work that is done.

So, to answer your question, yes, Macs would be much closer to parity if a better optimizing compiler were found that would produce executables which can run on any Mac, and take full advantage of available hardware. If that were done, then Macs would receive more credit per hour then they do now. Because they'd get more models crunched. Do you have a compiler to recommend to the Rosetta team that will accomplish that? You mentioned "client". So I wanted to be clear, it's not the BOINC client that needs optimization to help Macs. The BOINC client is running <1% of the time. It is the Rosetta application that would require change.

I take it you are now clear on the RAC decay deal. That if someone was running at a RAC of 500 and then stops running Rosetta altogether, they're RAC will still show 500, even though they are no longer crunching anything. The RAC expiry simply refreshes the RAC figure, even when the host has not been reporting in with any new results. Implementing RAC expiry simply causes the RAC to reflect such a lack of reported results.

[deep breath, check for type-o's, reread to avoid imflamatory or overly emotional statements... POST REPLY]

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

David Kim mentioned that he turned the RAC decay feature on. It will be running once per week:

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=2219#25556

However I'm not sure whether it will run automatically or whether David Kim has to run it each time manually. It seems to me after the one run 8 days ago it did not run another time.

It's being run once a week as a task and has run twice so far according to the logs. Is it not working as it should?

David Kim mentioned that he turned the RAC decay feature on. It will be running once per week:

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=2219#25556

However I'm not sure whether it will run automatically or whether David Kim has to run it each time manually. It seems to me after the one run 8 days ago it did not run another time.

It's being run once a week as a task and has run twice so far according to the logs. Is it not working as it should?

Well, I was wondering about this host which has not reported back any results for 10 days but still has a high RAC. However it probably had such a high RAC that it is falling only slowly. Well I will watch this host and if in a week the RAC is the same I'll report back.

1-

Jose, But you seem to be making vague assertions, especially about Linux and Mac, and as such they feel more like bait then offering any new information or perspective on the credit system.

Thanks for allowing me the opportunity to make some points clear.

I am not baiting anyone re Linux or Power Macs. All I am asking is for clarification on the often repeated issue that Power Macs and rigs that are run under Linux get short changed in the credit area. In order to do that i have engaged in a very civil dialogue with tralala, Norbert and Mats about that issue.

As part of that dialogue, Mat made the following statement: "I can say that Rosetta doesn't seem to be noticeably slower/faster on Linux than on Windows. ". I asked for a definition regarding what he considered noticeably, specially when I think he meant to say " there were no statistically significant differences ". To me there are very important differences in noticeable (as that is a subjective term) and statistically significant ( that is objective).

In other words, I would like to see the issue of Linux vs Windows put to rest which is not the same as seemingly put to rest. If the under crediting claim is an urban legend , so be it and let's move on. If it is not, I would like to see a solution found.

It has been argued that a fair credit system would help attract more crunchers in to the projects. I would argue that a system that allows for a more efficient use of a type of machine or a type of OS would encourage more people to participate in a project.

More people in projects , more science done. Can we agree on that?


2- As to the accusations I do baiting . Again that is an issue of perspective. I would say I use the Socratic Method. :) But, I digress.

3-

So, to answer your question, yes, Macs would be much closer to parity if a better optimizing compiler were found that would produce executable which can run on any Mac, and take full advantage of available hardware. If that were done, then Macs would receive more credit per hour then they do now. Because they'd get more models crunched. Do you have a compiler to recommend to the Rosetta team that will accomplish that? You mentioned "client". So I wanted to be clear, it's not the BOINC client that needs optimization to help Macs. The BOINC client is running <1% of the time. It is the Rosetta application that would require change.

Then the Rosetta application and another applications that uses BOINC that has the same problem with the way Power Macs are used should be changed.

I know what type of Benchmarks Power Macs can have, because I reviewed Power Macs credits under the old system. And, I know what type of credits they were getting. I know the applications do not use their potential more efficiently. I only would like to see that change so more people with power macs feel encouraged to join.

Again more people crunching more science.

I think I do not need to recommend a compiler for the Power Mac. The fact is the developers know what is needed to be used . They have talked about the "optimizer" that could solve the problem. They know.



4-

I take it you are now clear on the RAC decay deal. That if someone was running at a RAC of 500 and then stops running Rosetta altogether, they're RAC will still show 500, even though they are no longer crunching anything. The RAC expiry simply refreshes the RAC figure, even when the host has not been reporting in with any new results. Implementing RAC expiry simply causes the RAC to reflect such a lack of reported results.

I have no problem with that. What I did take issue with was the statement that was not being done when it has been done. I will not revisit the person's posts but a fair reading of the first one , basically states that RAC expiry was not being done . The Second post by that person included the data that showed that his first claim that RAC expiry feature was not used was not a factual statement.

I also pointed out that in one case in particular the person whose top RAC was being questioned is still reporting new results ; not as many as before , but still new results. That, is a verifiable fact

That is when I allowed my bias and overt dislike for that person to take over. ( My fault) and that is when tralala correctly pointed out that fact: that I was letting my bias against the person in question speak. Instead of accepting the truth of tralala's admonition, I explained in a very particular way HOW much bias and dislike I had and that brought the intervention of the moderator and the rest is history.

SO I will follow your advice

[deep breath, check for type-o's, reread to avoid inflammatory or overly emotional statements... POST REPLY]

to which I will add : allow the pain killers the dentist gave you (as in Me, José) to take effect and then go and do what I promised : read.

David Kim mentioned that he turned the RAC decay feature on. It will be running once per week:

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=2219#25556

However I'm not sure whether it will run automatically or whether David Kim has to run it each time manually. It seems to me after the one run 8 days ago it did not run another time.

It's being run once a week as a task and has run twice so far according to the logs. Is it not working as it should?

Well, I was wondering about this host which has not reported back any results for 10 days but still has a high RAC. However it probably had such a high RAC that it is falling only slowly. Well I will watch this host and if in a week the RAC is the same I'll report back.

Could it be possible that you contact me at joseantonioATchoicecableDOTnet?

Jose, from what I know about painkillers, once they take full effect, you'll probably be asleep :)

Yes, I agree, more Mac contributors the better. And I read posts from one that was very upset that they now receive less credit then they used to, and felt R@H was only using 1/3rd of their machine. So, I think this point has been made. And I've not heard anyone assert that improvements to the Mac executable for Rosetta would not be desirable.

So, how does this pertain to the new credit system? Allow me to answer my own question. The new credit system reflects the lack of optimizations in the Rosetta programs that run on a Mac, and therefore, a Mac user may be more inclined to run other BOINC projects... at least until the issue can be addressed.

...so beyond that, are you asserting that Mac should be granted more credit until such changes could be made?

As for Linux, since Linux and Windows can run on the same physical hardware, it is one of the few places you can really get a good feel for any discrepencies in the credit system. And from what I'm reading, Linux systems used to receive low credit for the work they produced. And under the new system they are now on par with Windows. So it's hard to call it an urban legend. My understanding is that it would be more accurate to say that it used to be a problem, and the new credit system has resolved it. I believe that issue has already been put to rest.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Well, I was wondering about this host which has not reported back any results for 10 days but still has a high RAC. However it probably had such a high RAC that it is falling only slowly. Well I will watch this host and if in a week the RAC is the same I'll report back.

Some of the BOINC-stats-sites uses the info in stats-dumps to re-calculate the RAC themselves, since not all projects is routinely updating the RAC except then results validated. Atleast BoincStats does not re-calculate RAC themselves, but only relies on the projects doing the job...

A quick look on BoincSynergy that does re-calculate RAC themselves, reveals that this host has RAC of 1.1k.

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

It's being run once a week as a task and has run twice so far according to the logs. Is it not working as it should?

It seems to work fine Dr. Kim. I was unaware it was and was posting a request for it's use. Thanks

tony

P.S Sorry, it seems anything I say or post stirs up some poster/s here.

From my example of the top 40 participants by rac, you can see something is happening. knowing it's being run once a week/so answers my question

Jose, from what I know about painkillers, once they take full effect, you'll probably be asleep :)

Yes, I agree, more Mac contributors the better. And I read posts from one that was very upset that they now receive less credit then they used to, and felt R@H was only using 1/3rd of their machine. So, I think this point has been made. And I've not heard anyone assert that improvements to the Mac executable for Rosetta would not be desirable.

So, how does this pertain to the new credit system? Allow me to answer my own question. The new credit system reflects the lack of optimizations in the Rosetta programs that run on a Mac, and therefore, a Mac user may be more inclined to run other BOINC projects... at least until the issue can be addressed.

...so beyond that, are you asserting that Mac should be granted more credit until such changes could be made?

As for Linux, since Linux and Windows can run on the same physical hardware, it is one of the few places you can really get a good feel for any discrepancies in the credit system. And from what I'm reading, Linux systems used to receive low credit for the work they produced. And under the new system they are now on par with Windows. So it's hard to call it an urban legend. My understanding is that it would be more accurate to say that it used to be a problem, and the new credit system has resolved it. I believe that issue has already been put to rest.

I believe the optimization that is required and is known to solve the Mac issue should be implemented .

To be honest with you, I don't think the Linux issue has been resolved. As long as the perception that the current credit system still under evaluate the performance under Linux persists , the issue is there . Perception is many times more powerful than reality and that is why I would like to see reality and perception to be one and the same.

I wish I know how to put an end to that. That is why I would like to see a complete statistical analysis of the issue.

Just in case: I do not do Linux ( too complicated for me ) and I do not belong to the Mac cult. :) I just don't like small sample statistics and conclusions based on small sample statistics. I don't like the use of " it seems to have been solved " in lieu of " it has been solved " . The compliance auditor that still lurks in me is trying to get answers.

Alas it seems that my search for answers in an attempt to find solutions irritate some people. Worst, there are some people that do not understand why , if I left the project, I am still trying to look for answers. That is too complicated to answer here.

Self-Exile , even though justified , is a weird state of being. Suffice to say I cared about this project and I do still care.

That said. I think I should stop bothering this thread and let all that want and or care still look for answers and ways to make the system fair and to make the system attractive to all kind and type of crunchers. (Alas something that is not now.) keep doing their work.

Pax

Thanks Tony. I don't have a phd. DK, David or Dave is what I'm used to.