At present I can only download 2 wu's at a time and they immediately go into high priority.
This is because the time to completion starts at
staggering 350hrs, of course the units complete in the correct time, usually about 35 mins, but subsequent time to completion does not adjust itself accordingly.

Is there a way to adjust this manually?

---

Yep, check the duration_correction_factor (TDCF) for MW in the client_state file. My guess is you will find that it is at some relatively large number.

Then edit it to some more appropriate value for the current work. From the numbers you gave, something around 0.500000 (the number has to have six places after the decimal point) should be about right, but you can always go back in and change it again if the estimates aren't what you expect when you restart BOINC. As long as you aren't set to carry a large cache of work, if you go too low for the TDCF that isn't a big deal. The CC will make a fast up correction if you get too optimistic for the value you plug in.

The alternative is to just leave it alone. The CC will adjust it down slowly over time, but it takes quite a few tasks to be run to move it down a large amount.

Alinator

thanks i'll give it a try...........

the duration_correction_factor = 76.267146

---

BOINC manager also gives me unreasonably large times to completion for MW. Checking the client_state file, I found the duration correction factor = ~27. I changed it to 1.000000, but after a few minutes, it gets bumped back up to 27 again. Is there some trick to getting a lower number to "stick?"

BOINC manager also gives me unreasonably large times to completion for MW. Checking the client_state file, I found the duration correction factor = ~27. I changed it to 1.000000, but after a few minutes, it gets bumped back up to 27 again. Is there some trick to getting a lower number to "stick?"

Yes. Close BOINC, edit the file, then restart BOINC again. Otherwise, it'll just overwrite your changes.

---

I'm making this sticky since it seems to be a common problem since the switch to the new version of the application/assimilator.

---

I now have an about right Time to Completion and it is steady, however cannot
account for the constant running in High Priority, even after running the
cache empty, cache, well, I've managed to get 2 wus at a time since yesterday.

---

I have reset the project but still have wu's running in High Priority?

---

Hello,

i have the same problem. i use BOINC Client 6.2.19 and i have WinXP64. The Duration Value is 0.753212 now.
This problem come with the new application "MilkyWay@home Optimized .x"

eminator

The way I fixed this was to set MW to no new work to run the cache out, update the project to upload all the completed work units, detach and then reattach. This still gave a high time to completion figure, but it was a lot lower than before and, after a couple of days, it adjusted to the correct time to completion.

Before that, three of my four boxes were running MW at high priority all the time; afterwards, the MW work units ran at normal priority.

It's not very elegant, I know, but it did work. :-)

HTH,

Rob.

I have reset the project, so I will give a detach /re-attach a try.
I have 6.2.19 running on a Win2k system with no High Priority, so
I'm not convinced that it's purely down to the Optimized .x suggested by eminator,
but maybe a combination of factors.

---

OK, now that you have the TDCF back in the right ballpark, don't forget that MW is by far the tightest deadline BOINC project. One thing to keep in mind here is that in order to accommodate the folks who have dialup or truly intermittent network connections, the CC is designed to make sure that all tasks onboard will be completed at least:

Connection Interval (CI) + 24 hours

Before the deadline comes up. In MW's case, the effective deadline is just 48 hours minus whatever you have the CI set to.

Therefore, if you run MW with any other project and carry virtually any extra work in the cache, you are going to see MW tasks going into HP/EDF frequently.

For example, I have my CI set to 0.01 days (about 15 minutes) and have a Extra Cache setting of 0.125 days (3 hours) and run three or four projects at equal shares on all my hosts. Even for my fastest host, this results in MW tasks going into HP/EDF fairly regularly.

However, this is no big deal. Since the CC tracks the extra time spent on MW, it will shut down DL's from the project periodically so the others can catch up for the time. IOW, given some patience your Resource Share is honored as well.

<edit> @ niterobin: Yes, in this case a detach (or reset) helps fix the problem because this will reset the TDCF to 1 (it also resets the debts for the project to zero).

However, for most modern hosts this is just a partial fix, since the actual TDCF will ultimately end up less than 0.5 ( a lot less in some cases). ;-)

Alinator

