I've seen the lower 'efficiency' in the S5R2 work units as well (less credit per cpu cycle). Someone mentioned pushing Einstein behind Seti in their work share, well, at this point, perhaps some other project would make more sense. SETI is doing a fair amount of hardware shift out and for the next few weeks, you'll find it takes a lot more effort to get thru to Seti (both upload and download).
For me, I have pushed *both* SETI and Einstein back in the work share priority. I've got six active projects (though BBC Climate is a small runner for me), and so what I've done is reduct the work share for both SETI and Einstein back to 1/3 what I had been running. This results in a couple of my 'younger projects' (World Grid and Rosetta) picking up the increased share.
I suspect that the SETI issues will be resolved in a couple of weeks, then I'll move it back up the list. As to Einstein, well, here is hoping that they either tweak the code so it returns to its previous efficiency, or alternative, re-jigger the awards to get back in sync. At that point, I'll move Einstein back up the charts as it were. The thing is, there are a bunch of good projects out there, so it simply is a matter of allocating the CPU cycles between them for me.
It seems my first S5R2 work unit just crashed at the very moment I pushed the "Update project" ("Aktualisieren" in german, anyway) button :-(. Is this a general problem? Or was the task deliberately terminated by request from the server???
Host is a Pentium M (Banias) 1.5 GHz under Linux, kernel 2.6.17, BOINC version 5.8.15.
The work unit to be reported was still an S5RI one, the crashed WU was about 62 % finished.
Mo 23 Apr 2007 00:17:23 CEST|Einstein@Home|Sending scheduler request: Requested by user
Mo 23 Apr 2007 00:17:23 CEST|Einstein@Home|Reporting 1 tasks
Mo 23 Apr 2007 00:17:28 CEST|Einstein@Home|Scheduler RPC succeeded [server version 509]
Mo 23 Apr 2007 00:17:29 CEST|Einstein@Home|Deferring communication for 1 min 0 sec
Mo 23 Apr 2007 00:17:29 CEST|Einstein@Home|Reason: requested by project
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Deferring communication for 1 min 0 sec
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Reason: Unrecoverable error for result h1_0198.80_S5R2__48_S5R2c_1 (process got signal 11)
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Computation for task h1_0198.80_S5R2__48_S5R2c_1 finished
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Output file h1_0198.80_S5R2__48_S5R2c_1_0 for task h1_0198.80_S5R2__48_S5R2c_1 absent
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Starting h1_0198.80_S5R2__45_S5R2c_0
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Starting task h1_0198.80_S5R2__45_S5R2c_0 using einstein_S5R2 version 414
Let me say that even if the S5R2 run may have its problems at the beginning, I think it is worthwile to contribute to it, because this is the only way to help improve the software. There are so many different OSes, different hardware and different BOINC versions out there that you cannot expect everything to work without any glitch from the very beginning. Even if this was kind of experimental software, I'd still be happy to participate. And the credits....well... I couldn't care less :-)
Yeah, I agree with that (well I do care a bit about credits, but only to see if I'm getting better and getting the most out of my boxes, and to compete a bit with some friends)- as long as we can help the project it's okay for me, even if it doesn't run that smoothly atm. And don't forget it's also quite informative to have a "live" view into the development process, especially with people like Bruce, Bernd and Akos taking there time to give us so much information about what's being done. Personally, I see this as an interesting challenge much rather than being annoyed- and hell, it DID wake up these message boards :-D
Personally, I see this as an interesting challenge
When anyone is looking at SDLC (Systems Development Life Cycle), the majority of the "interesting challenge" part should be taken care of in either the design phases or the unit test phases. The role of QA/QC in this project should've been a group of beta testers, not the entire user base. Given the length of time post-release until the crashes started happening (immediate), a beta would've shown some serious problems that need to be overcome. Instead, the decision was made to push it on out. That's not cool, nor is it really professional.
Annika, I'm not targeting you. I'm not mad at you. I understand your point of view. As a software developer though, I'm willing to state that this application should not have been released to the entire user base yet. There are hard crashes on Intel and AMD platforms on both Windows and Linux.
I'll say it again, and probably get disliked by the project team:
I've been watching my systems pretty close over the weekend. On my dual core AMD 4800+ units were downloading with expected completion time to start with of 5 hours. Its has increased through 14, 24, 41 and 48 hours. For a 24 hour completed workunit to only receive 310 credits is either a serious flaw in the calibration or an insult to my computers spare cycles. I was averaging 18 to 20 workunits with an average credit of 53 to 54 each for a total daily average of around 1000 credits for this system. To have it cut to 1/3 the credits it was EARNING with the S5R1 units is NOT an adjustment.
Both of my other systems are AMD's, one a single core 64 3700+ and the slowest an Athlon XP 2200. For most of the weekend they were both still getting the old workunits. They both have received units with expected 13 and 16 hour completion times with the new S5R2 units. I'm going to allow those 2 systems to finish them, but I've set all my system to "No New Tasks" until this mess is straightened out. I aborted the 48 hour workunit on my 4800+ system since I can't see wasting my computer's time on an obvious flawed unit.
When all this mess is straightened out I will gladly resume working on new units. I'm sorry but I beta test enough things now that beta testing this is overload for me.
I just completed my first S5R2 using a 2.07 3200+ 64 bit Athlon and the points that I received on a per hour basis were considerably less than I was recieving from the S5R1 jobs. For example, on average running a S5R1 job I would recieve approx. 54 points for approx. 10,900 seconds of work. By comparison, I received only 204 points for 66,700 seconds of work running an S5R2. A considerable drop in points received/time.
If this is the same for everyone, then there is not problem, but I remember reading another post a couple of days ago that this result is typical only for users of AMD chips, and Intels were getting points at about the same rate as they did for S5R1 jobs.
Has anyone else noticed a drop in the number of points recieved over a specific time running the S5R2 jobs with AMD chips?
Gary
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.....Douglas Adams
I've seen the lower
)
I've seen the lower 'efficiency' in the S5R2 work units as well (less credit per cpu cycle). Someone mentioned pushing Einstein behind Seti in their work share, well, at this point, perhaps some other project would make more sense. SETI is doing a fair amount of hardware shift out and for the next few weeks, you'll find it takes a lot more effort to get thru to Seti (both upload and download).
For me, I have pushed *both* SETI and Einstein back in the work share priority. I've got six active projects (though BBC Climate is a small runner for me), and so what I've done is reduct the work share for both SETI and Einstein back to 1/3 what I had been running. This results in a couple of my 'younger projects' (World Grid and Rosetta) picking up the increased share.
I suspect that the SETI issues will be resolved in a couple of weeks, then I'll move it back up the list. As to Einstein, well, here is hoping that they either tweak the code so it returns to its previous efficiency, or alternative, re-jigger the awards to get back in sync. At that point, I'll move Einstein back up the charts as it were. The thing is, there are a bunch of good projects out there, so it simply is a matter of allocating the CPU cycles between them for me.
RE: For me, I have pushed
)
For the moment R2 seems to act as a beta project; so no more chewing on Einstein.
"souls ain't born, souls don't die"
Hi! oh oh... It seems
)
Hi!
oh oh...
It seems my first S5R2 work unit just crashed at the very moment I pushed the "Update project" ("Aktualisieren" in german, anyway) button :-(. Is this a general problem? Or was the task deliberately terminated by request from the server???
Host is a Pentium M (Banias) 1.5 GHz under Linux, kernel 2.6.17, BOINC version 5.8.15.
The work unit to be reported was still an S5RI one, the crashed WU was about 62 % finished.
Mo 23 Apr 2007 00:17:23 CEST|Einstein@Home|Sending scheduler request: Requested by user
Mo 23 Apr 2007 00:17:23 CEST|Einstein@Home|Reporting 1 tasks
Mo 23 Apr 2007 00:17:28 CEST|Einstein@Home|Scheduler RPC succeeded [server version 509]
Mo 23 Apr 2007 00:17:29 CEST|Einstein@Home|Deferring communication for 1 min 0 sec
Mo 23 Apr 2007 00:17:29 CEST|Einstein@Home|Reason: requested by project
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Deferring communication for 1 min 0 sec
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Reason: Unrecoverable error for result h1_0198.80_S5R2__48_S5R2c_1 (process got signal 11)
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Computation for task h1_0198.80_S5R2__48_S5R2c_1 finished
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Output file h1_0198.80_S5R2__48_S5R2c_1_0 for task h1_0198.80_S5R2__48_S5R2c_1 absent
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Starting h1_0198.80_S5R2__45_S5R2c_0
Mo 23 Apr 2007 00:17:30 CEST|Einstein@Home|Starting task h1_0198.80_S5R2__45_S5R2c_0 using einstein_S5R2 version 414
Let me say that even if the S5R2 run may have its problems at the beginning, I think it is worthwile to contribute to it, because this is the only way to help improve the software. There are so many different OSes, different hardware and different BOINC versions out there that you cannot expect everything to work without any glitch from the very beginning. Even if this was kind of experimental software, I'd still be happy to participate. And the credits....well... I couldn't care less :-)
CU
BRM
Yeah, I agree with that (well
)
Yeah, I agree with that (well I do care a bit about credits, but only to see if I'm getting better and getting the most out of my boxes, and to compete a bit with some friends)- as long as we can help the project it's okay for me, even if it doesn't run that smoothly atm. And don't forget it's also quite informative to have a "live" view into the development process, especially with people like Bruce, Bernd and Akos taking there time to give us so much information about what's being done. Personally, I see this as an interesting challenge much rather than being annoyed- and hell, it DID wake up these message boards :-D
RE: Personally, I see this
)
When anyone is looking at SDLC (Systems Development Life Cycle), the majority of the "interesting challenge" part should be taken care of in either the design phases or the unit test phases. The role of QA/QC in this project should've been a group of beta testers, not the entire user base. Given the length of time post-release until the crashes started happening (immediate), a beta would've shown some serious problems that need to be overcome. Instead, the decision was made to push it on out. That's not cool, nor is it really professional.
Annika, I'm not targeting you. I'm not mad at you. I understand your point of view. As a software developer though, I'm willing to state that this application should not have been released to the entire user base yet. There are hard crashes on Intel and AMD platforms on both Windows and Linux.
I'll say it again, and probably get disliked by the project team:
S5R2 needs to be taken back into beta test.
Brian
It worked for
)
It worked for me.
Estimated time after downloaded was 22 hrs plus a few minutes.
Crunch time was 24 hrs 46 so only a little off.
Using WinXP2 SP2, Athlon XP2800+, no overclocking.
Unit validated successfully and received credit.
I've been watching my systems
)
I've been watching my systems pretty close over the weekend. On my dual core AMD 4800+ units were downloading with expected completion time to start with of 5 hours. Its has increased through 14, 24, 41 and 48 hours. For a 24 hour completed workunit to only receive 310 credits is either a serious flaw in the calibration or an insult to my computers spare cycles. I was averaging 18 to 20 workunits with an average credit of 53 to 54 each for a total daily average of around 1000 credits for this system. To have it cut to 1/3 the credits it was EARNING with the S5R1 units is NOT an adjustment.
Both of my other systems are AMD's, one a single core 64 3700+ and the slowest an Athlon XP 2200. For most of the weekend they were both still getting the old workunits. They both have received units with expected 13 and 16 hour completion times with the new S5R2 units. I'm going to allow those 2 systems to finish them, but I've set all my system to "No New Tasks" until this mess is straightened out. I aborted the 48 hour workunit on my 4800+ system since I can't see wasting my computer's time on an obvious flawed unit.
When all this mess is straightened out I will gladly resume working on new units. I'm sorry but I beta test enough things now that beta testing this is overload for me.
I have finished 5 units so
)
I have finished 5 units so far.
Only one on my slower P4 2.5 that took about 32hrs (336.68 claimed credits)
And 4 on the dual P4 3.2 that took about 17hrs (each @ 172.70 claimed credits)
I haven't tried the AMD 3200 yet but may have to do that now.
I just completed my first
)
I just completed my first S5R2 using a 2.07 3200+ 64 bit Athlon and the points that I received on a per hour basis were considerably less than I was recieving from the S5R1 jobs. For example, on average running a S5R1 job I would recieve approx. 54 points for approx. 10,900 seconds of work. By comparison, I received only 204 points for 66,700 seconds of work running an S5R2. A considerable drop in points received/time.
If this is the same for everyone, then there is not problem, but I remember reading another post a couple of days ago that this result is typical only for users of AMD chips, and Intels were getting points at about the same rate as they did for S5R1 jobs.
Has anyone else noticed a drop in the number of points recieved over a specific time running the S5R2 jobs with AMD chips?
Gary
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.....Douglas Adams
RE: and Intels were getting
)
Not so. In my post above I quoted figures for an Intel 2.8GHz Northwood, it has dropped from ~15 an hour to ~11.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
