@jeanne95132

I have a monster running up to now 85 hours of elapsed time @ progress of 61% and let it running further.

The previous replications indeed errored out due to CPU time limit.
But I've checked max CPU time allowed for my WU as described above.
It's way enough.


Workunit Status

Project Name: Beta
Created: 24.04.09
Name: BETA_CMD2_0001-PP1BA.clustersOccur-TPM3A.clustersOccur_8
Minimum Quorum: 2
Replication: 3

Result Name Status Sent Time Time Due /
Return Time CPU Time (hours) Claimed/ Granted BOINC Credit
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 5-- In Progress 28.04.09 22:37:28 03.05.09 21:25:28 0.00 0.0 / 0.0
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 4-- In Progress 27.04.09 18:52:07 02.05.09 17:40:07 0.00 0.0 / 0.0
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 3-- In Progress 27.04.09 07:44:06 02.05.09 06:32:06 0.00 0.0 / 0.0
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 1-- Error 25.04.09 05:32:39 28.04.09 22:37:08 81.56 641.1 / 641.1
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 2-- Error 25.04.09 05:32:23 27.04.09 07:31:09 36.49 744.8 / 744.8
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM3A.clustersOccur_ 8_ 0-- Error 25.04.09 05:32:19 27.04.09 18:51:59 48.95 724.7 / 724.7

Hi Everyone,

I wanted to update you all on the 2 monsters I managed to grab.

First:-
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM1A.clustersOccur_ 25_ 4

This one is running on a Phenom 9600, XP Pro SP3, Boinc 6.2.28.
It is 50.6% complete after 73hrs 40min, based on linear calculations it is speeding up slightly.
This came with a FPOP setting of 8000 Zillion.

Second:-
BETA_ CMD2_ 0001-PP1BA.clustersOccur-TPM1A.clustersOccur_ 19_ 2

Running on a dual socket Athlon MP 2000+, W2K3 R2, Boinc 5.10.45.
It is 61.46% complete after 144hrs 50min, this one is also speeding up a bit.
I got this one first and changed the FLOP setting to 9000 Zillion.

You can see that the old 32 bit machine is really good from a badge hunting point of view, but not so good from the credit angle.

Both jobs will probably become "No Reply", which looks like good news for alert badge hunters:

If more copies are sent out and they get started before mine are returned, we can all get some good badge hours.

I'm hoping to get 15-16 DAYS worth.


Pete

Hi Jean,
I hope that the boundary actually was globally reset, because I finally found the client.xml file and nowhere could I find anything about fpop-boundary under the only beta WU I found (exported it to Word, so if Word can't find it, it doesn't exist). Curious as to whether the missing fpop line has anything to do with 64-bit cpu?--does it have different instruction set? But guess it doesn't really matter, if the end result is the same.

o.k., I will let it run to the bitter end so the scientists and techies can figure out WU sizes that won't make us anxious and pro-abortion. You would think there would be a set of standardized BOINC parameters so these things don't happen.

Was the random data I posted useful, or should I give it up, since I definitely will not be spending 24/7 in front of my computer for the next week.

In any case, we are now at
CPU PROGRESS TTC MYTIME
50:39:00 74.920 13:29:05 23:39, Apr30
61:15:31 78.458 13:24:20 15:02, may1
Was 67 CPU hours the previous boundary?

Followed someone else's lead and suspended all the other WUs to give it more space.

Thanks for your help.
Jeanne

Hi Jeanne!
I don't know if you have not found the fpops limit because Word is hiding something (I don't use Word) or if it is because you have not looked for the right thing. If you want to try again you can simply use Notepad and look for <workunt>. Right after you will probably find "your" WU, otherwise look for the next <workunt> line and so on. Once you have found the right <workunt> group the parameter that we are interested with is <rsc_fpops_bound>. To be safe it should have 15 zeroes before the decimal point.
But again, this is just for the fun, because with the original limit your WU would have already exceeded that limit. The 67 hours corresponding to this limit is for machines slower than yours.

Boinc is doing what it can, and it is precisely using the limits given with the WU to stop computing when these limits are reached. Boinc does not know what is done inside the WUs and it is of no help to set these parameters to appropriate values.

It helped me to make some calculations but, considering the slowness of the process, more spaced measurements are enough and more useful. What you give in your last post (one every 10 hours) is exactly what is needed to check that things are going as expected. And if you cannot do it the WU will still go on.
I have checked with your latest measurement at 61.25 hours and it confirms a total runtime of 110-115 hours, i.e. still 50-55 hours to go at the time it was taken.

This was for a P4 HT where two threads are competing for a single physical processor. For a P4 HT it was a very good decision.
In your case you have four physical processors and one WU cannot use more than one, therefore you can go on running four WUs, it will not slow your big one at all. The only point which could matter would be if not enough RAM is available, but it is not relevant in this case because those monster WUs are using only 5 Mbytes of RAM, i.e. peanuts in our modern world of huge program sizes. If I wanted to make a naughty joke I would say that 5 Mbytes is just enough for Vista to tell you if your computer is switched on or off.

Cheers. Jean.

Hi Mathilde2006!
The only thing which is certain about your WU is that you can definitely ignore what Boinc has to say about time to completion for this WU!
As you said it started on a 100 hours basis, but progress between 2 and 3 hours makes me think that you might be gone for much longer, say around 200 hours, like many others in this thread.
Keep an eye on it if you want to know where you are going, and consider only the progress speed if you want your forecast to be close to reality.

Cheers. Jean.