Sighting of the legendary Monster Workunits (630 cr)

archae86
archae86
Joined: 6 Dec 05
Posts: 2,824
Credit: 3,302,226,979
RAC: 2,558,244

Some Celerons have been

Some Celerons have been wonderful (for their time) (like the P55 one), some awful (like the first one).

Generalizing off the Celeron name is about like generalizing off some automobile model name like Plymouth. It is just a convenient marketing designation, with no durable actual meaning.

Performance per Hz as an absolute value metric is silly beyond description. Per Dollar, yes, per watt, yes, but per MHz--nonsense.

Somewhere around the 3081, IBM changed the performance/MHz about a factor of two. Hardly anyone even noticed. That was the right answer.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,935
Credit: 270,832,120
RAC: 228,833

Now finished two of the

Now finished two of the monsters, and the P4 is working on a third. No sign of a wingman as yet, so I think these three are going to be pending for a while to come.

In the meantime, my 400MHz Celeron has picked up a result with a 10+ day runtime estimate. It's a good thing I'm not in a hurry for those credits.

Donald A. Tevault
Donald A. Tevault
Joined: 17 Feb 06
Posts: 439
Credit: 73,516,529
RAC: 0

Well, folks. . . Judging

Well, folks. . .

Judging by its 48 hour estimated completion time, it appears that my 3500+ machine has started on one of these monsters. It's my first one, so we'll see how it goes.

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632,255
RAC: 0

I have one with a time

I have one with a time estimate of 23 days 22 hours. Not at all certain I can return it on time.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 455,978,858
RAC: 46,188

RE: I have one with a time

Message 69464 in response to message 69463

Quote:
I have one with a time estimate of 23 days 22 hours. Not at all certain I can return it on time.

What is the resource share for Einstein@Home on that host? Your list of projects is rather impressive . On 100%, even the slowest of your hosts should be ble to complete a "monster" in under 14 CPU days, so within the deadline period (if run 24/7).

CU

BRM

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632,255
RAC: 0

RE: RE: I have one with a

Message 69465 in response to message 69464

Quote:
Quote:
I have one with a time estimate of 23 days 22 hours. Not at all certain I can return it on time.

What is the resource share for Einstein@Home on that host? Your list of projects is rather impressive . On 100%, even the slowest of your hosts should be ble to complete a "monster" in under 14 CPU days, so within the deadline period (if run 24/7).

CU

BRM


The resource shazre doesn't really come into the picture. It is a 400Mhz Pentium, and the estimate of CPU time is almost 24 days.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 455,978,858
RAC: 46,188

RE: RE: RE: I have one

Message 69466 in response to message 69465

Quote:
Quote:
Quote:
I have one with a time estimate of 23 days 22 hours. Not at all certain I can return it on time.

What is the resource share for Einstein@Home on that host? Your list of projects is rather impressive . On 100%, even the slowest of your hosts should be ble to complete a "monster" in under 14 CPU days, so within the deadline period (if run 24/7).

CU

BRM


The resource shazre doesn't really come into the picture. It is a 400Mhz Pentium, and the estimate of CPU time is almost 24 days.

BOINC seems to overestimate the CPU time required here, I'd say, but if your resource share for E@H is too low, even a more realistic figure of (say) 6..10 CPU days will be too huge for the 2 week deadline and you should abort that result, what was what I intended to say.

CU

BRM

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

I think you're missing his

I think you're missing his point when it comes to 'slugs'.

The project should take into account all the performance metrics as well as the the resource share and current work onboard when it decides whether to send work or not.

In this case it looks like the project sent the result anyway, even though all the indicators from the scheduler logs say the host wouldn't be able to make the deadline even if there wasn't anything else onboard the machine at the time.

Alinator

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 455,978,858
RAC: 46,188

RE: I think you're missing

Message 69468 in response to message 69467

Quote:

I think you're missing his point when it comes to 'slugs'.

The project should take into account all the performance metrics as well as the the resource share and current work onboard when it decides whether to send work or not.

In this case it looks like the project sent the result anyway, even though all the indicators from the scheduler logs say the host wouldn't be able to make the deadline even if there wasn't anything else onboard the machine at the time.

Alinator

Based on the client's estimate, yes, the WU should never have been sent. That's granted. But the question still is whether this estimate is realistic or not. To me it looks too pessimistic.

CU

BRM

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

RE: Based on the client's

Message 69469 in response to message 69468

Quote:

Based on the client's estimate, yes, the WU should never have been sent. That's granted. But the question still is whether this estimate is realistic or not. To me it looks too pessimistic.

CU

BRM

The part your overlooking here is the estimates from the scheduler log are not client side generated other than they are based on the BM's and other metrics the host has last reported. They are server side calculated, although I'm not 100% sure at the moment (brain fade) about who actually calculates the RDCF.

I am sure the the estimated CPU duration in the scheduler log is server generated, and that the final estimate in that line is the ECD times the RDCF. Therefore if the RDCF is even in the ballpark as far as being correct and the final estimate is greater than 1,209,600 seconds, then the host has no chance of making the deadline (unless it's BM's and other client side metrics are completely whacked for some reason that is).

I have been tracking this on my K6 family hosts as well as my Katmai and the numbers work. The Katmai hasn't missed a deadline yet, and the scheduler logs said it wouldn't. However for the K6's, the project has sent work to them where it 'knew' it would take longer than the deadline, and sure enough they overran it.

There has always been something funny about the 'feel' of the way the EAH scheduler was working, but then we weren't looking at being in the tight deadline scenario we are now (for slowhosts). Back then it didn't make any difference in the long run. OTOH, it did raise it's head a little in S5R1, since they implemented the differentiation between fast and slow hosts to mitigate the problem of some people pushing the deadline and subsequently going into EDF all the time as we got to the higher template frequencies.

This is the main reason I have lobbied for an increase in deadline, at least for the interim. Up until S5R2, none of my hosts ever missed a deadline, even running more than one project. Now there's almost no reason to keep the K6's attached, even though they are fully capable of doing the work.

Alinator

Comment viewing options

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