Okay Brian, looks like you were right there. At about 40% finished the WU seems to be headed for a completion time around 40 hours, which would be 10.5 credits/hour. Not great, but acceptable. Maybe the WU will get a bit faster still. So, no performance probs here (apart from what this box has had under Windows before) and still crunching perfectly stable despite some evil stuff I did (a bit of heat, keeping both cores busy with video encoding, yesterday's bluescreen and a few network problems at Uni- none of this was on purpose, except the video encoding of course but I had to do that anyway, but it should have been quite a test).
My current workunit survived an emergency hibernation after a low battery condition :-), and some minor network sabotaging. Later I realized that it is kind of futile to expect meaningfull debug traces for network related problems: how should the app load the debugging stuff from the symbolstore if the network is down :-(??
This App will never make it to become an "official" App. The "Symbol Store" feature is not working properly. And last night I discovered a bug in our code that is probably responsible for quite some trouble, at least for (some of the) cross-platform validation problems, and maybe memory access violations, too.
I'll build a new App (which will actually need to be a new generation of Apps for all platforms) and announce it for Beta Test here.
This App will never make it to become an "official" App. The "Symbol Store" feature is not working properly. And last night I discovered a bug in our code that is probably responsible for quite some trouble, at least for (some of the) cross-platform validation problems, and maybe memory access violations, too.
I'll build a new App (which will actually need to be a new generation of Apps for all platforms) and announce it for Beta Test here.
Thanks for testing! This was incredibly helpful!
BM
Bernd,
It's good news that you have tracked some stuff down in any case...
Can we still use 4.23, or should we revert back to 4.17?
It is a very good new!. And better still that they have learned from past mistakes and maintain a beta testing program. That is the way to go!!
One observation about credits. A lot of people complained that E@H grants to few credits compared to other projects. Right now, it doesn't look so. I crunch for 3 projects with a Pentium Dual Core T2300 (Yonah) and E@H grants an average of 13.5 credits per hour per core, Rosetta 11 and Proteins@home 9.7... so E@H is the most generous... Maybe in AMD/Windows because of the modf() problem the credits are too low, but not on Intel...
It is a very good new!. And better still that they have learned from past mistakes and maintain a beta testing program. That is the way to go!!
One observation about credits. A lot of people complained that E@H grants to few credits compared to other projects. Right now, it doesn't look so. I crunch for 3 projects with a Pentium Dual Core T2300 (Yonah) and E@H grants an average of 13.5 credits per hour per core, Rosetta 11 and Proteins@home 9.7... so E@H is the most generous... Maybe in AMD/Windows because of the modf() problem the credits are too low, but not on Intel...
Astro made a cross-project comparison lately. From that one, it looked as if a Win/AMD box might have been used to calibrate the credits and therefore led to slightly too generous crediting now, compared to most other projects, IIRC.
@Bernd: Excellent news, thanks for the overtime you obviously put into this debugging effort!!
Is it too early to ask whether some of the results computed so far will have to
be recomputed? Sounds like a rather serious problem affecting all platforms.
Astro made a cross-project comparison lately. From that one, it looked as if a Win/AMD box might have been used to calibrate the credits and therefore led to slightly too generous crediting now, compared to most other projects, IIRC.
I do wish to reiterate something:
One should not concern oneself with cross-project parity until such time as intra-project parity is achieved.
Irrespective of what box was used, K8-class Win/AMD would've been penalized.
Had Linux/AMD been used, Linux was faster, so Win/AMD would've still been penalized.
Had Windows/Intel been used, Intel was faster, so Win/AMD would've still been penalized.
Had Linux/Intel been used, Intel and/or Linux was faster, so Win/AMD would've still been penalized.
Astro made a cross-project comparison lately. From that one, it looked as if a Win/AMD box might have been used to calibrate the credits and therefore led to slightly too generous crediting now, compared to most other projects, IIRC.
I do wish to reiterate something:
One should not concern oneself with cross-project parity until such time as intra-project parity is achieved.
Irrespective of what box was used, K8-class Win/AMD would've been penalized.
Had Linux/AMD been used, Linux was faster, so Win/AMD would've still been penalized.
Had Windows/Intel been used, Intel was faster, so Win/AMD would've still been penalized.
Had Linux/Intel been used, Intel and/or Linux was faster, so Win/AMD would've still been penalized.
I think everybody understands that point, and personally I don't care whether I get 1 or 1000 cobblestones per CPU hour. But you cannot neglect that fact that there are others out there that are basing their choice of BOINC projects not so much on scientific significance (who are we to judge this, anyway) but on a simple calculation what project will yield the most cobblestones for them. Like it or not, I think this is a fact.
In my eyes it's a matter of inter-project etiquette to try to align the credits or else credit-inflation would happen in a race to attract more users. If intra-parity cannot be achieved, it would be reasonable to pick the most widely used platform for calibration instead (you have to calibrate the cobblestones to some value, after all). At the moment this would rather be Intel/Win than AMD/Win.
Okay Brian, looks like you
)
Okay Brian, looks like you were right there. At about 40% finished the WU seems to be headed for a completion time around 40 hours, which would be 10.5 credits/hour. Not great, but acceptable. Maybe the WU will get a bit faster still. So, no performance probs here (apart from what this box has had under Windows before) and still crunching perfectly stable despite some evil stuff I did (a bit of heat, keeping both cores busy with video encoding, yesterday's bluescreen and a few network problems at Uni- none of this was on purpose, except the video encoding of course but I had to do that anyway, but it should have been quite a test).
My current workunit survived
)
My current workunit survived an emergency hibernation after a low battery condition :-), and some minor network sabotaging. Later I realized that it is kind of futile to expect meaningfull debug traces for network related problems: how should the app load the debugging stuff from the symbolstore if the network is down :-(??
CU
BRM
Status: This App will
)
Status:
This App will never make it to become an "official" App. The "Symbol Store" feature is not working properly. And last night I discovered a bug in our code that is probably responsible for quite some trouble, at least for (some of the) cross-platform validation problems, and maybe memory access violations, too.
I'll build a new App (which will actually need to be a new generation of Apps for all platforms) and announce it for Beta Test here.
Thanks for testing! This was incredibly helpful!
BM
BM
RE: Status: This App will
)
Bernd,
It's good news that you have tracked some stuff down in any case...
Can we still use 4.23, or should we revert back to 4.17?
Thanks,
Brian
It is a very good new!. And
)
It is a very good new!. And better still that they have learned from past mistakes and maintain a beta testing program. That is the way to go!!
One observation about credits. A lot of people complained that E@H grants to few credits compared to other projects. Right now, it doesn't look so. I crunch for 3 projects with a Pentium Dual Core T2300 (Yonah) and E@H grants an average of 13.5 credits per hour per core, Rosetta 11 and Proteins@home 9.7... so E@H is the most generous... Maybe in AMD/Windows because of the modf() problem the credits are too low, but not on Intel...
RE: Can we still use 4.23,
)
What's broken in 4.23 is broken in 4.17, too, so honestly I don't care.
Best,
Bernd
BM
RE: RE: Can we still use
)
OK...
Did you get enough data to find out if checkpointing has improved?
RE: It is a very good new!.
)
Astro made a cross-project comparison lately. From that one, it looked as if a Win/AMD box might have been used to calibrate the credits and therefore led to slightly too generous crediting now, compared to most other projects, IIRC.
@Bernd: Excellent news, thanks for the overtime you obviously put into this debugging effort!!
Is it too early to ask whether some of the results computed so far will have to
be recomputed? Sounds like a rather serious problem affecting all platforms.
CU
BRM
RE: Astro made a
)
I do wish to reiterate something:
One should not concern oneself with cross-project parity until such time as intra-project parity is achieved.
Irrespective of what box was used, K8-class Win/AMD would've been penalized.
Had Linux/AMD been used, Linux was faster, so Win/AMD would've still been penalized.
Had Windows/Intel been used, Intel was faster, so Win/AMD would've still been penalized.
Had Linux/Intel been used, Intel and/or Linux was faster, so Win/AMD would've still been penalized.
RE: RE: Astro made a
)
I think everybody understands that point, and personally I don't care whether I get 1 or 1000 cobblestones per CPU hour. But you cannot neglect that fact that there are others out there that are basing their choice of BOINC projects not so much on scientific significance (who are we to judge this, anyway) but on a simple calculation what project will yield the most cobblestones for them. Like it or not, I think this is a fact.
In my eyes it's a matter of inter-project etiquette to try to align the credits or else credit-inflation would happen in a race to attract more users. If intra-parity cannot be achieved, it would be reasonable to pick the most widely used platform for calibration instead (you have to calibrate the cobblestones to some value, after all). At the moment this would rather be Intel/Win than AMD/Win.
But we are getting off-topic a bit I'm afraid.
CU
BRM