Boinc

ghaverla · 2017-07-14 14:36:12

I had boinc running on the first (of 4) Debian/Jessie machines which got upgraded to Devuan/Jessie, and then got upgraded again to Ascii/Ceres.

It had been running fglrx (aka Catalyst) as it had a HD 5450 in it.

Before the upgrade, I changed settings in the manager so that it did not download new work. And it was allowed to finish all the work it had, and upload it.

I upgrade systems seldom and how to properly upgrade boinc in such a situation is not fluid in my head. I thought it would be enough to just let the existing jobs finish.

As doing OpenCL via open source has improved a lot via Mesa3D, LLVM and others, I was thinking of seeing if this HD 5450 could be made to work with the open source OpenCL system.

I downloaded the various boinc packages from Devuan and tried to set things up get it working again. At one point it had downloaded some work. But trying to get the manager to communicate with the client only worked that one time. Starting the manager from the GUI menu had different effects than starting from the command line. gui_rpg_auth.cnf was a problem. The new (on Devuan) package seems to want to start a data store in the user's $HOME, which I had never seen before.

Some of this may be the difference from Debian/Jessie to Debian/Sid. It could be something done in conversion to Devuan. I spent the day fighting things and not getting anywhere. At one point, I downloaded strace and collected a strace log of the boincmgr (23k lines). I didn't finish wading through that.

Growing frustrated, I wondered what was available from upstream. My other Debian systems are running a 7.6.x version of boinc. The boinc site has a 7.2.x package available? Sorry, I don't want to go that far backwards. Okay, over to the git and clone it. It is version 7.7, so newer than what I was working with. A few hiccups in getting dependencies of the compile going, but I've compiled much of that now. It wants to work with MySQL to be a boinc server (almost nobody needs that, that is for projects to distribute work units), and doing a quick search it doesn't look like anyone has converted to MariaDB. I have to go get farm parts today, so it will be a few hours before I can look at the results of the compile to see if that works here.

Maybe the gremlins will diffuse out of the system, and re-installing boinc from scratch again (I did it 3 or 4 times yesterday) may then work. Maybe someone with better boinc-fu than I, may happen on this note and realize what I did wrong (my old boinc /var/lib/boinc-client is still on the old hard disk if I need it) and point me to the error.

Thanks for any wisdom/comments.

--

As Red Green has been known to say, "Keep your stick on the ice.".

ghaverla · 2017-08-13 02:40:34

Hmmmm, no replies. Aka - Gord, do more work.

Okay, we'll see what happens. I've got a system move from an ATX to a mini-ITX, and a new system to go into the ATX tower. All wanting to do BOINC.

Have a great day people!

ghaverla · 2017-08-13 03:04:13

Churn on things for a minute or ten.

There were always two different problems with BOINC:
1. A user wants to run BOINC when they are logged in.
2. The system wants to run BOINC all the time (to use up cycles).

What I had on Debian, is solution 1, except that the data is kept in /var, which is a system thing.

It seems to me, that the "overview" package needs to be one, which will allow a system BOINC process to run, or allow whoever is logged in to X to run BOINC processes. And then a person installs a boinc-system and/or boinc-user packages to handle the specifics.

Easy for me to say, I have never written something like this. I think. Maybe. Sometimes. Without enough beer.

Ideas?

leloft · 2017-08-13 17:21:23

I am also experiencing Boinc problems after upgrading to ascii this morning. It appears to be related to the kernel version:

Machine 1: upgraded between Sun, 13 Aug 2017 11:14:00 +0100 and Sun, 13 Aug 2017 11:39:04 +0100 from jessie to ascii using

deb http://auto.mirror.devuan.org/merged ascii main
deb-src http://auto.mirror.devuan.org/merged ascii main
deb http://auto.mirror.devuan.org/merged ascii-updates main
deb-src http://auto.mirror.devuan.org/merged ascii-updates main
deb http://auto.mirror.devuan.org/merged ascii-security main
deb-src http://auto.mirror.devuan.org/merged ascii-security main
deb http://auto.mirror.devuan.org/merged ascii-backports main
deb-src http://auto.mirror.devuan.org/merged ascii-backports main

