FGRP3 new release experiences
24 Jan 2014 16:44:50 UTC
Topic 197354
(moderation:
I infer from this post in Technical News that FGRP3 work is quite recently issuing in quantity with revisions.
I got work on two hosts, and artificially moved a task on each to immediate execution to observe behavior. It may be relevant that I have not previously been running FGRP2 on either host. In any case, my observations are that on both hosts the FGRP3 job took far longer to run than the forecast, and that consequently greatly increased the completion time estimates for all other work on the machines (CasA on both, and Perseus on the GPU-equipped one). One of the hosts has a very small queue setting, so no readily observed effect, but the other host went into "panic mode" and currently imagines itself to have 21 days of CPU work and 28 days of BPU work (it actually has about 5 days each).
Lastly, it appears that I am to be awarded 80 credits for these jobs, which is vastly below breakeven with CasA work.
Possibly all this arises from my work having been issued before the late-in-the game flops estimation tweak mentioned in the official post.
Here are links to the two hosts, and to their recently completed tasks:
I am just trying to make a helpful report, and not begging for adjustment of what is already past.
FGRP3 new release experiences
)
That announcement also mentioned that the expected run time would be about 75% of that for the FGRP2 tasks. I've allowed a couple of machines to get #3 tasks and can confirm that they do seem to be doing just that.
In my case, the new tasks were predicted to take approximately the same run time as FGRP2 tasks. Seeing as they take only 75% of that, there will be an increase in DCF 'see-sawing' for those hosts that are running FGRP on the CPUs and BRP5 on the GPUs. With FGRP2, the real run times were invariably shorter than the estimates for a whole range of (relatively modern) CPU types. With BRP5, the real times were slightly longer than the estimates. As tasks of each type finish, BOINC would adjust the DCF in opposite directions for each task type - DCF 'see-sawing'. I'm not running any CasA tasks so I don't know how their run times compare with estimates. Seeing as Bernd mentioned "preliminary final adjustments", I presume that better estimates (through further adjustments) will be made once enough data has been accumulated.
I've seen something similar when I was adding GPUs to existing CPU only hosts. In my case, when BOINC restarted after adding a GPU, benchmarks would be recalculated and BOINC would come up with some crazy values for estimated crunch times. I never did bother to try to work out what was causing this but in each case the DCF was massively distorted so the quick fix was to stop BOINC, adjust the DCF back to 1.0 (or whatever the normal value was) and restart BOINC. End of problem. You should be able to do much the same.
Why do you think it will only be 80? It was 880 for all 'full-running' FGRP2 tasks so I expect it will be 660 (880x0.75) for FGRP3 'full-running' tasks. Bernd has previously mentioned 'corner cases' which are shorter running and the credit is reduced accordingly.
I wouldn't think so. I would think the mentioned tweaks were done before any 1.09 tasks were issued.
Edit: I was a bit concerned about your "80 credits per task" comment so I did a bit of digging through tasks lists of quorum partners until I found an example of a validated FGRP3 WU. Sure enough, only 80 credits were awarded. The original short running FGRP2 single tasks (quite a while ago) did indeed attract 80 credits. Larger tasks (11x the size) were created which gave 880 credits. FGRP3 seem to be taking 75% of the large FGRP2 tasks so obviously they should get 660 credits. I suspect that this has been overlooked for the setup of FGRP3.
Cheers,
Gary.
So far so good. Only noticed
)
So far so good. Only noticed that the last part file of the wu takes about 4 times the amount of time than the previous part files of that wu. Also cpu temp is up for the duration of that part file. Maybe extra time and cpu is needed to do some extra computations to complete the wu.
RE: ... last part file of
)
Take a look at what Bernd posted - particularly the second point in the list of "features" - in his opening post. I've seen one task that finished quite quickly and another one where the final ~0.96% (this seems to be the approximate 'step-size') took nearly 40 mins.
Note the comment about no checkpointing during this stage. I've made a mental note not to disturb things if a task is within 1% of finishing :-).
Edit: I've done a few rough calculations regarding the display of progress for running tasks. For FGRP2, there were 220 'sky points' per task so the progress of a task was displayed in steps of 100/220=0.454%. For FGRP3, there must be 104 sky points per task since the progress is stepping by 0.962% - 100/104=0.9615.
For FGRP2, follow-up calculations were done every 11 sky points and were not as sensitive (and therefore not as noticeable) as those for FGRP3 which are all being done right at the end. We are probably going to get a few questions about why it's sometimes taking sooo loooong to finish off that last 1% :-).
Cheers,
Gary.
RE: Note the comment about
)
What happens if you have to exit Boinc at that stage of the file? Let's say: turning of pc for going to work. Are there chances you loose the file, or the last part starts from the beginning?
You only lose the work done
)
You only lose the work done since the last checkpoint was recorded. At most times during the processing of a task, that could amount to a small number of minutes at most. It could amount to a few tens of minutes if processing is at the 99%+ stage.
Cheers,
Gary.
Thanks Gary. That's a relief.
)
Thanks Gary. That's a relief.
My i7 has finished 3 grp#3,
)
My i7 has finished 3 grp#3, all in the range of 56-57k sec. 8 more in progress, also on different systems.
2 Albert cpu wu's finished on an old AMD Athlon X2 4600+ in ~ 55k sec, one OpenCL ati in ~ 18k sec.
Checkpointing in the last phase would be very helpful!