Message boards :
Number crunching :
504 Hr work time!?
Message board moderation
Author | Message |
---|---|
Send message Joined: 4 Nov 11 Posts: 3 Credit: 66,301 RAC: 0 |
One of the work units I received in the last update has an estimated completion time of 504 hrs and 45 min, is that normal? |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 528,817,480 RAC: 564,695 |
One of the work units I received in the last update has an estimated completion time of 504 hrs and 45 min, is that normal? No, that doesn't sound right. I would guess that the client calculated the estimated time incorrectly. If you give me a link to the WU, I could look at it closer. Thanks, Eric |
Send message Joined: 28 Oct 11 Posts: 180 Credit: 252,038,814 RAC: 179,496 |
One of the work units I received in the last update has an estimated completion time of 504 hrs and 45 min, is that normal? It depends what you mean by 'normal'. Looking at your computer, and specifically the Application details for host 1491, it's clear that you haven't done any work for this project for a little while. As a result, all the tasks you received this morning used applications that your computer hasn't run before - one task for "Get Decics with Bounded Discriminant v2.04" (which you've completed), and three tasks for "Get Decic Fields v1.01" - these will be the ones with the badly-estimated completion time. Because this is the first time you've run these applications, the server doesn't have any information about how well the tasks run on your machine. But your machine itself will have some knowledge of the project in general, because of the 'bounded - v2.02' jobs you've run in the past. I'm guessing that you've ended up with a high 'Duration Correction Factor' from that earlier run, which is skewing the estimate for the new work. The 'bounded - v2.04' tasks are notoriously variable in their run time - you got one of the quicker ones. The 'decic - v1.01' tasks are (in my experience) less variable, but in general longer: using somewhat faster CPUs than yours, I'm seeing a variation between roughly 15 hours and 30 hours - so I'd be surprised if your tasks ran for more than 50 hours in the end. Another curiosity is that these tasks usually show around 50% progress soon after they've started, then slow down dramatically. But they do get there in the end, and even speed up a bit as they approach the finishing line. In short, the "normal" thing is that the initial runtime estimate for BOINC tasks has to be taken with a pinch of salt. |
Send message Joined: 28 Oct 11 Posts: 180 Credit: 252,038,814 RAC: 179,496 |
... If you give me a link to the WU ... Click on his name, then computers - view, then tasks, to end up at All tasks for computer 1491 |
Send message Joined: 4 Nov 11 Posts: 3 Credit: 66,301 RAC: 0 |
Ok, thanks for the explanation. I'll just let the work unit run and see what happens. |
Send message Joined: 4 Nov 11 Posts: 3 Credit: 66,301 RAC: 0 |
Hello, it's me again. Just thought I'd let you guys know that not long after the work unit started it jumped to 50% complete with an estimated completion time of 60 hours. |
Send message Joined: 19 Aug 11 Posts: 45 Credit: 1,014,069 RAC: 0 |
The 2 that I have/had (on VERY slow hosts) jumped to 50% very quickly and started climbing steadily. One had got to 80-something percent and suddenly finished after around 39 hours - Got decent credit for it too, about time, I thought I was jinxed ;) The other is 71% after 45 hours, and I'm guessing it will finish at around 60 hours. Only using these old hosts for this project as they are my junk test machines with BOINC 6.10.30 and 6.12.32 which I don't want on any other machines, and I don't think this project works properly (regarding Run Time) with older versions. Al. |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 528,817,480 RAC: 564,695 |
Hello, it's me again. Just thought I'd let you guys know that not long after the work unit started it jumped to 50% complete with an estimated completion time of 60 hours. I treat each pass through the search loop equally with respect to computing the percentage complete. But in reality, the beginning and end of the search are faster than the middle. Thats why you see a quick jump (to about 50%) at the start of the search. For those who are interested in more details, read on... The core of the search algorithm uses a series of tests to filter out the candidate fields. The outer part of the search region corresponds to fields whose polynomial coefficients are larger than usual, and these get filtered out very quickly in the earlier tests. On the other hand, the middle of the search region corresponds to fields whose polynomial coefficients are smaller- these fields make it to the inner most tests which involve computing field discriminants and factoring large integers, and these tests are much more computationally intensive. |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 528,817,480 RAC: 564,695 |
Thanks Richard for explaining that. I figured it had something to do with the DCF. |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
The 2 that I have/had (on VERY slow hosts) jumped to 50% very quickly and started climbing steadily. of course you did - eric got rid of creditnew.. ;) |