# Devuan repositories
deb http://packages.devuan.org/merged ascii main
deb-src http://packages.devuan.org/merged ascii main

Boinc: 7.6.33
kernel: 3.16.0-4-amd64
Boinc working on 4/4 cores, but unable to use boinccmd
********************************************************

Machine 2 upgraded between Sun, 13 Aug 2017 04:00:09 +0100 and Sun, 13 Aug 2017 04:33:18 +0100 from jessie to ascii using

deb http://gb.mirror.devuan.org/merged/ ascii main
deb-src http://gb.mirror.devuan.org/merged/ ascii main

# jessie-security, previously known as 'volatile'
deb http://gb.mirror.devuan.org/merged/ ascii-security main
deb-src http://gb.mirror.devuan.org/merged/ ascii-security main

# jessie-updates, previously known as 'volatile'
deb http://gb.mirror.devuan.org/merged/ ascii-updates main
deb-src http://gb.mirror.devuan.org/merged/ ascii-updates main

# jessie-backports, previously on backports.debian.org
deb http://gb.mirror.devuan.org/merged/ ascii-backports main
deb-src http://gb.mirror.devuan.org/merged/ ascii-backports main

# Devuan repositories
deb http://packages.devuan.org/merged ascii main
deb-src http://packages.devuan.org/merged ascii main

Boinc: 7.6.33
kernel: 4.9.0-3-amd64
Boinc working on 1/2 cores only, unable to use boincmd
***************************************************
Machines 3,4,5 running devuan jessie
Boinc: 7.4.23
kernel: 3.16.0-4-amd
Boinc running on 2/2 cores on all three machines, boinccmd works.
***************************************************
Note: the machine that upgraded from gb.mirror upgraded the kernel, but the machine that upgraded from auto.mirror did not.
I now have two versions of ascii one running the 3.16.0-4 (jessie) and one running the 4.9.0-3.
I am locked out of the 4.9.0-3 machine following a reboot.
I don't think it's the firewall (connection tracking modules not loaded in 4.9.0-3): turning iptables into ACCEPTing everything doesn't help with the boinccmd issues.

ghaverla · 2017-08-14 03:07:42

leloft wrote:

I am also experiencing Boinc problems after upgrading to ascii this morning. It appears to be related to the kernel version:
[ snip ]

I am not the greatest sysadmin debugger in the world. Do you have logs (from the /var/log or from $HOME/.xsession*)? Are they showing anything? Do you get any more information if you start the programs from a command line, instead of from a GUI?

ghaverla · 2017-08-14 03:19:12

ghaverla wrote:

Churn on things for a minute or ten.

Tonight, I compiled the client side of the BOINC source tree (from BOINC, not from Debian/Devuan). And it is version 7.7.0 I believe.

Well, it is a different compile process than I have seen before. And very little documentation as to what make targets are present, and what they are for. I tried a make test, and there is no test target (maybe only CPAN has this typically?). Looking in the Makefile, I tried a make dist, and that failed. Make install should usually fail for ordinary users, as they shouldn't have write permission to /usr/local. But changing to root and running make install, did install some stuff.

Boincmgr runs, it doesn't like that the BOINC core client isn't running. Something for tomorrow.

----

In terms of what BOINC packages installs, at the present time dpkg -l | grep boinc reports boinc is not installed. I do have "old" packages installed. There are no *inst files related to boinc on the system. All of the devuan packages show each package has debian-binary, control-tar.gz and data.tar.gz components.

----

In any event, tomorrow I will see if I can get the core client running even though there are no jobs. It could be interesting as I need to specify where these are stored, and what I ran into on Devuan was this stuff was going in $HOME, and not in /var. But maybe I will figure out what is going on.

ghaverla · 2017-08-22 13:47:13

Nope, it wasn't tomorrow. Actually more than 1 day later.

I have the compiled source tree for "client only" from BOINC installed in /usr/local. I copied the startup script from a Debian/Jessie (/etc/init.d/boinc*) to this Devuan. One edit of consequence so far, and that is to point at the binary in /usr/local/bin. Just comments otherwise.

