Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
Message boards :
Problems and Help :
Really Oversized program
| Author |
Message |
|---|
|
|
|
I have a program that has over 2k hrs estimated for my processor. It is a 17 or bust 1.01 application with the name of IIr_sob_71248719_2. It has a report deadline of 1/15/2013. I am running about three minutes faster per 24hrs than estimated. Why do I have such a large program? It is already on high priority. I can't use my dual core 3.2ghz processor for almost anything else extensive like gaming. | |
|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 479,147,692
RAC: 395,407
                               
|
I have a program that has over 2k hrs estimated for my processor. It is a 17 or bust 1.01 application with the name of IIr_sob_71248719_2. It has a report deadline of 1/15/2013. I am running about three minutes faster per 24hrs than estimated. Why do I have such a large program? It is already on high priority. I can't use my dual core 3.2ghz processor for almost anything else extensive like gaming.
Unless your CPU is running much slower than it should be, it will take nowhere near 2000 hours to complete that task. BOINC is notorious for having terrible estimated run times.
As the job progresses, you'll get a better sense of the actual run time by comparing the elapsed time with the percentage complete.
____________
My lucky number is 75898524288+1 | |
|
|
|
|
17 or bust 1.01 application is looking for vary large primes as such completion
can be hard because of the vary long run time.
the last one I tried estimated 12,000 hr.
a system crash and reload interrupted the task and I was unable to recover it.
but it looked like about 4 1/2 days would have seen it done.
I will try another after solstice challenge.
any one know how much credit they are worth?
| |
|
|
|
|
The main reason that estimated times are off is because each PrimeGrid sub projects have wrong or outdated GFLOPs estimation that differ in each sub project causing the DCT (duration_correction_factor)
in BOINC's client_state.xml file to be off (sometimes dramatically). Ideally the DCT should be very close to 1.000 but when you run different sub projects, that value changes, skewing many other sub projects DCT (some are very far off) resulting in wrong ETC (estimated time to completion). If you run a single sub project long enough it will eventually slowly correct itself until ETC become much more accurate. But when you change to a different sub project then the ETC goes askew again. Running multiple sub projects at the same time will cause ALL sub projects to have varying amount skewing for each one.
This all can be corrected if PrimeGrid Administration would correct the GFLOPs on ALL the sub projects. However this has been a problem for a LONG time and it seems it may never get fixed.
HEY ADMINISTRATION, how about some love for us crunchers and FINALLY fix this problem
NM*
____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713
 | |
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 479,147,692
RAC: 395,407
|
This all can be corrected if PrimeGrid Administration would correct the GFLOPs on ALL the sub projects. However this has been a problem for a LONG time and it seems it may never get fixed.
HEY ADMINISTRATION, how about some love for us crunchers and FINALLY fix this problem
NM*
If it were that simple, it would have been done years ago. :)
The reason DCF exists is because different types of calculations run at different speeds on different types of processors. A gross simplification would be if sieves run fast on AMD CPUs, but slow on Intel CPUs, while LLR runs fast on Intel and slow on AMD.
DCF is intended to correct for differing speeds by being a corrective multiplier that modifies the GFLOPs defined by the project, to create a corrected prediction for a specific computer.
That process works reasonably well if both the GLFOPS defined for the task is accurate AND if the DCF is accurate.
For the DCF to be accurate, the project's tasks need to run at a predictable rate on a single computer -- and that's possible if the project has a single type of application.
However, BOINC was originally created with the idea that each project was running only a single application -- a concept that was invalidated almost immediately as some of the earliest BOINC projects, such as CPDN, ran multiple applications.
Unfortunately, BOINC only has a single DCF per project, and this is a case where one size definitely does not fit all.
The DCF for PrimeGrid, for any given computer, is formed by some combination of the sub-projects that are run on that computer. As long as you're running more than one sub-project -- especially if they're radically different types of sub-projects (sieves, LLR, GPU, etc.), the DCF is going to essentially always be wrong for all of the tasks.
The result is that the initial time estimates are always off, and that, in turn, causes some unfortunate and problematic behavior in the BOINC scheduler.
The only way to fix this is to modify the BOINC client to support independent, multiple DCF values for sub-projects. Without that, the problem can not be fixed.
____________
My lucky number is 75898524288+1 | |
|
|
|
|
if this has been a problem from day one
I would think that pressure from administrators would be enough to get it fixed.
and barring that if we as users were so directed we could bring pressure.
bionc administrators must know there is a problem do we need to squeak
so the wheel gets oiled?
____________
| |
|
|
|
|
It is not a problem for admins.
The only effect is a display error, mainly in the start of a WU. As the user does more WU of a type the error goes, and it reduces a lot as the WU nears completion.
The only time it has any real effect on BOINC is if the WU is short, especially if the work level held by the computer is also short and the demand on the server is high.
I am running PPS to get the timers ready for the challenge now, with low work holding some have complained of not getting work early in the challenge due to these problems.
It is not normally serious enough to be a problem worthy of attention.
____________
Member team AUSTRALIA
My lucky number is 9291*2^1085585+1 | |
|
Message boards :
Problems and Help :
Really Oversized program |
