Detaching. I have no option to detach, remove is greyed out and right clicking on the projects yields nothing. After review of the FAQ I have come to the conclusion that this project wants to exclude windows users, there are over 11k of projects for Linux platforms and exactly 0 for windows. It has been like this for some time and I'm sure there are other boinc projects that will be glad to make use of my unused computing time. I have made use of the options to stop getting work but I'd like to get it off my computer. Anyone else know how to get this done?

If the option is greyed out, then you attached by means of a different Manager, perhaps BAM! If so then you MUST use the same manager to disconnect.

*****************

The project has been down for nearly 3 weeks, due to a major infrastructure failure in the cabinet housing our servers. One week for the company to rebuild/replace the hardware and for the IT people to bring the software back on line, 3-4 days of people uploading their backlog of files, and a week of firmware updates, and to bring the software back up again.

During this time no new data sets were even considered for loading onto the servers. Hopefully the last few problems will be fixed early in this coming week.

New models for new areas have been under test in the beta site recently, and when some bugs have been fixed, this should result in more work, mostly for Windows.

This post should be read in relation to what model types get work on a given OS.

This project has 3-5 times as many computers wanting work as there are data sets to run. And it most likely will always be this way.

The reason that those 11K Linux are still on the server after about 6 months is the Penguin hasn’t been able to get them done. Problem with incapabilities between 64 bit versions of Linux and the 32 bit nature of CPDN have caused many crashes and the need to reissue the same tasks over and over again. In the mean time, Windows machines has successfully crunched its way through 30,000 to 40,000 tasks. So the Windows cubby is bare while there is still a lot of work for Linux.

---

> Problem with incapabilities between 64 bit versions of Linux and the 32 bit nature of CPDN have caused many crashes and the need to reissue the same tasks over and over again.

Seems an old story re: 32bit program failures on 64bit Linux machines. It's hard to believe Linux users would be unaware of the 32b on 64b issue. When I decided to run CPDN on Linux, the requirement for having 32bit libs was quite obvious.

Which 32b libs was a bit of a puzzle, but I solved this by installing all of the suggested Ubuntu lib32* packages (and a number of others just to be sure). After that it worked fine.

Actually, until the 32b libs were installed the CPDN models wouldn't even download/start, so I'm not understanding how lack of the libs causes a "compute failure" (unless the request for work itself counts as a failure when 32b libs are missing).

Ultimately the backlog of Linux tasks reflects having too few usable Linux computers in the pool. Not sure what inhibits creating tasks as 64bit binaries, but given the predominance of x86_64 these days, it seems it would be the effective solution.

Actually, until the 32b libs were installed the CPDN models wouldn't even download/start, so I'm not understanding how lack of the libs causes a "compute failure" (unless the request for work itself counts as a failure when 32b libs are missing

Unfortunately the system isn't clever enough. Lots of people have missing libs and still download work which then fails within about 6 seconds. Many of these people have adopted a, "set and forget" attitude to using BOINC and don't notice. Recently a user with 64 cores was identified as downloading a work unit a day for each core which then promptly failed. When identified, work is stopped for these boxes and an email sent out to the address associated with the account but it is taking a long time and I suspect more non working linux boxes may be getting added than are being identified!.

One problem is there are so many kinds of Linux and the fact that major updates occur so often. The Compatibility Lib that worked with the last “flavor” of Linux you ran may or may not work with the new one.

One problem is there are so many kinds of Linux and the fact that major updates occur so often. The Compatibility Lib that worked with the last “flavor” of Linux you ran may or may not work with the new one.

Actually I have found the procedure consistent over the past few years with a major upgrade twice a year on Ubuntu.

One problem is there are so many kinds of Linux and the fact that major updates occur so often. The Compatibility Lib that worked with the last “flavor” of Linux you ran may or may not work with the new one.

Actually I have found the procedure consistent over the past few years with a major upgrade twice a year on Ubuntu.

Twice a year! Can you imagine the chaos that would ensue if they brought out a new version of Windows every 6 months.

---

My Windows 10 is being updated every month, so I have to suspend all BOINC work on it. I have also to restart manually the CERN 2015 Challenge running on Virtual Box after every reboot.
Tullio

---