The Debian startup file sources /etc/default/boinc* (I am being lazy, the filename starts with boinc), and this Devuan machine still has a file in /etc/default of the appropriate name. The Debian file has a blurb about ENABLE=1 in it, to show that it has been set up and BOINC should run. The Devuan file has nothing like this. Actually, the Devuan file has no active lines in it, it is all blank lines and commented out lines. Is this how Debian/testing is set up now? Or how did the Devuan file end up being so different?

There are a few assumptions in the init file which I will change, to see if this works. Not sure if I will finish this today or not.

ghaverla · 2017-08-24 03:05:43

The edited Debian/Jessie BOINC init.d and default files work to get things at least started. The 'make install' of the Berkeley source tree seems to have installed its own init.d file, which is more involved than the Debian one is.

Starting the boinc client with the init.d script, showed no evidence of any GPU capabilities. Editing the group (and gshadow) files, to add boinc to the video group, and to add the ordinary user to the boinc group resulted in BOINC recognizing the GPU on a restart of the boinc client.

But at this point, I have no BOINC stuff in /etc. So, I need to move a copy of that from one of my Debian/Jessie setups.

ghaverla · 2017-08-24 15:16:04

I was hoping that what I am now seeing, was what leloft had for a problem, but it is different.

I've tried connecting to Seti@Home, World Community Grid and Einstein and there is no connection. I don't seem to have any firewall blocking things, but I suppose looking at what iptables is doing might be useful.

A Boinc or Seti forum suggested setting http_debug, http:xfer_debug and file_xfer_debug in cc_config. I am manually typing in (edited) snippets of error messages, so there could be typos.

TCP_NODELAY set
Connected to Boinc port 443
Initialising NSS with certpath:none
WARNING: failed to load NSS PEM library. Using OpenSSL PEM certificates will not work.
HTTP error: Problem with the SSL CA cert (path? access rights?)
...
Next it tries the SetiAtHome server at Berkeley, and this seems to handshake and everything.
Downloads some stuff.
Tries the same to SetiAtHome as Boinc, and we see the NSS PEM thing again.
Then it tries https to google.com, and same NSS PEM thing and gives up.

/var/lib/boinc-client/ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt

The ca-certificates.crt file is 261407 bytes, 644 permissions root.root ownership.

Not sure what else needed.

ghaverla · 2017-08-24 19:39:03

I updated anything SSL/NSS/GNUTLS related, and I ran update-ca-certificates.

Problem still exists.

Libraries cached in memory/swap, and I need a reboot to "fix" things?

ghaverla · 2017-08-25 00:39:21

Rebooting didn't fix things.

I deleted libcurl4-nss-dev and the binary library associated with it, and installed libcurl4-gnutls-dev and recompiled BOINC client from the Berkeley source. Of course, make install overwrites a couple of things. :-) But, it connected to SETI@Home and downloaded some tasks and it is working. Sort of, it doesn't seem to be doing any GPU work. I think there are a bunch of 32bit libraries a person has to have installed, in order to do GPU work on an amd64. But I'll work on that later. I am trying to get that working via Mesa3d/Clover, instead of that deprecated binary junk from amd that was not really supported at the best of times from what I can tell.

gdagar · 2017-09-11 02:38:07

Hi leloft, nice to meet you.

I have put 3 machines thru the 'Jessie to Ascii' upgrade. On all, I used the same 'auto' mirrors, as you did. However, I'm not so committed to 'free' software that I use only the 'main' section of each repo. I enabled the 'contrib' and 'non-free' sections of each repo as well. I find that they contain many packages/dependencies that I want, and sometimes need, especially for not-necessarily-linux packages like BOINC. I honestly don't know if this helped, but I haven't experienced any of the things that you describe. They all upgraded to the 4.9 kernel and I installed the 7.6 BOINC Client and Manager. All cores of all CPU Cores are running tasks, as well as all GPUs. I can't speak to 'boinccmd' as I've never used it.

NOTE: If a 'contrib' or 'non-free' section of a repo can't be found, Apt/Synaptic will tell you and you can remove that section from the repo line.

You can upgrade the 3.16 kernel to 4.9 manually, and I recommend that you do. Just be sure to reboot to the 4.9 kernel before you uninstall the 3.16.

