|
1)
Message boards :
Questions and problems :
Comutation error - cause was out of memory
(Message 82130)
Posted 20 Oct 2017 by Gordon Haverland Post: I looked over preferences again, and I don't see how the BOINC manager could have stopped me from ruining a bunch of tasks. I think the manager(or client) had no choice but to label the first job killed by the kernel in an attempt to manage RAM as computation error, but it would have been nice if the manager(or client) would not have kept trying to start new jobs (and subsequently have them fail) while the load was so high. One of my machines is running 7.8.3, so I could update the 7.8.2 to that. Would that have saved me? :-) I guess I will eventually have to come up with a list of programs which I should enumerate for BOINC, which can have big demands. I don't see that this is practical with emacs, as it can do so many things that are not resource hungry. What might be nice is if a person could send SIGUSR to the boinc process to tell it something unusual was happening. Perhaps use SIGUSR like XON/XOFF (Control S/Control Q)? |
|
2)
Message boards :
Questions and problems :
Comutation error - cause was out of memory
(Message 82117)
Posted 19 Oct 2017 by Gordon Haverland Post: Hello. I have been running a bunch of SETI and Einstein@Home jobs, and what had become more or less steady state was 5 SETI CPU jobs and 1 Einstein job split between CPU and GPU on a 8 core CPU. And then I started an interactive perldb session in emacs which generated a ton of output. And the machine ran out of memory, and the kernel started killing jobs. Seamonkey got clobbered, as did a pile of SETI and Einstein jobs. Is there a preferred way to handle this? Should I have stopped boinc-client before I started this? What if you don't know that something similar is going to chew up all of RAM and SWAP (I have 8 GB of RAM and 16GB of swap). I think I was running 7.8.2 for boinc. Computer is running Devuan/Ascii (nominally the same as Debian/testing). I think the 4.12 kernel. Mesa is supplying compute abilities for GPU (RX-460), not that proprietary stuff from AMD. Thanks. |
|
3)
Message boards :
GPUs :
AMD Drivers for Debian Jessie - Installing not successful
(Message 73558)
Posted 25 Oct 2016 by Gordon Haverland Post: And, something that I really do NOT like... X appears to stutter occasionally when the client is running with a GPU work unit running. The screen freezes temporarily and overall is non-responsive. Not sure what is happening... Greetings. It seems I have never logged in to BOINC itself, but I've been doing SETI, ClimatePrediction and others for a while. Or, it didn't recognize my email. Anyway Ken, I have 4 Debian/stable AMD64 machines here, all with AMD GPUs. Smallest GPU is a HD5450, which is smaller than yours. I have 2 HD6450s (same), an A10 APU (R7 class), a R7-250 and now a RX460. The stuttering is normal. That GPU is small enough, that stuttering will happen. You can set in your preferences to not run GPU jobs while the console is "active". Active being generating key scan codes from the keyboard or mouse movements. Normally this is a good definition, but if you hit Ctrl-Alt-F1 to get to a text UI session (console 1), this is still seen as activity on the keyboard, and will put your GPU task to sleep for as long as you indicated. Most people don't run text consoles and GUI consoles, so they don't run into this. Looking for advice about fglrx (Debian package family) a couple of years ago, probably got better advice than now. Nobodies fault in BOINC. The first proprietary driver was fglrx (Fire GL Radeon X, or something like that). Probably still when ATI owned it. After a while, a new proprietary driver came out (Catalyst). New driver, and so we will give it the name, ... fglrx. Catalyst will do a lot of things, but not everything (for example, it won't let my A10 with R7-250 both work). The new proprietary driver which will let both GPUs work is called Crimson, and its package name is, ... fglrx. ATI and AMD have had a bunch of changes in hardware technology. R7-250 is about the start of GCN. The A10 APU I have also has this R7 type GPU in it, which is GCN. In any event, it would seem that yet another software technology got started, which seems to be called AMDGPU, which is meant to support GCN. As I understand it, there is an open source part called AMDGPU, and there is a proprietary part called AMDGPU-PRO. Vulkan is another name which pops up in this. In any event, all non-GCN GPUs are somewhere in the process of being deprecated. And hence, bug fixes and documentation fixes, and things like getting Crimson to install just don't get much work any more. Or so it seems. I am wading through the Crimson install 'run' file setup, trying to figure out why it can't make a driver set for my machine. I am going cross-eyed. :-) --- The reason for me to visit BOINC itself, is that the BOINC manager is getting flaky. I am guessing that it is trying to manage the generation of work units. CPUs and HD5450s and HD6450s and A10-GPU and probably RX460 generate work units for SETI at much different timescales. If I am generating miniscule units per time with the CPU and big units per time with a GPU, it causes problems for work with other projects that don't have GPU work. I can run out of work at WorldCommunity Project (and units are available), but it won't ask for units because it isn't the most important project on the machine (or something like that). So, I have to manually suspend the other projects so that World Community is the only project left, and then it will download more work. At some point (hopefully soon), two things may happen. I will be too busy to micromanage BOINC, I will have computation intensive stuff of my own running, using up CPU and GPU (and maybe FPGA) resources. So this isn't a complaint, it is just an observation. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.