This reminds me of some other project's trick. They grant additional credits if tasks are returned within X days to disincentive excessive hoarding.

Back when my machine could always get work from CPDN and WCG (and Seti@home), I had at least 0.35 days of work and about 0.65 days additional work in my preferences. Now that Seti@home is gone, WCG is sort-of back up, and CPDN is erratic in work availability, my machine is set to at least 0.50 days of work and 1.5 days of additional work, and that 1.5 days is not really enough. When the upload server went down, I mostly let my machine keep crunching and I got around 20 completed tasks before they started uploading again. I do not think of that as hoarding. IIRC, some of the more recent "classical" CPDN work took around 8 days to complete a task, and in the distant past (and on slower machines) tasks could take several months.

But I do not think, with the new Oifs tasks, there is much point grabbing a month's supply because they would time-out before I could get around to them. I usually leave my machine up 24/7.

xii5ku wrote:

Hardware requirements for current "OpenIFS 43r3 Perturbed Surface" work:

The following items need to be taken into account, in descending order of concern:
1. Upload bandwidth of your internet link.
2. Disk space.
3. RAM capacity.
99. CPU. This one doesn't really matter, except of course that CPU core count has got an influence on how many tasks you may want to run in parallel, and that core count × core speed influences how many tasks you can complete per day at most. One or both of these factors (concurrent tasks, average rate of task completions) influence the sizing of items 1…3 in this list.

Note, I bolded one word in the first sentence after the fact.

This priority order has been criticised here. I admit that my perspective is somewhat biased, as I am owning several computers with relatively high core count and high computational throughput and am used to be able to fully utilize them. (Although that's not always trivial to accomplish, because many BOINC projects are focused on low core count/ low throughput hosts.)

However, given how the current "OpenIFS 43r3 Perturbed Surface" campaign is going so far, my priority list is – empirically; refer to thread 9167, thread 9178 – indeed quite generally applicable.

... I was sooo happy the CPDN had an abundance of jobs and joined the party - only to then find out I can't get rid of my results.
Two machines crunching, two harddrives slowly filling up.

Thanks, that's funny. :-) Initially it's "Where's the work?!", now it's "How do I get rid of the results?!"

I know and I feel you. The non-math projects have been dwindling over the years. WCG used to cover a whole lot more but these days are just two medical projects with ARP occasionally trickling in. The migration off IBM certainly didn't go well. The projects I added in recent years (asteroid, universe, LHC) are all because at some point, all projects I contributed to run out of work. Among the long list of math projects, I have yet found anything I can remotely relate to. In addition, for winter, I'd rather run my computers than turning on the heater.

Still though, BOINC or any projects are generally not run as a high availability service. That requires a level of funding and expertise that are generally not available to researchers and that's also a very different focus compared to science research. Sure we contribute compute power at our own cost, but I personally don't consider that enough to justify expecting people to troubleshoot during holidays.

The one computer that I tried to run these on failed all 8 tasks with segmentation violations. Looking at those work units, a couple of those work units had all 3 tasks fail with segmentation violation errors, a few had all fail for various errors, and a couple work units had one of the tasks progress and produce trickles, including producing trickles on another Linux PC. Quite odd.

Which machine are you talking about? You have eight Linux computers attached to the project, and one Windows computer.

The Windows computer will be unable to contact the project at this time, because of a security certificate expiry in the ca-bundle.crt file. Wait for a new Windows client to be released - I have no idea of the timescale for that at the moment - or explore the workrounds being discussed on the BOINC message board.

Site been Pownd?
Sorry to think so, maybe?
Can't attach to project.
All on this thread speculate ssl problems.
Tried those fixes
No help.
WTF?
Also -- checking local wu records vs website records -- big mismatch for wu's last few months
Or have I just lost my mind?
HELP!

WU hadam4_a16s_201310_6_914_012099105 is showing as abandoned on my task list, but it is still running on the VM (Ubuntu, computer ID is 1493840). Should I really abort it on that VM, or can the status be changed to "In Progress"?

Steve

Thanks for adding that. I have in fact had "Leave non-GPU tasks in memory while suspended" enabled on my boxes for many years. The measures I have outlined are in addition to that.

Not sure whether something has changed in the tasks or in more recent incarnations of BOINC but of late even when I have had restarts due to power failure, (electrician turning mains off without warning) I haven't lost tasks to it. Something has improved but I don't know what.(Over I would guess last 9 months to a year is an approximate time for the change.)

The 32bit libraries is not a problem unique to CPDN. It is an issue for a number of projects under Linux. With CPDN the issue is with something like a million lines of Fortran which has been compiled sorting out a 64bit version of programs from the met office without the source code or a license that allows mucking about with it even if we had the source is a far from trivial task even if the project had programmers with the necessary Fortran knowledge.

Sorting it out for other projects some of which may have written their own code would I assume be easier, even if they haven't seen the need to do it yet.

At some point there will probably be OpenIFS tasks for Linux and Mac which are 64bit and should, "just work." The ones which crashed during testing were problems with ancillary files as I understand it. That and file size limits being set too low in some cases. Then of course there is just the sheer complexity of climate modelling that means mistakes are more likely. Most get caught by the testing branch but not all.