As for the lock-out, if you told the upgrade to 'use the package maintainer's version' of any config files rather than keep the old one, that could have changed your login settings, especially with lightdm.conf or slim.conf. 'passwd' in a terminal will get you going again.
Come to think of it, this could affect 'boinccmd' as well. It may have messed with owners, groups, and/or permissions.

I can't speak much to the firewall or iptables, little skillset there. But my 'opinion' is that they aren't issues.

NOTE2: During the upgrade, I left the 'Jessie' repos enabled, complete with 'contrib' and 'non-free' sections, and didn't disable them until the upgrade was complete and reboot successful. Whether or not this helped is unknown. I know Apt/Synaptic pulls in the newest version of a package, but I thought that if Ascii didn't have something, maybe the upgrade could pull a suitable substitute from 'Jessie' and be OK. I also made sure that Jessie (again, with all sections enabled) was completely up to date before enabling any of the Ascii Repos.

These are my thoughts, hope they help.
Post your progress, regardless of my input. I'm interested.

Gary

Last edited by gdagar (2017-09-11 05:11:15)

gdagar · 2017-09-11 05:12:55

Hi ghaverla, nice to meet you.

I hate for your troubles. But in the last few months, I've been thru EXACTLY (mostly) what you're going thru, and I'd like to try to help. What makes my experience 'mostly' is that I had compile problems on 3 computers, and I had AMD Catalyst problems on a 4th computer. Hopefully, you can combine my lessons learned on one computer and find joy. I'm gonna try to take your posts one at a time, top to bottom.

Letting the tasks finish and upload and get no new work was the right thing...kudos. That should have been enough, and I know the projects appreciated it.

Your HD 5450 is barely in the usable range of compatible GPUs. Might consider an upgrade soon. In my BOINCsperience, NVIDIA is much easier to work with. BTW, I love the term BOINC-fu. Maybe your room needs some BOINC-shui.

MESA is designed to work only with non-proprietary drivers, in your case, Radeon and AmdGpu (not Pro) in the repos. xorg-radeon is AMD's non-proprietary driver for its older GPUs, xorg-amdgpu is AMD's non-proprietary driver for its newer GPUs. I don't know where the dividing line between old and new is.

I have seen boinc-client show up in my home folder before. I ignored it and just kept going. BTW, not in Devuan, in MX.

Using the Distro's Version, rather than compiling, is the best way to go if you can. I think your upgrade to an upgrade to an upgrade may have left some things not right, systemically. Multiple unsuccessful re-installs of an Application is a sign of this.

I hate that noone replied to you for so long. I saw your post 2 weeks ago, but was not in the right mind to reply. Today, I am.

I love to move and upgrade hardware. Hope you had fun.

The boinc-client starts on boot-up by default. Users must suspend/resume projects/tasks manually to their likin'.

Glad you found that 'compile client only' flag. I had to visit 3 or so different Web Pages to get all the instructions I needed. Then I still had to wait for the compiler to tell me something was missing.

I extracted and compiled in my Home Folder. I think this made write permissions less of a problem.

It sounds to me like you're trying to mix files from the Distro's BOINC installation with the Compiled BOINC installation. This is a booboo. They are not compatible. The Distro Version uses Symbolic Links throughout the tree. The Compiled Version is completely self-contained in its own folder. It compiles completely and solely in the same folder to which it was extracted. It places nothing anywhere else in the tree, not in /etc, not in /var. The Distro Version's symbolic links will interact with any files anywhere in the tree that have 'boinc' in their name, including those in the Compiled Version's folder. You must choose one version or the other, and completely remove all files of the one you don't choose (backup boinc-client first). Catfish is your friend.

Your last post indicates that you chose the Compiled Version and it's working, except for GPU. Congratulations. Still uninstall the Distro Version and remove all rogue files. Apt-get autoremove, GtkOrphan, and BleachBit are good friends too.

OPINION: After all the things you did, undid, and rearranged, a fresh install of DevJessie upgraded to Ascii may be worth considering. If you wish, see my reply to leloft for my take on that.

