Windows Beta Test App 4.23 available

Annika
Annika
Joined: 8 Aug 06
Posts: 720
Credit: 494410
RAC: 0

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).

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686042976
RAC: 586832

My current workunit survived

Message 68364 in response to message 68363

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

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4265
Credit: 244923706
RAC: 16785

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

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: Status: This App will

Message 68366 in response to message 68365

Quote:

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

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

Lisandro Firman
Lisandro Firman
Joined: 17 May 06
Posts: 22
Credit: 49004
RAC: 0

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...

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4265
Credit: 244923706
RAC: 16785

RE: Can we still use 4.23,

Message 68368 in response to message 68366

Quote:
Can we still use 4.23, or should we revert back to 4.17?


What's broken in 4.23 is broken in 4.17, too, so honestly I don't care.

Best,
Bernd

BM

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: RE: Can we still use

Message 68369 in response to message 68368

Quote:
Quote:
Can we still use 4.23, or should we revert back to 4.17?

What's broken in 4.23 is broken in 4.17, too, so honestly I don't care.

Best,
Bernd

OK...

Did you get enough data to find out if checkpointing has improved?

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686042976
RAC: 586832

RE: It is a very good new!.

Message 68370 in response to message 68367

Quote:

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.

CU

BRM

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: Astro made a

Message 68371 in response to message 68370

Quote:

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.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686042976
RAC: 586832

RE: RE: Astro made a

Message 68372 in response to message 68371

Quote:
Quote:

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.

But we are getting off-topic a bit I'm afraid.

CU

BRM

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.