OK, I'm one of those dial-up folks. Why do I get over 80 CPU hours of work from a download. That's unreasonable given the deadline that's being set
Even the longest Workunits will require far less than 80 CPU hours on your Pentim 4. Don't trust the inital estimate of the boinc manager, this is very pessimistic sometimes.
Let it run for some hours and you will probably see the estimated remaining time drop faster than the elapsed CPU time increases.
CU
BRM
It seems like Boinc has to run about 50% of the first WU before it starts to correct the times. The corrected times look like they are not applied to WU's already downloaded, but just to the next batch of WU's you download. So- That being said, just hang in there, within several days the numbers should start to look better.
My Linux box and an OSX box were paired against a Windows machine. But, the OSX box and the Windows machine validated with each other, and left my Linux box out in the cold with zero points. A bit out of the ordinary, no?
My Linux box and an OSX box were paired against a Windows machine. But, the OSX box and the Windows machine validated with each other, and left my Linux box out in the cold with zero points. A bit out of the ordinary, no?
Indeed, first time I see that. Bernd will be interested in this one, I guess. He's already written that there's not one single issue responsible for the x-platform validation problem, but a combination of issues.
To whomever it may concern and with all due respect I am not pleased with the new longer crunch times on AMD / Windows, nor any other platform for that matter. Like a trooper I gave this a go and the benefit of the doubt but in truth I am so far unimpressed. I understand the needs and the whys but I do not wish to tie up my computer in such a manner. 24 hours or more for a WU is just too taxing.
And suggesting my switching to an alternative operating system such as Linux to get better results is not going to happen. I would much rather see a friendlier E@H version for the AMD / Windows platform. OS / Platform of choice should be a non-issue. MO's
To whomever it may concern and with all due respect I am not pleased with the new longer crunch times on AMD / Windows, nor any other platform for that matter. Like a trooper I gave this a go and the benefit of the doubt but in truth I am so far unimpressed. I understand the needs and the whys but I do not wish to tie up my computer in such a manner. 24 hours or more for a WU is just too taxing.
And suggesting my switching to an alternative operating system such as Linux to get better results is not going to happen. I would much rather see a friendlier E@H version for the AMD / Windows platform. OS / Platform of choice should be a non-issue. MO's
Respectfully and no flames intended,
Antony
The latest official Windows version (4.24) of the app has let to a ca. 25 % performance increase for all AMD CPUs and for Intel CPUs that do not support SSE2 (e.g. Pentium I..III). The Linux app is still a bit faster, but not as significantly as before. Because different compilers are used under Linux /Darwin and Windows, some performance differences can't be helped. At least the drastic AMD handicap you mentioned is solved, now.
Unless you have a beta version installed with an app_info.xml file, the new version will be installed automatically ony your PC.
... I am not pleased with the new longer crunch times on AMD / Windows ...
I'm assuming you have two quite separate concerns. Firstly, there is the penalty that AMD and PIII type computers were suffering and ...
Quote:
24 hours or more for a WU is just too taxing.
... secondly there is the fact that WUs take a long time to crunch.
As Bikeman points out, the first issue was addressed with the release of the version 4.24 science app on June 28. All Windows users would have automatically transitioned to that app by now if they have simply allowed the system to work as intended. As most of my computers were either AMD or PIII, I know from personal experience that the previous penalty is now largely removed. There really isn't a great deal of difference any more.
Quote:
And suggesting my switching to an alternative operating system such as Linux ...
When the problem was first identified for the PIII architecture, I publicised the fact that there was a considerable improvement in efficiency to be had by using Linux. I regarded that as keeping other participants informed. There was no attempt to force people to switch. People were quite free to take whatever course of action or inaction they wished. None of the staff of this project made any comment suggesting that people needed to switch.
With regard to your second point, yes, a number of people, including myself, would like to see shorter WUs. Having said that, I think it's useful to work out exactly what the disadvantages of long WUs really are. One of the reasons you suggest is that it "ties your computer up" for too long. Other people often seem to get really distressed about this too. Let's assume that a person is prepared to give 25 hours of crunching time to EAH. Does it really make all that much difference if the time was made up by one 25hr result or 25 one hr results?
Well yes it does because of at least two reasons. Firstly a random client error half way through a long result will cause a bigger waste of crunching time for results that take a long time. This doesn't take into account the real possibility that proportionally more short units than long units might be so affected.
Secondly, there is likely to be greater deadline pressure for longs compared with shorts, particularly for slower machines or multiple project machines. Once again there are counter arguments along the lines that BOINC can easily and automatically take care of deadlines provided that the user doesn't set it an impossible task.
I know you are aware of these sort of points because you said so :). I'm just restating some of them for the benefit of those who may not be so familiar with the issues but who have had the perseverance to keep reading this far :).
To me the key question is this. Can any of the participants, even the most experienced ones, really fully understand all of the factors that govern the decisions that have to be made about these matters? Isn't it in fact just the developers themselves who are in the best position to make these decisions? If we don't think they are, we should simply move on and leave them to their project. If we do think they are, we should remind them of our concerns but then support whatever choice they ultimately make. Believe me, the developers have been reminded of these very concerns many times before :).
The latest official Windows version (4.24) of the app has let to a ca. 25 % performance increase for all AMD CPUs and for Intel CPUs that do not support SSE2 (e.g. Pentium I..III). The Linux app is still a bit faster, but not as significantly as before. Because different compilers are used under Linux /Darwin and Windows, some performance differences can't be helped. At least the drastic AMD handicap you mentioned is solved, now.
This is good news for the AMD / Windows users indeed. Thanks BRM.
Quote:
When the problem was first identified for the PIII architecture, I publicised the fact that there was a considerable improvement in efficiency to be had by using Linux. I regarded that as keeping other participants informed. There was no attempt to force people to switch. People were quite free to take whatever course of action or inaction they wished. None of the staff of this project made any comment suggesting that people needed to switch.
This point I totally agree with Gary, my stating that was a result of many people stating that faster crunch times were available with the use of Linux due to the compiler if I am not mistaken? The "just swap out Windows for Linux" idea had been thrown out there numerous times by various scores of people in many different forums I had read through and browsed. And of course the project heads never forced such a thing on users. Please forgive my not stating the intended audience's as I did not wish to point fingers either here nor elsewhere. It was an attempt to not give the appearance of me bashing someones choices of what they use OS wise to get the science done, which in the end is the ultimate goal. I have no problem at all with peoples uses of alternative operating systems, or their suggesting the alternative. If it works for that person so be it! Great! Likewise I would hope that they not bash us Windows crunchers either.
Also with regards to the crunch dilemma's you have read my mind Gary, and summed it all up rather well if I may add. Thanks for your time and attention with regards to this. :)
Again respectfully and no flames intended to anyone,
That link goes to the results list of a host that doesn't seem to have a problem. There are three results, one completed and credited. one completed and pending and one currently crunching.
RE: RE: OK, I'm one of
)
It seems like Boinc has to run about 50% of the first WU before it starts to correct the times. The corrected times look like they are not applied to WU's already downloaded, but just to the next batch of WU's you download. So- That being said, just hang in there, within several days the numbers should start to look better.
Here's a new wrinkle on
)
Here's a new wrinkle on things. . .
My Linux box and an OSX box were paired against a Windows machine. But, the OSX box and the Windows machine validated with each other, and left my Linux box out in the cold with zero points. A bit out of the ordinary, no?
My result
RE: Here's a new wrinkle on
)
Indeed, first time I see that. Bernd will be interested in this one, I guess. He's already written that there's not one single issue responsible for the x-platform validation problem, but a combination of issues.
CU
BRM
To whomever it may concern
)
To whomever it may concern and with all due respect I am not pleased with the new longer crunch times on AMD / Windows, nor any other platform for that matter. Like a trooper I gave this a go and the benefit of the doubt but in truth I am so far unimpressed. I understand the needs and the whys but I do not wish to tie up my computer in such a manner. 24 hours or more for a WU is just too taxing.
And suggesting my switching to an alternative operating system such as Linux to get better results is not going to happen. I would much rather see a friendlier E@H version for the AMD / Windows platform. OS / Platform of choice should be a non-issue. MO's
Respectfully and no flames intended,
Antony
RE: To whomever it may
)
The latest official Windows version (4.24) of the app has let to a ca. 25 % performance increase for all AMD CPUs and for Intel CPUs that do not support SSE2 (e.g. Pentium I..III). The Linux app is still a bit faster, but not as significantly as before. Because different compilers are used under Linux /Darwin and Windows, some performance differences can't be helped. At least the drastic AMD handicap you mentioned is solved, now.
Unless you have a beta version installed with an app_info.xml file, the new version will be installed automatically ony your PC.
CU
BRM
RE: ... I am not pleased
)
I'm assuming you have two quite separate concerns. Firstly, there is the penalty that AMD and PIII type computers were suffering and ...
... secondly there is the fact that WUs take a long time to crunch.
As Bikeman points out, the first issue was addressed with the release of the version 4.24 science app on June 28. All Windows users would have automatically transitioned to that app by now if they have simply allowed the system to work as intended. As most of my computers were either AMD or PIII, I know from personal experience that the previous penalty is now largely removed. There really isn't a great deal of difference any more.
When the problem was first identified for the PIII architecture, I publicised the fact that there was a considerable improvement in efficiency to be had by using Linux. I regarded that as keeping other participants informed. There was no attempt to force people to switch. People were quite free to take whatever course of action or inaction they wished. None of the staff of this project made any comment suggesting that people needed to switch.
With regard to your second point, yes, a number of people, including myself, would like to see shorter WUs. Having said that, I think it's useful to work out exactly what the disadvantages of long WUs really are. One of the reasons you suggest is that it "ties your computer up" for too long. Other people often seem to get really distressed about this too. Let's assume that a person is prepared to give 25 hours of crunching time to EAH. Does it really make all that much difference if the time was made up by one 25hr result or 25 one hr results?
Well yes it does because of at least two reasons. Firstly a random client error half way through a long result will cause a bigger waste of crunching time for results that take a long time. This doesn't take into account the real possibility that proportionally more short units than long units might be so affected.
Secondly, there is likely to be greater deadline pressure for longs compared with shorts, particularly for slower machines or multiple project machines. Once again there are counter arguments along the lines that BOINC can easily and automatically take care of deadlines provided that the user doesn't set it an impossible task.
I know you are aware of these sort of points because you said so :). I'm just restating some of them for the benefit of those who may not be so familiar with the issues but who have had the perseverance to keep reading this far :).
To me the key question is this. Can any of the participants, even the most experienced ones, really fully understand all of the factors that govern the decisions that have to be made about these matters? Isn't it in fact just the developers themselves who are in the best position to make these decisions? If we don't think they are, we should simply move on and leave them to their project. If we do think they are, we should remind them of our concerns but then support whatever choice they ultimately make. Believe me, the developers have been reminded of these very concerns many times before :).
Absolutely ... and likewise.
Cheers,
Gary.
RE: The latest official
)
This is good news for the AMD / Windows users indeed. Thanks BRM.
This point I totally agree with Gary, my stating that was a result of many people stating that faster crunch times were available with the use of Linux due to the compiler if I am not mistaken? The "just swap out Windows for Linux" idea had been thrown out there numerous times by various scores of people in many different forums I had read through and browsed. And of course the project heads never forced such a thing on users. Please forgive my not stating the intended audience's as I did not wish to point fingers either here nor elsewhere. It was an attempt to not give the appearance of me bashing someones choices of what they use OS wise to get the science done, which in the end is the ultimate goal. I have no problem at all with peoples uses of alternative operating systems, or their suggesting the alternative. If it works for that person so be it! Great! Likewise I would hope that they not bash us Windows crunchers either.
Also with regards to the crunch dilemma's you have read my mind Gary, and summed it all up rather well if I may add. Thanks for your time and attention with regards to this. :)
Again respectfully and no flames intended to anyone,
Antony
Any one know whats up with
)
Any one know whats up with this http://einsteinathome.org/host/843574/tasks ?
Anders n
That link goes to the results
)
That link goes to the results list of a host that doesn't seem to have a problem. There are three results, one completed and credited. one completed and pending and one currently crunching.
Unless I'm missing something, everything appears normal??
Cheers,
Gary.
Oups link to wrong page :(
)
Oups link to wrong page :( and the result is gone now.
There was 3 validated results and 1 waiting for validation and 1 under work.
Anders n