Now you're back to the original problem in your original post, getting your GPUs to run OpenCL tasks.

I don't think you need any 32-bit libs, other than the deps pulled in by BOINC and the Video/OpenCL Drivers.

MY TAKE: Uninstall/remove all things proprietary AMD/Catalyst/fglrx and use the xorg-radeon driver only. If it won't uninstall, claiming that some files have been changed, just remove /etc/X11/xorg.conf and /etc/modprobe.d/blacklist-fglrx. A reboot should take you back to the xorg-radeon driver.

You're experienced with MESA so install whatever you like from it's collection. I installed: glx-provider-mesa, opencl, va, utils & extra, vdpau, and vulkan. There was plenty of MESA stuff already installed by the OS install, but these pkgs looked necessary/handy to me, and I don't think too much MESA will do any harm.

FAIR: This is my first attempt at MESA, it having been made necessary by smelly AMD OpenCL support in Stretch/Ascii/xUbuntu16.04/DevJessie. It was fine in DebJessie. So, my skillset in this area is highly undeveloped.

IMPORTANT NOTE!!!: As well as my AMD GPUs run BOINC tasks now, this Radeon/MESA combination is not powerful enough to run tasks and desktop graphics/video well simultaneously. Some 'points & clicks' take a few seconds to respond. Since the computer in question is our Home Theater PC, and Graphics/Video are primary, my solution was to 'exclude_gpu_0' in cc_config.xml, as that is the GPU that runs the TV/Monitor. The other two AMD GPUs run tasks continuously without consequence.

These are my thoughts, hope they help.
Post your progress, regardless of my influence. I'm interested.

Gary

Last edited by gdagar (2017-09-11 19:05:18)

ghaverla · 2017-10-05 15:19:25

Hello gdagar.

Working on the farm, there are always things to keep me occupied. I try to only work on computer problems when I don't want to be outside. Since we've had a drought much of the summer, there have been few rainy days.

The computer with the dual core AMD64 and the HD5450 is running World Community Grid CPU jobs. At the moment, there is 1 job running, 2 to report, and 4 tasks with computation error (I wonder what happened there?). I will have to look into the GPU issues a little later. I may put a RX550 in this, but the power supply is quite small.

---

