> July 9, 2004
>
> We made the core/app interface more flexible and general, providing better
> support for applications that consist of separate controller, worker, and
> graphics programs. We also added mechanisms that prevent multiple applications
> from running in the same slot, and that cause applications to exit if the core
> client dies.

>
> http://boinc.berkeley.edu/

> byron
> Canada

Finnally we are getting an excelent information service.
Congratulations on a job well done. Keep up the good work.

One question: why are we starting to get units that show 27hrs and 30 minutes for completion time, when all the previous were showing 4:35, ????

Hope you can give us a clue.

Liberto

> One question: why are we starting to get units that show 27hrs and 30 minutes
> for completion time, when all the previous were showing 4:35, ????

My guess would be that they skewed the estimated times to completion because of the current work unit shortage. This would prevent the people with absurdly large cache settings from downloading 40 or so work units and allow them to spread what they have around a little better.


Darren

> One question: why are we starting to get units that show 27hrs and 30 minutes
> for completion time, when all the previous were showing 4:35, ????

The time shown is dependant on your system speed. But have you actually processed any yet? Do they actually take that long? I still have 6 WUs before I get to the ones with longer TTCs.

<a> [/url]

> > One question: why are we starting to get units that show 27hrs and 30
> minutes
> > for completion time, when all the previous were showing 4:35, ????
>
> The time shown is dependant on your system speed. But have you actually
> processed any yet? Do they actually take that long? I still have 6 WUs before
> I get to the ones with longer TTCs.
>
> <a> [/url]
>
Well you are correct, I still need another 4 days before starting with those "special ones", at 6 units per day I will need 4 days before starting, then I'll know.

> > One question: why are we starting to get units that show 27hrs and 30
> minutes
> > for completion time, when all the previous were showing 4:35, ????

I dont know if its the same for everybody but on my system the completion time for the long WU's is exactly 6 times that of the "normal" ones - to the second. Strange or what?

Neil

On my main PC All my WU's say 05:11:00 to completion but I always seem to get done in approx 02:00:00 hours CPU time.

I've been confused about the time to completion thing but I haven't seen any of the "super" WU's yet. Every day brings a new surprise!!!





Total: 7875.90
RAC: 555.20
Pending: Eleventy bazillion :)




~Michael
"They better be out there, I think we need their help"

> On my main PC All my WU's say 05:11:00 to completion but I always seem to get
> done in approx 02:00:00 hours CPU time.
>
> I've been confused about the time to completion thing but I haven't seen any
> of the "super" WU's yet. Every day brings a new surprise!!!

Yeah, they're a bit off. The 5:11:00 is how long the scheduler thinks it should take your system based on your benchmarks. So really, it's no more than a rough estimate at present.

<a> [/url]

>
> > > One question: why are we starting to get units that show 27hrs and
> 30
> > minutes
> > > for completion time, when all the previous were showing 4:35, ????
>
> I dont know if its the same for everybody but on my system the completion time
> for the long WU's is exactly 6 times that of the "normal" ones - to the
> second. Strange or what?
>
> Neil
>
Well with mine it happens that the "normal" ones say they will last some 4hrs and 32" and normally they are finished in 3:38 average; thus I assume the new ones marked with 27hrs and based on your comment of exactly 6 times the "normals" it would become some 20hrs.
But the problem starts right there; I do have 7 units of the suppossed 27 hrs, but the report deadline for all of them IS THE SAME DAY!!!!

We will have to wait and see.
Liberto

> The time shown is dependant on your system speed. But have you actually
> processed any yet? Do they actually take that long? I still have 6 WUs before
> I get to the ones with longer TTCs.

No it isn't.
The estimated time on my system is also 27:30.
Real time per WU is about 2:50 - 3:20.

I recognized this problem yesterday for the first time.

Greetings
Stefan

I currently have a unit in cache with a completion time of 28h 26m, but this WU downloaded while another was in progress. my WU time is usually around 3:30. thankfully i only got one ;), it should start in 2 1/2 hours so i guess we'll see what happens :|. perhaps Heffed is correct in saying
"Yeah, they're a bit off. The 5:11:00 is how long the scheduler thinks it should take your system based on your benchmarks. So really, it's no more than a rough estimate at present.". It would make sense that the completion time is high if another was being processed when this WU downloaded and benchmarked.

-PyroFox

btw, sry if I dont make sense, it's 2 am and im tired :P

This could be intentionallly imposed as a way of temporarily limiting the number of WU's sent out. A recent message from the developers mentioned they were sending out much more work and if , for example you want to cache 5 days worth- bumping up the projected time would help assure that everybody asking at least gets some of what there is to go around. My estimate went from 3+ hours to 20 +. I expect many need to get caught up- The recent dumping of alot of work because of the scheduler shift and death of the old URL might call for this temporary action as well. Maybe?....cc

> But the problem starts right there; I do have 7 units of the suppossed 27 hrs,
> but the report deadline for all of them IS THE SAME DAY!!!!

The reported deadline is 14 days from the date and time the WU has been downloaded. If your 7 WU's has been downloaded the same day it is normal that the deadline is identical.

Greetings from Belgium.

I processed 4 WU's with this "long" time and the final CPU time fits within the range of the one that has been processed before.

[/url] [/url]

One could try to change the values in teh client_stat.xml file.

for a "normal" wu the values are:

|workunit|
|name|01ja04aa.2129.26368.709636.238|/name|
|app_name|setiathome|/app_name|
|version_num|308|/version_num|
|command_line||/command_line|
|env_vars||/env_vars|
|rsc_fpops_est|27924800000000.000000|/rsc_fpops_est|
|rsc_fpops_bound|446797000000000.000000|/rsc_fpops_bound|
|rsc_memory_bound|33554422.000000|/rsc_memory_bound|
|rsc_disk_bound|500000.000000|/rsc_disk_bound|
|/workunit|


and for the mystery one:


|workunit|
|name|11ja04aa.29978.26002.92308.94|/name|
|app_name|setiathome|/app_name|
|version_num|308|/version_num|
|command_line||/command_line|
|env_vars||/env_vars|
|rsc_fpops_est|167548800000000.000000|/rsc_fpops_est|
|rsc_fpops_bound|2680782000000000.000000|/rsc_fpops_bound|
|rsc_memory_bound|33554422.000000|/rsc_memory_bound|
|rsc_disk_bound|500000.000000|/rsc_disk_bound|
|/workunit|

so it seems to be the values for "rsc_fpops_est" and "rsc_fpops_bound" resbonsible for the estimated completion time. so one may change the values of the abnormal one to the normal values. perhaps this should alter the estimated completion time after a restart of boinc.

> One could try to change the values in teh client_stat.xml file.
>
> for a "normal" wu the values are:
> |workunit|
> |rsc_fpops_est|27924800000000.000000|/rsc_fpops_est|
> |rsc_fpops_bound|446797000000000.000000|/rsc_fpops_bound|

> and for the mystery one:
> |workunit|
> |rsc_fpops_est|167548800000000.000000|/rsc_fpops_est|
> |rsc_fpops_bound|2680782000000000.000000|/rsc_fpops_bound|

These numbers are exactly 6 higher.

Greetings from Belgium.

and what will this for the --NORMAL-- USER- + or-
[/url] [/url]