Thanks again Les. You are ever helpful in explaining the vagaries of the system.

However, the AFR models I downloaded at the beginning of January seem to mis-estimate the run time. About halfway through (about 6 trickles out of 12), the original estimated time has already elapsed and the Remaining time actually starts to increase!

I've not seen that happen before.

Errors in the time remaining counter aren�t uncommon. They are also harmless and don�t effect the outcome of the tasks. The hadam3p_afr currently running on my machine is going to take about 200 to finish. The time remaining counter reads 72 hours and the �elapsed� counter is at 28. It will probably reach �0� at the 50% point.

... not entirely harmless. In a mix of model types the AFR models when run will tend to inflate the estimates for other model types, which means that the host's work buffer will not be filled correctly. This is happening on a machine of mine at the moment.

If it's any consolation, the mis-estimate had been reported to the project - as has the too-generous credit allocation for that model type. No response on either question thus far.

[/quote]
... not entirely harmless. In a mix of model types the AFR models when run will tend to inflate the estimates for other model types, which means that the host's work buffer will not be filled correctly. This is happening on a machine of mine at the moment.

If it's any consolation, the mis-estimate had been reported to the project - as has the too-generous credit allocation for that model type. No response on either question thus far.[/quote]

I see what you mean. The time estimate for hadam3p_anz that are waiting to start have increased by 15 hours and hadam3p_pnw by 8 hours. I don�t think this is a serious problem. I might have to wait a day or so longer to get new tasks.

---

Hmm, does the Africa-application have the same fatal bug as the PNW-application, with landing in the "crashes 100 times before giving-up", or is it something else going-on with just some bad wu's?

... not entirely harmless. In a mix of model types the AFR models when run will tend to inflate the estimates for other model types, which means that the host's work buffer will not be filled correctly. This is happening on a machine of mine at the moment.

If it's any consolation, the mis-estimate had been reported to the project - as has the too-generous credit allocation for that model type. No response on either question thus far.
[/quote]

Has this been corrected on the latest batch of AFRs? The estimated times on all my tasks have been more than doubled since I completed an older AFR task.

... not entirely harmless. In a mix of model types the AFR models when run will tend to inflate the estimates for other model types, which means that the host's work buffer will not be filled correctly. This is happening on a machine of mine at the moment.

If it's any consolation, the mis-estimate had been reported to the project - as has the too-generous credit allocation for that model type. No response on either question thus far.

Has this been corrected on the latest batch of AFRs? The estimated times on all my tasks have been more than doubled since I completed an older AFR task.

... if you run only AFR the run-times will tend to the correct value through the application of BOINC's normal per-machine adjustments. A mismatch only arises where there is a mix of model types. For example, running ANZ/EU/PNW will make AFR models seem "cheap" and you will get "too many" of them; if you then run AFR models you won't initially get ANZ/EU/PNW because they will be judged "expensive" - when there's a big enough work deficit then the ANZ/EU/PNW will indeed download but you will get "too few" of them.

The hadam3p_afr WU�s have completely screwed up the time remaining estimates. Since I completed 1 _afr task the day before yesterday all other task estimates have more or less doubled. Hadam3p_anz tasks that take about 200 hours on that machine are reading 478 hours. Hadcm3n tasks are reading over 1000 hours, when I know form experience that they take about 475 hours. Every other type is about double there former estimates.

As these tasks run will they self-correct or do we need to edit the files somehow to fix this. And is there a fix in works for the hadam3p_afr so it doesn�t do this again.

---

The hadam3p_afr WU�s have completely screwed up the time remaining estimates. Since I completed 1 _afr task the day before yesterday all other task estimates have more or less doubled. Hadam3p_anz tasks that take about 200 hours on that machine are reading 478 hours. Hadcm3n tasks are reading over 1000 hours, when I know form experience that they take about 475 hours. Every other type is about double there former estimates.

As these tasks run will they self-correct or do we need to edit the files somehow to fix this. And is there a fix in works for the hadam3p_afr so it doesn�t do this again.

All that will have happened is that your DCF (Duration Correction Factor) for this project will now be attuned to the AFR estimate, rather than the estimates appropriate to the other model types.

DCF is a BOINC tool designed to avoid tasks missing deadlines. As such, it isn't of much importance to CPDN, but it still exists. To avoid those deadlines, DCF is pessimistic - it assumes the worst possible case. So, the moment it sees a task running longer than estimate, is assumes that every task will be as badly behaved.

As new tasks finish in shorter than the expected time, DCF will automatically be adjusted back down again - but more cautiously, at just a 10% adjustment each time. The graph is like a sawtooth.