I upgraded another computer from B24 dual core to 8 core FX-8320e, and put back the RX-460 I meant to run there over the last few days. I installed Devuan/Jessie to a 40 GB partition on SSD from DVD (the install from the Jessie CD wouldn't work, something about network access). A fairly minimal install. I then upgraded that to Ascii/Ceres and a 4.12 kernel. On the SSD I had the root, /boot, /usr and /var partitions of Debian/Jessie. I removed almost everything that was OS (so mostly /etc left), and made a tarball of that. All of those partitions were ext4. I then redid the root partition as btrfs, and unrolled the tarball on the root partition. I then pruned what was below /boot, /usr and /var. After that, I mounted the 3 "Debian" partitions at the appropriate places, and copied (with archive switch set) all of the Devuan/Ascii-Ceres to this set of 4 partitions. I adjusted the few files in /etc that needed adjusting. Chrooting into the root partition and running update-grub was not sufficient to allow this to boot, I had to dpkg-reconfigure grub. But it booted then.

I had partitions for swap, /tmp, /var/log and /usr/local on another disk, which were relisted in fstab. And this "homeless" system booted fine. Even seamonkey in /usr/local ran.

I then loaded in clang-5.0, llvm-5.0, mesa, opencl and boinc stuff.

Boincmgr ran fine the first time. I removed the hold on new tasks for setiathome and einstein. Nothing was downloading for quite a while. I looked in the logs a bit, and I had been dumb. The UID and GID for boinc had changed, so it couldn't write things. Fix permissions, and jobs started appearing. All of them failing (GPU and CPU jobs).

I started today by setting dpkg to allow for i386 libraries if it needs to, but haven't installed any yet. I then entered the setiathome project directory with emacs in dired mode and shell in the other half window. And I started running 'file' against files found there, to find out what they are (and to run ldd against the executables I find).

There is an ELF32 file there, with Oland in the name (so some kind of GPU file) of unknown architecture that is reported to have a corrupt program header size (according to file). ldd says it is not a dynamic executable. And another similar file of same properties.

And there are four different 8.22 ati OpenCL files, which are all x64 ELF executables with ldd reporting that all of them have the libraries they need to run.

I don't seem to find any executable files meant to run on the CPU (only).

I haven't yet looked through the einstein directory, to see if there is anything to find out there. But BOINC seems to clean too much up after problems, so I probably need to visit the two projects in question to see if there are stdout or stderr outputs that have more information on the problems.

ghaverla · 2017-10-05 23:33:51

I got to look at the einstein project directory.

There are two executables in that directory now, one is a statically linked 64 bit file (so ldd can't help on that). The other is a dynamically linked 32 bit program. Two of the libraries are not found. I have tried downloading the packages for LibGL.so.1 and libX11.so.6 for i386, but there is a conflict at the moment for ascii/ceres that involves my choice of using LLVM-5.

ghaverla · 2017-10-06 23:20:13

For both seti@home and einstein, the jobs are failing on a segfault. Right when it first starts up.

ghaverla · 2017-10-07 00:39:40

Woo Hoo! Partial success. I have CPU jobs working.

It seems that at about the 4.8 kernel, the vsyscall was set to "none". If you look in your logs, you should see a bunch of lines where BOINC jobs are getting squashed because of this. These are the system logs, not the files in the BOINC directories.

On booting in grub, you can edit a command line and add
vsyscall=emulate
to the linux (kernel boot) line.

If this works, you can change the grub default linux boot line in /etc/default/grub and add
vsyscall=emulate
to that parameter, and then update-grub.

Maybe with something working, I will see why amdgpu (not amdgpu-pro) and mesa are not getting together to run GPU jobs. Or maybe they will start by magic as well. :-)

ghaverla · 2017-10-08 00:21:08

Seti@Home downloaded some GPU jobs today, and all of them resulted in build failures. I am seeing files in the BOINC directory for Seti@Home related to OLAND, but a RX-460 is Polaris not Oland. I will guess that Seti@Home is assuming catalyst driver, and not MESA? I think the libclc I have is new enough, certainly LLVM-5.0 is greater than 3.8 (which is where problems came in a long time ago).

There seems to be a problem with the Einstein@Home package, every BRP job segfaults as well. Since I have vsyscall=emulate already set, there has to be some other explanation for these early segfaults.

ghaverla · 2017-10-08 01:36:49

Looking in the "slots", I have found a log file of interest.

It is looking for a OpenCL kernel file, which is not present. Is this file supposed to be part of the download from Seti@Home, or is it supposed to be calculated locally?

This is being manually typed (not cut and paste), so there could be errors

AstroPulse_Kernels_ r2751.cl_ bin_V7_TWIN_FFA_1721

The only OpenCL things I am seeing for GPU, are Oland files.

ghaverla · 2017-10-08 02:47:07

After deleting (for a second time) the EAH boinc package in Devuan, I am seeing EAH jobs running.

They don't seem to be segfaulting in the first few seconds, but who knows if they calculate anything useful at this point?

ghaverla · 2017-10-08 19:06:27

Maybe I am reading too much. :-)

I am not too overjoyed at having purchased hardware to find it deprecated, or about to be deprecated. Some of this I may be mis-interpreting.

Advances in the Xorg server have made fglrx (Catalyst or Crimson) a non-starter for anyone with an up to date OS. Mesa/Clover/libclc/Clang is providing a OpenCL-1.1 environment, and work continues. It appears that the choke point in this is libclc. Apparently nobody has tried (published?) an attempt to run OpenCL-1.2 tests against this combination. What is there now, is 1.1 with extensions, and most of what is needed for 1.2 seems to be done. But there doesn't seem to be any urgency in getting to this 1.2 state. I'm not writing code, so it is easy for me to write.

AMD helped with the open source amdgpu module, and produces a proprietary amdgpu-pro driver. Does this driver following the same philosophy as fglrx? Is it just as enjoyable to work with? In any event, I gather AMDs answer to Clover is ROCm. While amdgpu is supposed to support all GCN cards/GPUs, ROCm doesn't seem to support all of GCN. So, if you follow the AMD hardware side and go to ROCm for OpenCL support, you may find that your older hardware will not play any more. For instance, my A10-7860k APU and R7-250 GPU would be too old.

