Thanks for the warning, I had one of those too (that's why I entered the forum).

It has been at 67.10% / 22:20 hours, the time increasing, the progress did not.

After a full BOINC restart, the time went back to 02:19 and the progress immediately increased to 67.18%, it seems to run fine from this point.

So it obviously hasn't done anything for ~20 hours, including not writing checkpoints and stuff.

I didn't backup slot and project folder so I cannot see the last modification times before the restart anymore.


p.s.: the workunit is this one : https://secure.worldcommunitygrid.org/ms/devi...us.do?workunitId=35866695
my result name is lv893_ 00002_ 7--


p.p.s.: I don't think that suspending the project would have helped in my case, as I leave apps in memory while suspended


p.p.p.s.: Quadcore Q9450, Win2k server, 3.2GB RAM (4GB installed but no r64 OS), BOINC graphics disabled.

Hmmm ... it doesn't do that for any other project on my boxes, so it must be a special feature of either BOINC 6.x or WCG


There was a benchmark while that WU was running, yes. No throtteling (it's a headless cruncher), CC 5.10.28


I'm using BOINCview and have set it to alert me when not enough CPU time per wallclock time is used - but a "no progress" alert wouldn't work as some projects have a quite jumpy progress. Yoyo Muons (the quickest runs) have only 1/3 and 2/3 progress - it would alert me all the time there.

I did see that % was stuck but I assumed that it has to be like that, HPF jobs on FaD used quite some time too - but then I saw that many of my wingmen had finished the complete thing already and my box isn't what I would call a slug ;-)

Now that is very interesting.... seen related reports at Berkeley where one or the other freeze occurred and also armstrdj, one of the WCG programmers asked that question earlier.

At one time I thought that it might be also of use to

1. Time the Benchmark to fall in a checkpoint, but was 1 core minded and thus does not work in the real world of dual/quad/octo

Do think it could help

2. Switch LIM off and extend the Project Time slicing to 240 minutes. The Benchmarking is I think these days not causing an offload like it did under 5.4 and causing Checkpoint Resume. Most many have enough ram these days to not have excessive disk i/o, so does LIM still have a valid right to be?

[edit: spelling)

Well that one I'd not thought about, but surely you know it runs once every 140 hours wallclock time. If you are hands on managing your projects, force the update prior to running WCG. Then it's one item excluded as being a potential source.

Meantime we'll highlight this to the programmers. Something in BOINC, but given it's 9 out of 10 a HPF2 that gets reported, it may the particular combination.