Agreed, if my puny little K6's and K6-2's can hang in the battle for 700,000 plus seconds and succeed, I don't see why folks with 'big gun' battleships need to turn tail and run, except for those having actual app faults. ;-)
Even then the team is pulling some pretty long hours working to get new versions out fast to eliminate the problems, and the optimization will come after that.
I don't see why folks with 'big gun' battleships need to turn tail and run, except for those having actual app faults. ;-)
I am abstaining out of principle... If they want to take the app into the beta area, I'll help out. Otherwise, no cycles until they can show that I'm not running the risk of wasting time and energy...
I don't see why folks with 'big gun' battleships need to turn tail and run, except for those having actual app faults. ;-)
I am abstaining out of principle... If they want to take the app into the beta area, I'll help out. Otherwise, no cycles until they can show that I'm not running the risk of wasting time and energy...
I'm not saying the project is beta right now. But let's assume, for the sake of argument, it is.
Isn't hammering out an app through a beta stage just as important to the ultimate goal as the actual crunching of data? Both need to get done before the final goal, and you get credits for both.
Isn't hammering out an app through a beta stage just as important to the ultimate goal as the actual crunching of data? Both need to get done before the final goal, and you get credits for both.
There is an appropriate place for doing a beta with this project. The project team chose not to put it there. There's a right way to do a beta, then there's the way that the team chose this time around... R2 is claimed to have a substantial amount of new code. That statement, in and of itself, justified a beta. The significant amount of crashes may turn out to be overclocking, or it may not. In either case, had the team taken the application to the beta area instead of going live with it, they likely would've found the same errors.
Like I said, if they want to do this debugging over in the beta test area, I'll be happy to help, but I am trying to make a point that using the entire user base without telling them via email is not appropriate and is highly lacking in professional courtesy.
Matt, you're not going to change my mind, so there's not much point in continuing on about it, ok?
We've talked about this a couple of times, but one thing to remember about the Beta area here is that in essence it's the same thing as the main project. There is no separate BOINC system setup up like SAH to differentiate the two.
I can see your point that it isn't explicitly spelled out as Beta anywhere, but a careful reading of Bernd's opening post surely makes it clear that S5R2 is an experiment to flesh out issues for the next full scale run (S5R3), even to non-experts/enthusiaists. In this case where it was stated to be experimental, the advantage to running production style is you don't have to do anything to run the updated version, unlike when there is an in run Beta to test. As has been mentioned earlier in this thread, there are some clever workarounds possible to eliminate some of these limitations but they would have to rework parts of the backend to do it, and I can only assume there's no time in the current schedule to allow for that.
I'm not trying to change you mind here and respect your position, but am just laying out how Beta testing has worked in general here on EAH for as long as I have been here for the casual reader.
You do have a point -- what I've done instead (to help the Einstein folks with the S5R2 production beta they are running), is continue running the project (at least with most of my previous Einstein systems), but reduce the resource share. As I continue to run into problems (the same ones others are running into) I'll reduce that share further. I may also suspend entirely on some of the systems since many of them are AMD's running Windows and that combination is clearly suffering with the existing code.
I am abstaining out of principle... If they want to take the app into the beta area, I'll help out. Otherwise, no cycles until they can show that I'm not running the risk of wasting time and energy...
I did not detach abruptly - I simply said "no new work" and let everything finish.
I do not mind a beta. I do mind, however, a beta that cuts a _large_ portion of my credits away due to a) general credit shrinkage and b) very poor performance on AMD systems.
There is no separate BOINC system setup up like SAH to differentiate the two.
Then perhaps they should consider it...
Quote:
I can see your point that it isn't explicitly spelled out as Beta anywhere,
I also mentioned an email.......
"Dear Einstein@Home Contributor,
We are approaching the conclusion of the analysis of our latest data collection. Shortly after the remaining workunits are sent out, we will be starting up a new run of data analysis. We have attempted a new approach in the upcoming data analysis. Due to this new approach, we, the staff, felt it best to advise you that the analysis will be more in-depth than in the past. As such, you may notice a marked increase in the amount of time for each unit to be completed. This increase in completion times will be reduced as we work to optimize our new search methods and will ultimately result in an improved search method as we go forward.
Should you experience any issues with the new science application, please navigate to our message boards and post a message in the Problems and Bug Reports section of the Help Desk message area of the forums.
We appreciate your continued support of Einstein@Home.
[insert signatures]
The project team and/or their legal folks could wrestle with the exact verbiage, but I think that's fairly close. Simple, to the point, and letting everyone know what is going to be happening and what to do if they have problems.
Hers's my problem with what Einstein is doing. Most useres never read the messages boards (just look at the number of users who have posted here). They look at what Einstein is doing on their computer, see that it's taking longer than what it use to take and abort the work unit, they may do this 2 or 3 times. Some then may visit the board, other just detach and go to another project or supend the project and switch to another project, either way work unit are not completed. Don't beleive me just look at the numbers, people don't like change and like it less when they're not told what's going on.
Agreed, if my puny little
)
Agreed, if my puny little K6's and K6-2's can hang in the battle for 700,000 plus seconds and succeed, I don't see why folks with 'big gun' battleships need to turn tail and run, except for those having actual app faults. ;-)
Even then the team is pulling some pretty long hours working to get new versions out fast to eliminate the problems, and the optimization will come after that.
Alinator
RE: I don't see why folks
)
I am abstaining out of principle... If they want to take the app into the beta area, I'll help out. Otherwise, no cycles until they can show that I'm not running the risk of wasting time and energy...
RE: RE: I don't see why
)
I'm not saying the project is beta right now. But let's assume, for the sake of argument, it is.
Isn't hammering out an app through a beta stage just as important to the ultimate goal as the actual crunching of data? Both need to get done before the final goal, and you get credits for both.
RE: Isn't hammering out an
)
There is an appropriate place for doing a beta with this project. The project team chose not to put it there. There's a right way to do a beta, then there's the way that the team chose this time around... R2 is claimed to have a substantial amount of new code. That statement, in and of itself, justified a beta. The significant amount of crashes may turn out to be overclocking, or it may not. In either case, had the team taken the application to the beta area instead of going live with it, they likely would've found the same errors.
Like I said, if they want to do this debugging over in the beta test area, I'll be happy to help, but I am trying to make a point that using the entire user base without telling them via email is not appropriate and is highly lacking in professional courtesy.
Matt, you're not going to change my mind, so there's not much point in continuing on about it, ok?
[Brian's lurk mode == back on]
We've talked about this a
)
We've talked about this a couple of times, but one thing to remember about the Beta area here is that in essence it's the same thing as the main project. There is no separate BOINC system setup up like SAH to differentiate the two.
I can see your point that it isn't explicitly spelled out as Beta anywhere, but a careful reading of Bernd's opening post surely makes it clear that S5R2 is an experiment to flesh out issues for the next full scale run (S5R3), even to non-experts/enthusiaists. In this case where it was stated to be experimental, the advantage to running production style is you don't have to do anything to run the updated version, unlike when there is an in run Beta to test. As has been mentioned earlier in this thread, there are some clever workarounds possible to eliminate some of these limitations but they would have to rework parts of the backend to do it, and I can only assume there's no time in the current schedule to allow for that.
I'm not trying to change you mind here and respect your position, but am just laying out how Beta testing has worked in general here on EAH for as long as I have been here for the casual reader.
Alinator
RE: RE: You do have a
)
I did not detach abruptly - I
)
I did not detach abruptly - I simply said "no new work" and let everything finish.
I do not mind a beta. I do mind, however, a beta that cuts a _large_ portion of my credits away due to a) general credit shrinkage and b) very poor performance on AMD systems.
RE: There is no separate
)
Then perhaps they should consider it...
I also mentioned an email.......
"Dear Einstein@Home Contributor,
We are approaching the conclusion of the analysis of our latest data collection. Shortly after the remaining workunits are sent out, we will be starting up a new run of data analysis. We have attempted a new approach in the upcoming data analysis. Due to this new approach, we, the staff, felt it best to advise you that the analysis will be more in-depth than in the past. As such, you may notice a marked increase in the amount of time for each unit to be completed. This increase in completion times will be reduced as we work to optimize our new search methods and will ultimately result in an improved search method as we go forward.
Should you experience any issues with the new science application, please navigate to our message boards and post a message in the Problems and Bug Reports section of the Help Desk message area of the forums.
We appreciate your continued support of Einstein@Home.
[insert signatures]
The project team and/or their legal folks could wrestle with the exact verbiage, but I think that's fairly close. Simple, to the point, and letting everyone know what is going to be happening and what to do if they have problems.
i've got problems in linux
)
i've got problems in linux too
but restarted another box just to see :)
Hers's my problem with what
)
Hers's my problem with what Einstein is doing. Most useres never read the messages boards (just look at the number of users who have posted here). They look at what Einstein is doing on their computer, see that it's taking longer than what it use to take and abort the work unit, they may do this 2 or 3 times. Some then may visit the board, other just detach and go to another project or supend the project and switch to another project, either way work unit are not completed. Don't beleive me just look at the numbers, people don't like change and like it less when they're not told what's going on.