Stats have me totall confused
15 Nov 2007 21:22:23 UTC
Topic 193319
(moderation:
I just finished a task at about 12 hours. But, in the BOINC manager, your tasks are listed as around 300 hours, and my average time on finished tasks is around 50 hours.
What's up with all of these disparate numbers???
Thanks
Stats have me totall confused
)
http://sciencesprings.wordpress.com
/http://Facebook.com/sciencesprings
http://twitter.com/sciencesprings
RE: RE: I just finished a
)
I should have said, I am on a Vista Core 2 Duo machine, 2gig processor, 2 gig of DRAM.
http://sciencesprings.wordpress.com
/http://Facebook.com/sciencesprings
http://twitter.com/sciencesprings
BOINC starts tasks with an
)
BOINC starts tasks with an estimated time to completion. It can't tell you immediately how long a task runs on your computer as it doesn't know your computer. Tasks are given out to a wide variety of computers, all of which take different amounts of time to crunch them, so the time to completion will always be off initially.
Yet, give it enough time (2 to 4 weeks) and you'll see that BOINC will learn about these tasks and their length. You'll then see that the estimated time will go down. Eventually it should even out to about the correct time it takes the task to run on your computer.
There are different datasets here at Einstein though, not all of the same lenght, so it's possible that you'll see BOINC restart its learning process a couple of times.
1) Work unit size is not
)
1) Work unit size is not constant. That leads to differences in the crunch time per work unit.
2) As far as the projected finish time of 300 hours versus your actual finish time of 50 hours: there have been several posts on this subject. Check out this one for starters.
RE: Yet, give it enough
)
I think the learning process for this purpose is according to number of tasks complete (unlike RAC, which is indeed related to wall-clock elapsed time). Something like thirty completed tasks on a host seems to get it quite close to a stable value, provided the tasks themselves don't include anomalies. On a Q6600, that could be under four days. On an old Katmai, much, much longer.
RE: RE: I just finished a
)
You actually have 5 computers registered with the project so thanks for clarifying which one you are talking about. As you say, this machine is taking around 12 hours to complete a task and this is seems quite OK for that type of machine. I'm not sure where you are getting your average of 50 hours from as this machine is clearly averaging around 12 hours or so.
BOINC bases its initial estimates of crunch time on benchmark calculations that it performs every 5 days approximately. It then refines its estimate progressively (as others have mentioned) using a duration correction factor (DCF) which is recorded in the state file (called client_state.xml) in your BOINC folder. BOINC also stores the benchmark values (called p_fpops and p_iops) in the state file as well. If new tasks for this particular machine are being estimated at 300 hours, there is someting radically wrong with either your benchmark values or your DCF.
Since benchmark values are global for all projects you support, if there was a problem here, you would expect it to affect all projects on that particular computer. If only EAH is affected, it is much more likely to be the DCF that is specific to the EAH project.
The state file (client_state.xml) is text and can be browsed easily with Notepad for example. Unless you first stop BOINC, please don't make changes and don't save when you exit Notepad. Why don't you browse the state file and see what values are recorded for p_fpops and p_iops which are quite close to the top of the file. Also browse down for the tag that belongs to the Einstein project and about 20 lines below that you will find the value for duration_correction_factor.
If you report all three values here someone will help you further with your problem, if necessary.
One final point - since the EAH task deadline is 2 weeks (336 hours) it is very hard to see how BOINC allowed you to download a 300 hour estimated task since BOINC is usually quite strict in not allowing the download to occur if there is a risk of not being able to meet the deadline. This points to the task being downloaded originally with a much lower estimate and then something else happening which has blown out the estimate and so BOINC is stuck with trying to manage it. I notice that your results list for that machine shows a user abort and a detach so perhaps something got screwed up at that time. However it should be easy to fix once you tell us the numbers.
Cheers,
Gary.
"...You actually have 5
)
"...You actually have 5 computers registered with the project so thanks for clarifying which one you are talking about...."
There are actually four computers. Somehow, one machine, Laptop, has two profiles registered, "work: and "default", and no delete button. I don'r know how I did this, but obviously I did.
"...As you say, this machine is taking around 12 hours to complete a task and this is seems quite OK for that type of machine. I'm not sure where you are getting your average of 50 hours from as this machine is clearly averaging around 12 hours or so..."
Avg work done from Projects 60.04. No unit is given, I assume it is hours.
Current task from Tasks shows CPU time 1:29:33 and To completion 22:16:40.
I thought I had seen a task of 300 or so hours, but I can not confirm it. Also, another project has 337:22.01 to 10/24/2008, so I may have mis-read the small fonts.
I am currently running EAH on two Core 2 Duo Vista machines, LaptopII and DesktopII. I also had it on two PIII XP machines, Laptop and Desktop. I took it off of those machines as I thought them not up to the running of EAH and three or four other projects.
"...BOINC bases its initial estimates of crunch time on benchmark calculations that it performs every 5 days approximately. It then refines its estimate progressively (as others have mentioned) using a duration correction factor (DCF) which is recorded in the state file (called client_state.xml) in your BOINC folder. BOINC also stores the benchmark values (called p_fpops and p_iops) in the state file as well. If new tasks for this particular machine are being estimated at 300 hours, there is someting radically wrong with either your benchmark values or your DCF.
Since benchmark values are global for all projects you support, if there was a problem here, you would expect it to affect all projects on that particular computer. If only EAH is affected, it is much more likely to be the DCF that is specific to the EAH project.
The state file (client_state.xml) is text and can be browsed easily with Notepad for example. Unless you first stop BOINC, please don't make changes and don't save when you exit Notepad. Why don't you browse the state file and see what values are recorded for p_fpops and p_iops which are quite close to the top of the file. Also browse down for the tag that belongs to the Einstein project and about 20 lines below that you will find the value for duration_correction_factor.
If you report all three values here someone will help you further with your problem, if necessary...."
p_fpops= 1845225023.451501
p_iops=3834687200.882189
I cannot for the life of me find the project tag for Einstein.i searched on and went right down through the file.
Thanks for your help.
http://sciencesprings.wordpress.com
/http://Facebook.com/sciencesprings
http://twitter.com/sciencesprings
RE: p_fpops=
)
The floating point and integer ops per second look reasonable so it must be DCF. You should find several tags in your state file, one for each project running on that machine. For the Einstein project you should see these two lines at the start of the correct section of the file:-
http://einstein.phys.uwm.edu/
Do the search for the master_url and then find the DCF about 20 or so lines below that.
Cheers,
Gary.
RE: There are actually four
)
Go to your account page on the website and click on the link to view your computers. You will see all your machines listed showing a computer ID for each registration. Pick one of the duplicates and click its computer ID and you will be taken to a summary page for that machine. At the bottom of the page you will see the venue you selected for that machine (which you can change and update if you wish} and you will also see a link to allow you to merge this computer with any others that are duplicates. See if that can clean things up for you.
No, not hours - this sounds like your daily average credit from all projects running on that machine or something like that. Not important for your current problem.
PIII machines are fine (slthough somewhat slow) compared to your faster boxes. It's actually quite interesting and instructive to watch how cunningly BOINC is able to manage that project mix on slower machines :).
Cheers,
Gary.
RE: RE: There are
)
http://sciencesprings.wordpress.com
/http://Facebook.com/sciencesprings
http://twitter.com/sciencesprings