Estimation about total calculating time
8 May 2007 17:48:03 UTC
Topic 192706
(moderation:
I connected to Einstein because the problems of Seti.
But !!!
I downloaded a Einstein WU with request of 2 days ( 48 hours of course)
I receive TWO WU about 70 hours !!
But when it began to run, the estimated time to completion increase second by second. Now, after 2 hours working time and 3.3% to completion, the time stay increase !!!
A easy estimation 3.3% at 120 minuts normaly need to result about 100% at 60,6 hours !! I am already at 1 day more than expected !!!
The actual completion time is 90 hours !!! Very strange. Perhaps a blackhole on transmission !
Who can explain ???
Estimation about total calculating time
)
The issue is that you haven't completed enough of the new S5R2 workunits for the Duration Correction Factor (DCF) to be accurate. DCF takes a look at the actual runtime of a unit and then that gets applied to the benchmark to try to more closely estimate runtimes. If you do a few units, the estimated times will get get closer to reality...
RE: RE: I connected to
)
Thanks for the explanation.
But I repeat , i asked WU for 48 hours. I have run the benchmark BEFORE request work .
Now, I have wait one day to see the difference. After 21h of work ( run always) , and completion of 38%, the time to completion is still. I am now at 59 hours !!! Great !!! 21 hours work and 38% later, the time only decrease from 1 hour !!! I let you calculate the estimated needed time to end of one WU !!!
It will say, i can not make planification about connection. Because the configuration, I can not allow 300 computers to stay connected at the same time through the proxy and open a port permanently!!
So, I will finish the WU and leave this project.
Sorry
[img]http://boincstats.com/signature/-1/user/8912/sig.png[/img]
RE: But I repeat , i asked
)
The way the work requests work is the request is based upon the benchmark and the DCF. I am set for 3 days via preferences. 3 days = 72 hours. Due to the DCF not being accurate at first, when I connected I retrieved 4 units at an estimated 20 hours a piece. That's 80 hours and is, more or less, what my work request was... Reality is that the units run 25-26 hours, so I actually got over 4 days of work. The next time I request work, the more accurate DCF should cause me to only get 3 units assigned to me.
What likely happened in your case is that your DCF was significantly below 1.0. 1.0 means the benchmark is accurate. If you have a DCF of 0.8, then that is saying, in simple terms, that the actual runtime is 80% of the benchmark. The problem is that the new science application is not optimized, so if you did have a DCF of 0.8, then your runtime estimate would be very low for the new units. Conversely, if your DCF was significantly over 1.0, the initial estimates may be very high and you may find that the completion estimates drop rapidly during the course of the run.
As for the rest of what you posted, I'm not sure if you're complaining about the size of the work units or the speed at which they run. Yes, they are very slow right now. The claim by the project team is that they will work on speeding things up sometime in the future.
@travail: Just to clarify
)
@travail:
Just to clarify one point Brian made. RDCF is tracked for each individual project you're attached to, and when you first attach a host to a project BOINC assumes a default of 1 for it (IIRC).
The benchmarks are known to be notoriously non-representative of how your host will perform on a real world WU, therefore since all BOINC has to go on for the first results run are the benchmarks the estimates for completion times are virtually worthless. Therefore just because you run them before request work makes no difference to how accurate the first request will be
As Brian mentioned, once the host builds up some track record by completing some results, BOINC will compute a new DCF for it on that project and the runtime estimates and work requests will get closer to the mark.
Regarding your last comment, I'm not sure what you're driving at there. BOINC does not open an external connection to anything unless it needs to except for the GUI RPC port, which is a listening port. Even then that's only externally exposed if you have remote RPC control enabled.
The port it opens when it needs to connect to a project is only open for the duration of the session with the project and is then closed and the socket released.
The only thing I can think of here is if you were DL'ing the initial datapacks and app files to a lot of hosts all at the same time it might seem like you were 'permanently' opening up ports on the proxy, but that's not the case in fact.
The workaround for that is to not attach all of them at once so they don't all hammer the proxy at the same time.
Alinator
Tks for your explanation.
)
Tks for your explanation.
Only one precision : I am not a new BOINC user .
My total credit on Seti is about 562,000 credit.And about 400 WU each week !!!
So BOINC can calculate accurate !!
By the way , i requested WU for 2 days and receive for about 8 days !!!
Now, I am working only on Seti, but due to the crash, i have join Einstein. Of course, Seti is now disconnected from my running Boinc ( run always, with no limit on use of CPU).
By the way thank you for yout replies.
Philippe
[img]http://boincstats.com/signature/-1/user/8912/sig.png[/img]
RE: By the way , i
)
I know... That's what we're trying to explain. If you go to your account info here and look at your computer, down towards the bottom there will be a Result duration correction factor. What is that number? Mine is currently 1.298434. My guess is that yours is either going to be exactly 1 or less than 1.
BOINC can calculate accurately, but it needs some help because different projects are also different in how they perform due to different types of calculations in each project...
Remember I initially requested 4 units at approx 20 hours each, which is as close to the 72 hours of work that I specified as it could get, as 60 hours would be too little. I remember looking and seeing my DCF was at 1 (perhaps because I reset project, not sure). If I take my DCF and use it to adjust the estimate, here's what I get:
Initial Benchmark estimate * DCF: 20hrs * 1.298434 ~= 26 hours
Now when I request work, the scheduler will know that each unit takes 26 hours instead of the initial estimated 20 hours, so 72/26 ~= 2.77. Rounding up, it will send me 3 units for a total runtime of between 78 and 80 hours, instead of what I got the first time, which was over 100 hours of work...
Brian
Edit: Disclaimer - I know this is a simple example and does not take into account the variable sizes of the S5R2 units. I'll find out exactly what happens when I request work again sometime on Saturday morning.
RE: RE: By the way , i
)
Hi Bryan
Once again thank you for your patience
A few precision :
On Einstein, correction factor is 1 !!!
If I follow your explanation, how higher, how more accurate ???
But on Seti, my CF is 0.52 !!! And when I request 400 hours, i also receive it ( more or less ) but all the work is finished into about 75% of the time .
Here, it is just the reverse situation!!
And my computer is at the 38th place at average !!!
Now, If i follow your explanation, a CF of 1 will normally result the normal time to completion !!!!
Of course all the numbers are rounding.
But then with a CF of 1, i can not explain why , when I ask 48 hours, i receive 200 !!! If the CF was about 0.24 or 4.1 i can understand !!!
I repeat, all rounding !!!
Now, i have limited the preference on 2 days and also the cache. But i received WU for 800 hours. I repeat eight hundred hours !!!!!!
It will say 33 days !!!! With also deadline on 25 may ( in 14 days )!!!
Very nice " F " correction factor. Of course, i delete all of it . I have no choice !!! I ask work for 2 days, receive for 33 with a dead line of 11 !!!!
If someone can explain, ....................
Or perhaps Einstein will offer me a QuadCore at 2.66Ghz !! ( I also accept a 2.4Ghz/8MbCache ) !!!
Then, i will stay !!! Keep smiling !! Thank you Albert !!!
I only want to understand why !!!
Of course the first goal is to help on research.
With hope on answer,
Greetings from Belgium
Philippe
[img]http://boincstats.com/signature/-1/user/8912/sig.png[/img]
RE: Now, i have limited
)
I've tried to explain... :-)
When you attach to a project or reset a project, you get a default RDCF of 1. This means that when you first run a project, it assumes that the benchmark is a completely accurate measurement for completion times. This is a potentially flawed assumption as the BOINC benchmark is not always reflective of the actual performance levels of the science applications, so the developers came up with the per project RDCF correction to assist in projecting estimates.
When you intially attach to a project, the benchmark is assumed to be "accurate", but it may not be... I put "accurate" in quotes because until you've run a few units, BOINC has no way of knowing if it is really accurate. If you previously had one for S5R1/S5RI, it was based on the benchmark and then an optimized science application. The current science application is not optimized, so it takes considerably longer than the previous application. Also, again bear in mind that a DCF for your individual computer is implemented per project. DCF is computer-specific, not project-specific, meaning my DCF in Project A is not neccessarily the same as your DCF in Project A. That's why you have to complete a few units for each project you attach to for the scheduler system to learn what the DCF should be for that specific project.
In other words, due to the change to S5R2, the correction factor had to be "relearned". What you experienced in downloading more work will only happen this first time...unless you do a reset project, then it will have to learn all over again.
Also, your experiences at SETI are probably because you're most likely using an optimized science application and you've had enough units performed so that the DCF is accurate. Right now the DCF you have for Einstein is not accurate. In time, if you're willing to wait, it will be accurate. If you're not willing to wait, then I suppose I wish you the best, as I don't know how to explain it better... :(
Just updating... I
)
Just updating... I requested more work and got 4 units again, but with estimated times of 21 hours. Again, this is more than what I expected (3 units), but I also stated that there are variable runtime units being generated now, so getting 4 is not unreasonable. 4*21 = 84. 3*21 = 63. Apparently the system errs on the side of giving slightly too much work than too little.
RE: Just updating... I
)
The server can not give half a task, so if 3 tasks leaves you 1 second short of your request you will get the fourth one. This assumes there is not some other reason not to send the additional task.
BOINC WIKI
BOINCing since 2002/12/8