Longer WUs

eOn code for long time scale dynamics

Moderator: moderators

Post Reply
Saenger
Posts: 27
Joined: Thu Sep 02, 2010 4:23 pm
Contact:

Longer WUs

Post by Saenger »

The WUs are very short, they last less than two minutes on my machine. Is it possible to get a bit longer ones, let's say more than 15 minutes, somehow? I'd like even longer ones, over 1h long, but the actual ones primarily generate traffic, not crunchtime.
Saenger
Posts: 27
Joined: Thu Sep 02, 2010 4:23 pm
Contact:

Re: Longer WUs

Post by Saenger »

Now I get some WTs with 6-10 min duration, their names start with 578416205, is there a possibility to get more of them?
Why are most WUs still so ridiculously short?
matt
Posts: 37
Joined: Thu Jul 17, 2008 10:51 pm

Re: Longer WUs

Post by matt »

We're currently working out some bugs in our code. When these are fixed, I'll be starting some simulations with longer WUs.
Saenger
Posts: 27
Joined: Thu Sep 02, 2010 4:23 pm
Contact:

Re: Longer WUs

Post by Saenger »

I just crunched the first 3.0, and it was 10 times longer.
I hope it stays this way :)
graeme
Site Admin
Posts: 2291
Joined: Tue Apr 26, 2005 4:25 am
Contact:

Re: Longer WUs

Post by graeme »

Things look much better with v3.0. The overall performance is great.
ttoilleb
Posts: 1
Joined: Tue Jun 28, 2011 10:48 pm

Re: Longer WUs

Post by ttoilleb »

I agree, V3 WUs are nice. EXCEPT, can either the deadline be increased, or a more accurate duration estimated. V3 WUs are now taking over my systems. As soon as they download they begin running with "High Priority". Deadlines are 30hrs from download and durations are between 12.5 and 13.5 hours. Actual durations are between .5hr and 1hr.

eOn is not the only project I crunch and I would really appreciate the above changes so eOn "plays nice".
graeme
Site Admin
Posts: 2291
Joined: Tue Apr 26, 2005 4:25 am
Contact:

Re: Longer WUs

Post by graeme »

I still don't understand quite how the system works, but we have had this experience before and found that there are correction factors for the estimated time which self-correct. I will keep an eye on this, and my guess is that the estimation of the time to finish a work unit will steadily improve on its own.
michaelCG*
Posts: 12
Joined: Tue Mar 22, 2011 7:24 pm

Re: Longer WUs

Post by michaelCG* »

What about the Credits? I've not crunched that much from the new ones, but it feels like 30% less credit per CPU-time in relation to the former Workunits. Fault or Intention or am i just too impatient ;-)
Lets see how the following workunits are rated on this or any other PC.
Saenger
Posts: 27
Joined: Thu Sep 02, 2010 4:23 pm
Contact:

Re: Longer WUs

Post by Saenger »

michaelCG* wrote:What about the Credits? I've not crunched that much from the new ones, but it feels like 30% less credit per CPU-time in relation to the former Workunits. Fault or Intention or am i just too impatient ;-)
Lets see how the following workunits are rated on this or any other PC.
I can't confirm that.
Here's my experience (data from several WUs accumulated):

Code: Select all

Version	Runtime	CPU-Time	Grant	C/h clock	C/h CPU
V2.04	 33919,35	 30145,28	 293,17	31,12	35,01
V3.00	 14052,25	 13021,14	 292,70	74,99	80,92
V3.01	 87642,36	 80438,70	1035,53	42,54	46,34
V3.04	146594,46	135632,28	1583,74	38,89	42,04
Version 2.04 was OK in regard of credits.
Version 3.00 was extremely generous.
Version 3.01 is back to normal but a wee bit higher.
Edit 04 July
Version 3.04 as well a wee bit higher then 2.04

Here's my machine.
Here are my WUs.
Last edited by Saenger on Mon Jul 04, 2011 5:51 pm, edited 2 times in total.
michaelCG*
Posts: 12
Joined: Tue Mar 22, 2011 7:24 pm

Re: Longer WUs

Post by michaelCG* »

a) The 3.00 Client was really generous, but this version is the one i have missed ;)
b) I see in your case that there is no real big difference. Estimated 10 times longer duration and 10 times more credit is a fair deal
c) in my case i see that v3.01 pays only 56% of the credits compared to the v2.04 (thats even 10% worse than my estimation!)
in other words cpu-time = 20x and credit =11x is not a fair deal ( and it is even more unfair when others have no difference )
d) i'll watch the results of the next workunits on other machines but i doubt, that it will give better results regarding the credit/cpu-time ratio

Let's see if the credits and cpu-times matches better than the last ones, but in case it doesn't change i am probably not very happy with the status quo.
[BOINCstats] Willy
Posts: 1
Joined: Sun Jul 24, 2011 8:14 am

Re: Longer WUs

Post by [BOINCstats] Willy »

In my opinion you should extend the deadline, I have numerous systems which don't run 100% of the time and can't complete all the longer workunits in time.
upstatelabs
Posts: 20
Joined: Wed Oct 27, 2010 2:07 pm

Re: Longer WUs

Post by upstatelabs »

I like the longer WUs, but I wish the time to completion estimates were a little more accurate. A 1.5 hr unit will claim 30-100 hrs of estimated run time, which messes up my work waiting queue a bit.

Also, I find that I am now getting less than half the credit rate that I get for other projects like WCG and SETi, and even (gasp) uFluids. I've noticed that this doesn't seem to be everyone's experience, but I have several P4s at work and they all are behaving in the same way.

EDIT: OK, I'm now looking at 3.09 and I'm seeing more like 3/4 credit rate compared to other projects, which isn't great, but is better.
Nflight
Posts: 8
Joined: Fri Oct 22, 2010 5:10 pm
Contact:

Re: Longer WUs

Post by Nflight »

Serious deficiency of points values here. 28,000 seconds for one Work Unit equates to 23 points. That's 7+ hours of run time or about <3 points an hour ?
Saenger
Posts: 27
Joined: Thu Sep 02, 2010 4:23 pm
Contact:

Re: Longer WUs

Post by Saenger »

Longer WUs are fine, with checkpoints even better, but withthis error they are definitely not fine:

Code: Select all

<core_client_version>6.10.58</core_client_version>
<![CDATA[
<message>
Maximum elapsed time exceeded
</message>
<stderr_txt>
SIGSEGV: segmentation violation
Stack trace (2 frames):
[0x4a7ccd]
[0x4b6de0]

Exiting...

</stderr_txt>
]]>
Why is the maximum time set too low for the WU?
Post Reply