I have always chosen my operating system according to which one is more efficient on my project of choice since I started my first Boinc project 3 years ago. Although this affects credit rate the main reason for this is science/watt. This meant that I used Windows for many years when crunching Climate Prediction, even though Linux was my OS of choice. To do otherwise would be unnecessarily spending extra on electricity/carbon.
This is just my personal view and not any implied criticism of anyone's choice of operating system. I was even about to switch to FreeBSD at one stage because it was reported to be more efficient on a project I was crunching at the time. Luckily for me a Belgian person tried it first and found out that it was not more efficient than 64-bit Linux.
If this is about the significant difference between the Linux and Windows apps running on the same hardware (dual boot), then how can you possibly advocate cross-project parity? If your statement is about this gripe of mine, bear in mind that it is a gripe of others as well and is something that Bernd sees as a deficiency. If Bernd corrects the issue, even if it is to only within some sort of reasonable difference (within 5%), I'll shut up about it... Tony's research some time ago showed that there was a 20% gap... That is a very substantial penalty simply based on the OS. If we're not going to care about those things and/or minimize the viewpoint of those who see it as an issue, then nobody should be worrying about "cross-project parity" at all...because then it becomes "if it is not impacting me, I don't care".
I agree with you. About the only way I can see this with all other projects out of the picture and ONLY looking at einstein@home with the disparity of work done is: (fictional of course but gets to the point)
Example:
I have two computers that are exactly alike with all hardware, running time, etc EXCEPT that computer A (mine) runs linux and computer B (wife's) runs windows. My computer does 10 wu's a day and the wife's computer does 7 or 8 (if the disparity is 20%) We both are running einstein because it is a project that is of great importance to both of us in our related fields. Also assume there is a bit of competition between both of us on who gets more credits and processes the most work.
I'm thrilled to death because since I am running linux I am able to do more work, thus receive more credit than the wife can. The wife mean while is upset because even though she receives the same amount of credit per workunit I do, since she uses windows she can't complete as much work in the same amount of time that I can. Let's also assume that in our daily jobs I use linux for all my work and rarely see or use a windows machine. The same is true for the wife as well except that she uses a windows computer. I use linux on my system at home because that is what I am used to and I can get around a lot easier than if I were trying to figure out how to do something in windows. The same holds true for the wife, yet she is still upset that all things being equal she is unable to do the same amount of einstein@home work as I do and she's losing ground on the credit totals. Neither of us has any desire to change from our comfort zone with the OS we use. Either of us telling the other that if they want to compete then they should change to the other OS so things would be on a equal basis is ridiculous! Why should either one of us be penalized because of our choice?
Now let's bring this into a longer time frame. In the beginning I tell the wife that the reason there's a difference is because einstein's client has a problem being compiled with the MS libraries and that einstein@home is working on a solution that "might" get it where there is very little difference. Enough so that the little bit of difference really isn't going to make either of us feel like we are taking advantage of the other in work or credits or being penalized. This is fine in the beginning and it seems to sooth things over for a while. In the meantime einstein comes out with a optimized clients for both OS's. My computer with linux gets even faster, but so does the wife's computer and still hearing that they are going to do more for the windows clients she's happy that the difference isn't as great as it was before and she's happy for the time being. Life is good at home.
Now the project ends one run and begins a new one. With the new project both OS's receive a new client. Both are expecting things to even out more or less within reason. Suddenly there's even greater disparity since the new client for linux has incorperated the optimizations that made it more efficient while the windows client goes back to where it was in the beginning. Once again I try to explain why the windows client is falling behind, but that they will do something to make it more equitable as soon as things settle down after the change over. Life at home is getting strained!
To bring all this into perspective within the larger boinc community, take this senario and have the same thing happening within all the other projects. If you can't make it fair within your own project how in the heck can you try to make it equal with every project?
Now the project ends one run and begins a new one. With the new project both OS's receive a new client. Both are expecting things to even out more or less within reason. Suddenly there's even greater disparity since the new client for linux has incorperated the optimizations that made it more efficient while the windows client goes back to where it was in the beginning.
Hi!
There must be a misunderstanding, because for both Windows and Linux, (and OSX..) the most powerful versions (beta / poweruser app) from the S5R3 run were made the stock app for S5R4. There was no step back for Windows.
"[AF>Futura Sciences]click" has made a nice chart comparing app performance over the past months, if you allow 3% error margin you'll see that app performance did not change between S5R4 and S5R3.
There must be a misunderstanding, because for both Windows and Linux, (and OSX..) the most powerful versions (beta / poweruser app) from the S5R3 run were made the stock app for S5R4. There was no step back for Windows.
Your probably right in there is a misunderstanding. I thought I read in Brian's message Message ID 86418 in this thread where the linux release has the SSE2 optimizations whereas the windows release only had SSE and that was the reason for the differences. As I don't use linux I've had to rely on what I have read on the boards.
I've had to assume, maybe incorrectly, that the difference between the stock windows app and the optimized one for the last run was about 40%. On my systems that seems to have been a pretty close aprox. With the change over I'm back where I started at with the last run. I attribulated that to the lack of the SSE2 optimizations. I could be and probably am wrong. I do know that before I started using the optimized client on the last run work unit times here were about 13 hrs. After switching to the optimized client it went to aprox 6 to 7 hrs depending on where I was in the high/low cycle of the run. Now I have the new app and I'm back to 13 to 14 hours. "Bernd has said that there will be an attempt to rectify that situation" with the discrepancies between clients and that's all I have to go on.
Aside from that point I think the overall argument in my example still holds true. It's hard enough to have a level playing field within one project, whether or not it is between optimized clients or optimized vs. standard applications much less trying to level the playing field between projects.
[edit] My example was just that. My wife could care less what boinc project I run on her computer as long as it isn't CPDN since it hogs most of her memory and drags the system to a crawl.[/edit]
There really does seem to be something odd going here, and I'm not surprised people are getting confused.
There are different apps:
For Windows, there are two: without SSE, and with SSE
For Linux, there are three: without SSE, with SSE, and with SSE2
The chart posted by [AF>Futura Sciences]click shows very clearly that, like for like, the application speed for R4 is very close to the application speed for R3. In fact, I'd go further: for the "best" app (SSE on Windows, SSE2 on Linux), it's almost identical. The "second best" apps (non-SSE on Windows, SSE on Linux) have improved significantly. The only one which has gone backwards is non-SSE on Linux. Edit - and for AMD-Linux, there is negligable difference between SSE and SSE2.
That's from the chart, which says it's been run on an AMD XP3800+. It would be nice if someone with a dual-boot Intel could draw up an equivalent chart (sorry, I'm Windows-only here).
But that's for the reference WU. What I am seeing (and I suspect others are too) is a big change in the runtime for the real-world tasks which are being issued. That's true of both the windows _1 application which this SSE2 machine is running, and the windows _0 application which my Celeron MMX machine is running.
I'm afraid I don't buy Bernd's #3 explanation (that the first tasks issued are always at the peak of the run-time variation). Since I was the first person to publish that the run-time variation in S5R3 was cyclical, I think I can say with some authority that the runtimes I'm seeing are way outside the envelope of that variation. Either we've moved into a new era where we'll all see the extreme variability I christened Datenrat's Peak, or the whole graph has moved upwards by quite a large margin. We'll find out soon enough: since we've started again towards the bottom of the frequency range, the runtime cycle is short. Host 1001562 will be ready for charting duties tomorrow.
Your probably right in there is a misunderstanding. I thought I read in Brian's message Message ID 86418 in this thread where the linux release has the SSE2 optimizations whereas the windows release only had SSE and that was the reason for the differences. As I don't use linux I've had to rely on what I have read on the boards.
...and I'm still correct on that. The SSE2 application would run as the "2" executable. The Windows "1" app is still just SSE.
As Richard has noted, the "reference" unit seems to tell a different story from the real-world tasks.
So, I await the results of his testing and that of others...
Yes, I see your point. Indeed, we have to figure out just how big the variation is for S5R4 WUs before we can make a final judgment on what the average credit output will be. I started an experiment yesterday which I expect to finish today, which will map runtime of a typical S5R4 WU to sky-position, so we get an idea what is the worst case variation.
The cyclical behavior of S5R4 WUs will not match 1:1 that of the S5R3 formula, because some of the assumptions we made back then do no longer hold: S5R3 units all contained about 1200 sky positions, S5R4 units can contain far less (!) , but more work is done per sky position (more spin-up values tried, and longer observation time AFAIK). So the formula has to be adjusted.
What should still hold is that WUs with index "__0" should be among the slowest. WUs at this index start at a pole of the (equatorial) sky coordinate system, close to where the maximum runtime skypos is (pole of ecliptic sky coordinate system). I think Bernd was referring to this effect in the remark you quoted.
Maybe, and I say that cautiously, but maybe I am beginning to see what is troubling Brian.
I think Brian is not convinced that the cross project parity can be reached if there are differences in cr/time within a project. Here we have the problem that the 'nix version is faster than the win ver. And on Seti the cr/time is dependent on the Angle_Range of the task the graph of which is very non-linear.
I also think he is concerned about the performance of cpu families.
The problems within the project should have no bearing on the cross project parity because on that one should be looking at the average of the whole projects population not individual computer, or even groups of computers.
Some of you may have read Eric Korpela's description of his way of getting at least Seti back in line with the original credit formula. If not the link is New Credit Adjustment and the graphs he refers to are at graphs.
It would appear that the adjustment is starting to work, it will be slow as it works on a moving 30 day average, in both directions, the original Seti app credits are being lowered but the new AstroPulse tasks are getting more than is being claimed/granted on the test site, where they are going down.
AP credits Beta site before adjustment 684.33, and before release on main site.
AP credits Main Site after a few days of adjustment 720.59
AP credits Beta site after a few days of adjustment 675.64.
N.B. The Flops for all AP units that are completed is the same. Seti uses Flops counting to calculate credit claims.
The problems within the project should have no bearing on the cross project parity because on that one should be looking at the average of the whole projects population not individual computer, or even groups of computers.
In stating this, you miss the point. Telling me that "on average" things are equal when they are not equal to me, is really no consolation. From my vantage point, I do not and can not have "parity". It doesn't really matter if you have your "parity", I do not. When I raise this as an issue, if you (general sense) scoff at me and tell me I'm "emotional" about the issue, you belittle me and insult my intelligence.
The fundamental difference between my belief and your current belief is that I believe that "parity" should really be "parity for everyone". I'm willing to give a tolerance value, which I have repeatedly stated as 3-5%. When it starts getting to 10-20%, I have a real hard time accepting that things are "equal". This is in no way different from the "justifying reasons" for this quest for purported "cross-project parity".
1: What if the gap in performance for my choice of OS here was 60 or 70%?
2: Does your view of "averaging out" mean that I have no valid complaint, while your complaint that, for example, Cosmology is paying someone with the same system as you 60-70% more, is completely valid and MUST be rectified?
The problems within the project should have no bearing on the cross project parity because on that one should be looking at the average of the whole projects population not individual computer, or even groups of computers.
In stating this, you miss the point. Telling me that "on average" things are equal when they are not equal to me, is really no consolation. From my vantage point, I do not and can not have "parity". It doesn't really matter if you have your "parity", I do not. When I raise this as an issue, if you (general sense) scoff at me and tell me I'm "emotional" about the issue, you belittle me and insult my intelligence.
The fundamental difference between my belief and your current belief is that I believe that "parity" should really be "parity for everyone". I'm willing to give a tolerance value, which I have repeatedly stated as 3-5%. When it starts getting to 10-20%, I have a real hard time accepting that things are "equal". This is in no way different from the "justifying reasons" for this quest for purported "cross-project parity".
1: What if the gap in performance for my choice of OS here was 60 or 70%?
2: Does your view of "averaging out" mean that I have no valid complaint, while your complaint that, for example, Cosmology is paying someone with the same system as you 60-70% more, is completely valid and MUST be rectified?
What's the difference?
The difference because of OS in Einstein is an Einstein problem. Full Stop. And I sincerely hope that they are doing everything to make Win, and other OS, SSE2 versions soon.
If on any project identical systems, including OS, should be getting the same credits for identical work. If not then there is a problem and I agree it should be investigated and solved.
I don't know Cosmology at all. So first question is, are their credits calculated by benchmark (BM) * time, and if so what are the BM figures for the other computer?
If they are significantly higher than yours why? Is it a case of that computer using the third party BOINC client I mentioned earlier?
Is the performance of your computers similar to others of the same family and speed on other projects. Don't try comparing computers by BM scores, Pappa on SetiB has a Athlon X2 6000+ with BM's very similar to my quad, but processing times are 86hrs for his and 38hrs for mine doing astropulse units.
I have always chosen my
)
I have always chosen my operating system according to which one is more efficient on my project of choice since I started my first Boinc project 3 years ago. Although this affects credit rate the main reason for this is science/watt. This meant that I used Windows for many years when crunching Climate Prediction, even though Linux was my OS of choice. To do otherwise would be unnecessarily spending extra on electricity/carbon.
This is just my personal view and not any implied criticism of anyone's choice of operating system. I was even about to switch to FreeBSD at one stage because it was reported to be more efficient on a project I was crunching at the time. Luckily for me a Belgian person tried it first and found out that it was not more efficient than 64-bit Linux.
RE: If this is about the
)
I agree with you. About the only way I can see this with all other projects out of the picture and ONLY looking at einstein@home with the disparity of work done is: (fictional of course but gets to the point)
Example:
I have two computers that are exactly alike with all hardware, running time, etc EXCEPT that computer A (mine) runs linux and computer B (wife's) runs windows. My computer does 10 wu's a day and the wife's computer does 7 or 8 (if the disparity is 20%) We both are running einstein because it is a project that is of great importance to both of us in our related fields. Also assume there is a bit of competition between both of us on who gets more credits and processes the most work.
I'm thrilled to death because since I am running linux I am able to do more work, thus receive more credit than the wife can. The wife mean while is upset because even though she receives the same amount of credit per workunit I do, since she uses windows she can't complete as much work in the same amount of time that I can. Let's also assume that in our daily jobs I use linux for all my work and rarely see or use a windows machine. The same is true for the wife as well except that she uses a windows computer. I use linux on my system at home because that is what I am used to and I can get around a lot easier than if I were trying to figure out how to do something in windows. The same holds true for the wife, yet she is still upset that all things being equal she is unable to do the same amount of einstein@home work as I do and she's losing ground on the credit totals. Neither of us has any desire to change from our comfort zone with the OS we use. Either of us telling the other that if they want to compete then they should change to the other OS so things would be on a equal basis is ridiculous! Why should either one of us be penalized because of our choice?
Now let's bring this into a longer time frame. In the beginning I tell the wife that the reason there's a difference is because einstein's client has a problem being compiled with the MS libraries and that einstein@home is working on a solution that "might" get it where there is very little difference. Enough so that the little bit of difference really isn't going to make either of us feel like we are taking advantage of the other in work or credits or being penalized. This is fine in the beginning and it seems to sooth things over for a while. In the meantime einstein comes out with a optimized clients for both OS's. My computer with linux gets even faster, but so does the wife's computer and still hearing that they are going to do more for the windows clients she's happy that the difference isn't as great as it was before and she's happy for the time being. Life is good at home.
Now the project ends one run and begins a new one. With the new project both OS's receive a new client. Both are expecting things to even out more or less within reason. Suddenly there's even greater disparity since the new client for linux has incorperated the optimizations that made it more efficient while the windows client goes back to where it was in the beginning. Once again I try to explain why the windows client is falling behind, but that they will do something to make it more equitable as soon as things settle down after the change over. Life at home is getting strained!
To bring all this into perspective within the larger boinc community, take this senario and have the same thing happening within all the other projects. If you can't make it fair within your own project how in the heck can you try to make it equal with every project?
Just my perspective.
RE: Now the project ends
)
Hi!
There must be a misunderstanding, because for both Windows and Linux, (and OSX..) the most powerful versions (beta / poweruser app) from the S5R3 run were made the stock app for S5R4. There was no step back for Windows.
"[AF>Futura Sciences]click" has made a nice chart comparing app performance over the past months, if you allow 3% error margin you'll see that app performance did not change between S5R4 and S5R3.
CU
Bikeman
RE: There must be a
)
Your probably right in there is a misunderstanding. I thought I read in Brian's message Message ID 86418 in this thread where the linux release has the SSE2 optimizations whereas the windows release only had SSE and that was the reason for the differences. As I don't use linux I've had to rely on what I have read on the boards.
I've had to assume, maybe incorrectly, that the difference between the stock windows app and the optimized one for the last run was about 40%. On my systems that seems to have been a pretty close aprox. With the change over I'm back where I started at with the last run. I attribulated that to the lack of the SSE2 optimizations. I could be and probably am wrong. I do know that before I started using the optimized client on the last run work unit times here were about 13 hrs. After switching to the optimized client it went to aprox 6 to 7 hrs depending on where I was in the high/low cycle of the run. Now I have the new app and I'm back to 13 to 14 hours. "Bernd has said that there will be an attempt to rectify that situation" with the discrepancies between clients and that's all I have to go on.
Aside from that point I think the overall argument in my example still holds true. It's hard enough to have a level playing field within one project, whether or not it is between optimized clients or optimized vs. standard applications much less trying to level the playing field between projects.
[edit] My example was just that. My wife could care less what boinc project I run on her computer as long as it isn't CPDN since it hogs most of her memory and drags the system to a crawl.[/edit]
There really does seem to be
)
There really does seem to be something odd going here, and I'm not surprised people are getting confused.
There are different apps:
For Windows, there are two: without SSE, and with SSE
For Linux, there are three: without SSE, with SSE, and with SSE2
The chart posted by [AF>Futura Sciences]click shows very clearly that, like for like, the application speed for R4 is very close to the application speed for R3. In fact, I'd go further: for the "best" app (SSE on Windows, SSE2 on Linux), it's almost identical. The "second best" apps (non-SSE on Windows, SSE on Linux) have improved significantly. The only one which has gone backwards is non-SSE on Linux. Edit - and for AMD-Linux, there is negligable difference between SSE and SSE2.
That's from the chart, which says it's been run on an AMD XP3800+. It would be nice if someone with a dual-boot Intel could draw up an equivalent chart (sorry, I'm Windows-only here).
But that's for the reference WU. What I am seeing (and I suspect others are too) is a big change in the runtime for the real-world tasks which are being issued. That's true of both the windows _1 application which this SSE2 machine is running, and the windows _0 application which my Celeron MMX machine is running.
I'm afraid I don't buy Bernd's #3 explanation (that the first tasks issued are always at the peak of the run-time variation). Since I was the first person to publish that the run-time variation in S5R3 was cyclical, I think I can say with some authority that the runtimes I'm seeing are way outside the envelope of that variation. Either we've moved into a new era where we'll all see the extreme variability I christened Datenrat's Peak, or the whole graph has moved upwards by quite a large margin. We'll find out soon enough: since we've started again towards the bottom of the frequency range, the runtime cycle is short. Host 1001562 will be ready for charting duties tomorrow.
RE: Your probably right in
)
...and I'm still correct on that. The SSE2 application would run as the "2" executable. The Windows "1" app is still just SSE.
As Richard has noted, the "reference" unit seems to tell a different story from the real-world tasks.
So, I await the results of his testing and that of others...
Yes, I see your point.
)
Yes, I see your point. Indeed, we have to figure out just how big the variation is for S5R4 WUs before we can make a final judgment on what the average credit output will be. I started an experiment yesterday which I expect to finish today, which will map runtime of a typical S5R4 WU to sky-position, so we get an idea what is the worst case variation.
The cyclical behavior of S5R4 WUs will not match 1:1 that of the S5R3 formula, because some of the assumptions we made back then do no longer hold: S5R3 units all contained about 1200 sky positions, S5R4 units can contain far less (!) , but more work is done per sky position (more spin-up values tried, and longer observation time AFAIK). So the formula has to be adjusted.
What should still hold is that WUs with index "__0" should be among the slowest. WUs at this index start at a pole of the (equatorial) sky coordinate system, close to where the maximum runtime skypos is (pole of ecliptic sky coordinate system). I think Bernd was referring to this effect in the remark you quoted.
CU
Bikeman
Maybe, and I say that
)
Maybe, and I say that cautiously, but maybe I am beginning to see what is troubling Brian.
I think Brian is not convinced that the cross project parity can be reached if there are differences in cr/time within a project. Here we have the problem that the 'nix version is faster than the win ver. And on Seti the cr/time is dependent on the Angle_Range of the task the graph of which is very non-linear.
I also think he is concerned about the performance of cpu families.
The problems within the project should have no bearing on the cross project parity because on that one should be looking at the average of the whole projects population not individual computer, or even groups of computers.
Some of you may have read Eric Korpela's description of his way of getting at least Seti back in line with the original credit formula. If not the link is New Credit Adjustment and the graphs he refers to are at graphs.
It would appear that the adjustment is starting to work, it will be slow as it works on a moving 30 day average, in both directions, the original Seti app credits are being lowered but the new AstroPulse tasks are getting more than is being claimed/granted on the test site, where they are going down.
AP credits Beta site before adjustment 684.33, and before release on main site.
AP credits Main Site after a few days of adjustment 720.59
AP credits Beta site after a few days of adjustment 675.64.
N.B. The Flops for all AP units that are completed is the same. Seti uses Flops counting to calculate credit claims.
RE: The problems within
)
In stating this, you miss the point. Telling me that "on average" things are equal when they are not equal to me, is really no consolation. From my vantage point, I do not and can not have "parity". It doesn't really matter if you have your "parity", I do not. When I raise this as an issue, if you (general sense) scoff at me and tell me I'm "emotional" about the issue, you belittle me and insult my intelligence.
The fundamental difference between my belief and your current belief is that I believe that "parity" should really be "parity for everyone". I'm willing to give a tolerance value, which I have repeatedly stated as 3-5%. When it starts getting to 10-20%, I have a real hard time accepting that things are "equal". This is in no way different from the "justifying reasons" for this quest for purported "cross-project parity".
1: What if the gap in performance for my choice of OS here was 60 or 70%?
2: Does your view of "averaging out" mean that I have no valid complaint, while your complaint that, for example, Cosmology is paying someone with the same system as you 60-70% more, is completely valid and MUST be rectified?
What's the difference?
RE: RE: The problems
)
The difference because of OS in Einstein is an Einstein problem. Full Stop. And I sincerely hope that they are doing everything to make Win, and other OS, SSE2 versions soon.
If on any project identical systems, including OS, should be getting the same credits for identical work. If not then there is a problem and I agree it should be investigated and solved.
I don't know Cosmology at all. So first question is, are their credits calculated by benchmark (BM) * time, and if so what are the BM figures for the other computer?
If they are significantly higher than yours why? Is it a case of that computer using the third party BOINC client I mentioned earlier?
Is the performance of your computers similar to others of the same family and speed on other projects. Don't try comparing computers by BM scores, Pappa on SetiB has a Athlon X2 6000+ with BM's very similar to my quad, but processing times are 86hrs for his and 38hrs for mine doing astropulse units.