---

In any event, Einstein CPU and GPU jobs are working on the RX-460 using MESA (no fglrx). SETI sent some GPU jobs, but as near as I can tell it is only compiling them for Oland (and fglrx). So I get a build failure, and it pauses for a while, and then another build failure. Oland is what was in this computer before (the R7-250). I have looked to see if there is some old data file doing this, but I am drawing a blank. The CPU jobs are coming through fine.

I have stopped downloading new tasks on this machine to empty the queue (except for these build failures, which will never run I guess), as I am ready to copy my old /home to a new disk, and BOINC data actually sits in /home.

Which may give me time to see what this HD5450 can do again.

Happy Thanksgiving!

ghaverla · 2017-10-19 22:55:01

The computer most recently upgraded (8 CPU processor and RX-460) seems to be doing okay. It is doing Einstein@Home GPU jobs, it will not do SETI@Home jobs (they require Catalyst as I understand things). The computer first upgraded (2 CPU and HD5450) probably could do jobs, if it had Catalyst installed. It is doing CPU jobs now. I was running a 4.7 version of BOINC compiled from source. It is now running a 4.8 version of BOINC from Devuan packaging.

The computer with the 8CPU processor, I was running a perldb job in emacs, and generating a LOT of output, and emacs started running out of memory (8GB RAM and 16GB swap). I got "Computation Error" on a whole bunch of BOINC jobs. :-)

ghaverla · 2017-11-10 19:56:37

The 8 core computer with RX-460 continues to crunch. The only GPU work it gets is from Einstein@Home, which are jobs which are about equally split between CPU and GPU. SETI@Home jobs I believe all assume you are running Catalyst (or Crimson) or AMDGPU-Pro (in other words, proprietary).

I moved a mini-ITX motherboard from a fullsize ATX case into a mini-ITX case. This has a A10-7860k APU. It was planned to run with a R7-250, but that seemed to require Crimson, which was a nightmare. The R7-250 was replaced with a HD-6450, which ran under Catalyst (but was proprietary). On the move, I put a RX-550 into the machine. The HDMI output is plugged into the motherboard, and so makes use of the GPU part of the A10. The RX-550 is left all alone to do crunching. Perhaps in the future it will be possible to get the GPU side of the A10 to number crunch as well.

Initial E@H estimated time was 1:11, first job ran in 34 minutes.

I am only allowing 2 (of 4) CPU cores to run BOINC, leaving 2 free for other stuff. Perhaps a person can throw another CPU at things?

The officially official Devuan Forum!

#1 2017-07-14 14:36:12

Boinc

#2 2017-08-13 02:40:34

Re: Boinc

#3 2017-08-13 03:04:13

Re: Boinc

#4 2017-08-13 17:21:23

Re: Boinc

#5 2017-08-14 03:07:42

Re: Boinc

#6 2017-08-14 03:19:12

Re: Boinc

#7 2017-08-22 13:47:13

Re: Boinc

#8 2017-08-24 03:05:43

Re: Boinc

#9 2017-08-24 15:16:04

Re: Boinc

#10 2017-08-24 19:39:03

Re: Boinc

#11 2017-08-25 00:39:21

Re: Boinc

#12 2017-09-11 02:38:07

Re: Boinc

#13 2017-09-11 05:12:55

Re: Boinc

#14 2017-10-05 15:19:25

Re: Boinc

#15 2017-10-05 23:33:51

Re: Boinc

#16 2017-10-06 23:20:13

Re: Boinc

#17 2017-10-07 00:39:40

Re: Boinc

#18 2017-10-08 00:21:08

Re: Boinc

#19 2017-10-08 01:36:49

Re: Boinc

#20 2017-10-08 02:47:07

Re: Boinc

#21 2017-10-08 19:06:27

Re: Boinc

#22 2017-10-19 22:55:01

Re: Boinc

#23 2017-11-10 19:56:37

Re: Boinc

Board footer