<edit> @ niterobin: Yes, in this case a detach (or reset) helps fix the problem because this will reset the TDCF to 1 (it also resets the debts for the project to zero).

However, for most modern hosts this is just a partial fix, since the actual TDCF will ultimately end up less than 0.5 ( a lot less in some cases). ;-)

Thanks for the info - that explains why it works. :-) Truth be told, I just didn't know what else to try, and I don't like changing stuff in the config files as I'm not too sure what I'm doing there.

That may well be so, but on one of my boxes I am currently only running MW, well not strictly true, I do also run FreeHal but that is only one wu at a time!

OK, now that you have the TDCF back in the right ballpark, don't forget that MW is by far the tightest deadline BOINC project. One thing to keep in mind here is that in order to accommodate the folks who have dialup or truly intermittent network connections, the CC is designed to make sure that all tasks onboard will be completed at least:

Connection Interval (CI) + 24 hours

Before the deadline comes up. In MW's case, the effective deadline is just 48 hours minus whatever you have the CI set to.

Therefore, if you run MW with any other project and carry virtually any extra work in the cache, you are going to see MW tasks going into HP/EDF frequently.

For example, I have my CI set to 0.01 days (about 15 minutes) and have a Extra Cache setting of 0.125 days (3 hours) and run three or four projects at equal shares on all my hosts. Even for my fastest host, this results in MW tasks going into HP/EDF fairly regularly.

However, this is no big deal. Since the CC tracks the extra time spent on MW, it will shut down DL's from the project periodically so the others can catch up for the time. IOW, given some patience your Resource Share is honored as well.

<edit> @ niterobin: Yes, in this case a detach (or reset) helps fix the problem because this will reset the TDCF to 1 (it also resets the debts for the project to zero).

However, for most modern hosts this is just a partial fix, since the actual TDCF will ultimately end up less than 0.5 ( a lot less in some cases). ;-)

Alinator

---

Is there a reason why the stripe_79's are taking longer? I am getting 105-100 min now, up from 75 when the new code came out. And getting the same credit for longer work. Why is the credit keep getting lowered?

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I've used the excuse of upgrading to BOINC 6.4.5 as an attempt to sort this High Priority and it has worked. Downloading max units per processor and more importantly no High Priority.

---

Yes I use 6.4.5 on one machine & 6.2.16 on my other one, the one with the new version doesnt go " High Priority" at all,the older version was going "High Priority" all the time, but I've noticed that the older version has also started to run in normal mode in the last couple of days.Hope it has fixed itself.

---

I've noticed that MW sets the same deadline date on all workunits. The expected work quantity within each is not reflected in the deadline at all. It's not an issue for a short duration WU, but quite a different matter when the projected duration is more than the hours available until deadline. I'm finding myself manually aborting quite a few lately due to this issue.

I've noticed that MW sets the same deadline date on all workunits. The expected work quantity within each is not reflected in the deadline at all. It's not an issue for a short duration WU, but quite a different matter when the projected duration is more than the hours available until deadline. I'm finding myself manually aborting quite a few lately due to this issue.

Since you have your computer(s) hidden, we cannot look at an example of what you're talking about. However, what you seem to be describing is BOINC's projected time vs. actual runtime. This can get out of whack from time to time and it is what Alinator mentioned about checking the value for duration_correction_factor for Milkyway in client_state.xml. As you process more tasks, this will become more accurate. For my system, all Milkyway tasks I am processing run between 40 and 45 minutes. BOINC's estimate is around 42 minutes, so it's pretty accurate. I am not getting any variation in task runtime either. I do not know if there are longer running tasks out there right now.

In any case, since I can only get 8 tasks at any given time, 8 x 45 = 360 minutes = 6 hours of work. My system has no problem completing ~= 6 hours of work within 3 days. My system runs the MW tasks through first ("Earliest Deadline First" / "High Priority"), which doesn't get me all upset because I'm not overextended on other projects...

Without examples, I don't know what more can be said... :shrug:

Hi folks,
most of my wu are taking an hour 25 then got a few that will take 2.30 and the latest only an avg of 50 sec was wondering if there was a problem or if any one had an idea why this would happen??
Thanks
Glenn

---