|
21)
Message boards :
BOINC Manager :
7.16.3 on Ermine
(Message 93347)
Posted 28 Oct 2019 by Gary Roberts Post: I built 7.16.3 a couple of days ago on my distro-of-choice - PCLinuxOS. Initially I saw exactly the same error message and on checking my notes from previous builds together with the current configure output, I worked out that I had neglected to install lib64-curl-devel and a brand new lib called wayland-protocols-devel. This latter one was evidently needed from what I gleaned from the configure output.I believe that the https://github.com/BOINC/boinc/tree/client_release/7/7.16 branch of BOINC's own code is clean in this respect, although it's still subject to testing and I don't think we've got all the bugs out of it yet. So after installing these two and restarting with a fresh checkout, it all built fine. I don't actually know which of the two libs got rid of the missing gtk/gtk.h problem. I've been running this new version without problems for a few days now on a test machine. Obviously, the libs you need will probably be named somewhat differently but hopefully the PCLOS names will give you a clue about what to look for. To build BOINC, I needed to install over 150 tools/libs on what is a quite minimalist system that I use for crunching. If you get desperate, I could easily supply that full list so you could possibly work out anything else that might be missing from your build system. |
|
22)
Message boards :
Questions and problems :
Ubuntu 18.04 + Radeon HD 4890 + "No Usable GPU"
(Message 93114)
Posted 7 Oct 2019 by Gary Roberts Post: Is my conclusion correct (that OpenCL for the card is not supported by x.org so it cannot be recognised by BOINC in the absence of a functioning proprietary driver)?That's not really the problem. If you look at this information about HD4000 series GPUs you will see that your hardware only supports version 1.0 of OpenCL (far right column) and that is the real problem. You probably need hardware that offers 1.2 (or better) support. You certainly need that for Einstein and probably for other projects as well. Somewhat more modern AMD GPUs work well on Einstein. Pick something with GCN (Graphics Core Next) 2nd gen or above if you want easy support on Linux. GCN 1st gen (Southern Islands) does work with the older fglrx proprietary driver, but not yet (still a work in progress) with the later amdgpu open source driver. 2nd gen (Sea Islands) and later works fine. |
|
23)
Message boards :
Questions and problems :
GPU idling just because I set from 10 days to 1 day of work storage
(Message 93031)
Posted 3 Oct 2019 by Gary Roberts Post: All I did is select all but Prime Grid from the projects tab and have it store from 10 days of work to 1 day.Seeing as we have no idea of the list of projects that are "all but Prime Grid", perhaps you might like to mention the ones you selected rather than the ones you didn't. When you select a project on the projects tab, a number of commands then become 'available' for you to click on. Those are things like 'update', 'suspend', 'no new tasks', etc., but there is no command that will allow you to change the "days of work" for that selected project. If you have changed your work cache days setting, it would have been done elsewhere and would apply to all projects and not just to a selected project. Perhaps you should check the projects tab to see if any projects that normally supply you with GPU tasks have accidentally been 'suspended' or set to 'no new tasks' or something like that. Remember that the wording on a command button you see there shows the action that will happen if you click the button. For example, if a button for a selected project shows 'allow new tasks' then that project is currently set to NOT supply new tasks. After a day I only have 1 GPU running. Instead of it getting more work for an idle GPU and regardless of how much work I still have for that ideal GPU it never got more Prime Grid for 1 of my ideal GPU or use what GPU projects I still have. That 1 day should be times the amount of GPUs I have and keep the second GPU bussy. Again, I had other GPU work from other projects that I've seen run off of a 980 but it's not running those projects still stored up on my computer.I don't understand what you mean by "ideal GPU". I really don't understand what this whole paragraph is supposed to be describing. I gather you have only 1 of 2 separate GPUs that is actually crunching something (project and number of available tasks not specified) and that the other GPU is idle. You say that you have "other GPU work from other projects". If both GPUs are available and if one of them is idle, it seems like you must have done something like suspend the project that those "other GPU tasks" belong to. I don't know how available tasks would not start crunching if there was an idle and 'ready to go' GPU. Your assertion that the change in work cache size is somehow responsible just can't be correct. There is something else you've changed. In other words, somehow BOINC is being restricted by what you have (perhaps accidentally) changed and you need to find what that is. |
|
24)
Message boards :
Questions and problems :
how to get closest deadlines computed first
(Message 93022)
Posted 2 Oct 2019 by Gary Roberts Post: Is there a way to get Boinc to do the closest deadline first ...There is always the technique of 'micromanaging' - which is unnecessary, as Richard points out, since BOINC will take care of it for you. If you have a particular task that you want to run next, you can always use options in BOINC Manager to 'suspend' any tasks ahead of it in the FIFO queue. As soon as the 'promoted' task is underway, you could 'resume' whatever others you had previously suspended. It's a really good way to overlook things and get yourself (and BOINC) into a pickle so you can't just walk away and forget about it :-). |
|
25)
Message boards :
Questions and problems :
Manualy copy *.exe and *.dll to project folder?
(Message 93021)
Posted 2 Oct 2019 by Gary Roberts Post: Could that file be edited to tell Boinc that the files are downloaded?It is not necessary to edit the state file for the client to become aware that required files already exist. The client is perfectly able to discover that for itself. A classic example of that is the action I take if I want to install BOINC on a new machine and minimise the initial downloads. I have complete template hierarchies for whatever BOINC version I intend to use. That includes complete project directories for whatever project I wish to run. In each project folder, I include all the files that BOINC would need to download from the servers of that particular project. When BOINC is first launched, there are always lots of messages of the form, "File xyz exists, skipping download." For your situation, if you have known good copies of all the files you are unable to download, just stop BOINC and copy those files into place. When you restart BOINC, those files will be noticed and provided they do meet any validity checks (eg MD5SUM or other security checks) you should find that they will be accepted without you needing to touch the state file. Are you sure you have known good copies. That's the key. |
|
26)
Message boards :
GPUs :
AMD GPU Task Turns Computer Off Immediately
(Message 92770)
Posted 11 Sep 2019 by Gary Roberts Post: .... So this tells me it is not a heat issue, I would expect the computer to run for a little while before shutting down.Whilst you would not expect the temperature to rise instantly and therefore might expect to see a bit of a delay, maybe the firmware is using something other than a temperature change to invoke a protection mechanism. I have no idea if this is ever done but perhaps it might be current draw that triggers the response. You don't mention what project is supplying the GPU work but if that work is really compute intensive, maybe some current limit is being tripped. I could imagine that happening quite quickly - almost instantly. |
|
27)
Message boards :
Questions and problems :
Trouble running 2 RX 570 on Einstein@home
(Message 92427)
Posted 9 Aug 2019 by Gary Roberts Post: ... Would be awesome if anyone got an idea, on what might be wrong.You really should be asking this on the Einstein project forum since there are many regulars with the necessary experience there to tell you what the problem is. Simply put, your computer is trying to do all the searches and you have lots of CPU tasks close to or exceeding the deadline. You must have too large a work cache size for either the hours your computer runs or for the project mix you are trying to support. It looks very likely that BOINC is going into high priority mode in order to get more CPU tasks completed before the deadline. The effect of that is to prevent GPU tasks from running in order to release an extra CPU core to crunch the 'at risk' CPU tasks. As an example of why I think this, take the GW O2 All-sky CPU search. You have a total of 232 tasks of which 147 have already exceeded the deadline. Some of these are quite recent failures and BOINC would have stopped crunching on one of your GPUs to allow an extra CPU task to start. It's an impossible situation for BOINC to cope with. If you leave things as they are, very shortly it will be a further case of 'rinse and repeat'. The very first thing you need to do is lower your work cache settings to something very low in order to stop further work requests. You may also need to assess tasks already on board to see if there are any that can't possibly be completed by the deadline and abort them. I suspect you will find some but you need to work that out for yourself. If you want both your GPUs to crunch without interruption, you need to get rid of excess CPU tasks. If you need help with sorting this out, post details about which projects you wish to support, what resource shares you wish them to have, how many hours per day that your computer crunches, etc., on the Einstein 'Problems' forum. Also post what the setting for your work cache size has been up till now. |
|
28)
Message boards :
GPUs :
GPU run project
(Message 91611)
Posted 24 May 2019 by Gary Roberts Post: Does any one know of a Project that runs on a Linux Mint OS via a AMD Radeon 7700 GPU?There is no such model as a 7700 GPU. I presume you are talking about the HD 7000 series which includes a number of different model numbers. What is your particular model? I'm using a HD 7770 model under Linux at the Einstein project. It's been crunching for around 6 years and it's still working just fine. I've never used Ubuntu or any of its derivatives so have no direct knowledge of the hoops you might need to jump through with your distro. Depending on your precise model, those hoops might be different. You might get the best advice by composing a much more detailed set of information about your hardware and software environment and asking for assistance on the Linux Mint forums. There are bound to be people there with direct experience with running GPU apps on BOINC projects under Mint. If so, are there any special commands needed to make it work?So, in essence, you already have a project (what project is that?) with a Linux GPU app so it sounds like you just need information on how to properly install the appropriate OpenCL libraries? If that's the case, you'll have a much higher chance of finding out how to do that by asking in the Mint forums. I presume (but certainly don't know for sure) that Mint can use the Ubuntu version of "Radeon Software for Linux" which used to be distributed as "AMDGPU-PRO". I would think you just need proper information about the version of Mint, the kernel version and the version of the -PRO package that will all be compatible. Just saying that you "can't make it work" without giving any information about what steps you have tried, is not the best way to ask for help so be sure to document what you have already done if you expect people to tell you what you might be missing. |
|
29)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91105)
Posted 16 Apr 2019 by Gary Roberts Post: The discussion has moved on since you read it ...If by that you mean garnered more replies, then certainly yes, but if you mean the mood has changed or the overall opinion is different, I didn't see that. I find myself very much agreeing with Raistmer's views, as stated in a series of posts, starting with this one. I also agree with Keith's stated views both at SETI and in the github thread. I'm not trying to single anyone out. There were many other comments that I could have mentioned. Without really understanding the complexities that might be involved, I think Raistmer's suggestion of two separate scenarios (as mentioned in the message I linked to) would be the way to go. It should be possible to have just one complete source tree with full functionality and leave it up to the individual distros to configure the separate styles of use if they so desired. I imagine it could be just up to the package maintainer to tweak certain config options before building. Individuals building for themselves could get what is currently available with nothing removed by using defaults for those options. |
|
30)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91104)
Posted 16 Apr 2019 by Gary Roberts Post: A couple of small points for anyone reading.Stepping carefully into this heated discussionGary and I have repeatedly tried to explain our views which are so fundamentally different that they're only partly understood by the other side. From my side there's no need to continue this and I was just about to say that more opinions are very welcome. I'm not likely to change mine though. ;-) There is no heat in this discussion. The points of view may be different, but not fundamentally so. It's really just a 'debate' with the ultimate view of providing any reader with the various points from which they can make their own judgements about the matter. Both sides in a debate will inevitably make their points as strongly as possible. There should be no animosity involved. I have detected none and I'm not trying to deliver any. I fully agree with Floyd's final comment - we've made our respective opinions known, we've shaken hands and agreed to differ, and we respect each others' opinions and the right to hold them. People can take from it whatever they wish. |
|
31)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91085)
Posted 14 Apr 2019 by Gary Roberts Post: That depends on how you define it. To me a Linux system is always a multi user system, even if there's only one person involved. There's always root, and system users like boinc for example, and the next "real" user equal to you is just one useradd away. That "single" user is in no way special just because there is currently no other.I think you're conflating multi-user with multi-tasking. Linux is a multi-tasking OS that's equally at home with running multiple tasks from whatever number of users the hardware is able to support- from zero to some maximum. My argument is essentially that operations that potentially adversely affect other users of the system (whether they exist or not) should require privilege escalation rather than an outright ban by removing the functionality. The root user should never be permanently logged in - only briefly as required, very much on a temporary basis. I've never said that a single user environment is in any way 'special'. My point is that a multi-tasking system is simply that - able to run multiple concurrent jobs quite independent of how many actual users there are. A BOINC user who chooses to run a Linux system in a "single user" style, and is taking advantage of functionality reserved for a privileged user, has every right to expect that functionality to remain, perhaps under password control to limit potential misuse if the user really didn't have authority to take that action. I can't imagine a significant need to take that action from within boincmgr (or boinccmd). Anybody and anything can suspend boinc without any privileges and if it really needs to be stopped or (re-)started, the "responsible" people already have other ways. I would strongly advise against making changes in this sensitive area just to add some rarely used shortcut.I really don't understand your point here. I thought the purpose of this whole thread was to garner user feedback about a proposal to remove some existing functionality from the manager that allowed a user to stop a boinc client under circumstances where they wouldn't be able to restart it without the ability/knowledge to re-launch the service mechanism that started boinc in the first place. Whilst I don't use the functionality personally, I know others do. I'm voting for finding a better way to protect the system than blanket removal of the functionality. Please correct me if I'm not understanding the purpose of this thread. There's no necessity for a special treatment here, it just makes things more complex without much gain.I'm not asking for special treatment. I'm asking that a better way than blanket removal of functionality (for everyone and every mode of operation) be found. If an ordinary 'buntu (or derivative) user needed to restart a client killed through the current manager functionality, all they would need to do is run the command sudo systemctl restart boinc-clientor something like that. I've never used any 'buntu type distro so I'm just guessing. I believe that an ordinary user gets root privileges without a password this way so if the whole idea behind removing functionality from the manager was to improve security, I don't see any improved security where literally anybody with user access could carry out stopping, starting, or restarting the boinc client whenever they liked, irrespective of the capabilities of the manager. What does gary@localhost do if he killed the boinc service at remotehost (which IMO he shouldn't have been able to)?localhost and remotehost could be sitting right next to each other or on opposite sides of the planet. With the correct setup (a properly set up secure shell - ssh) it makes no difference. If I want to stop the client on any of 100 different machines that I own, I issue a very simple command as gary@serverhost and it doesn't involve the functionality in the Manager that is currently being discussed. That command is (complete with user prompt) [gary@serverhost ~]$ ssh $Hnnn "./StopBoinc"where $Hnnn is a variable defined in gary's .bashrc which contains the hostname of the nnnth host in my farm. The server's /etc/hosts file contains all hostnames and their full IP addresses that the server needs to access. StopBoinc is a bash script that exists on all hosts whose purpose is to run the local boinccmd in the BOINC directory with the --quit option. I have set up full public/private key access between server and client machines so there is no challenge/response or other style of password authentication needed between the machines. The server knows the proper key for each remotehost. Each remotehost knows the proper server key. For starting the client remotely, there is a similar procedure with a more involved script called StartBoinc for performing basic checks and launching the client. I use the --daemon client option to have the client detach and run in the background when started. Stopping and restarting the client this way while a host is running normally is something that's rarely required but it works perfectly when needed. As he has no control over remotehost, except for the stupid boinc that is dead now, there's nothing he can do but ask root@remotehost (or equivalent) to take care of the situation. Fortunately that's not too much effort because they happen to be the same person, but that doesn't matter here. What does gary@localhost do if he killed the local boinc service? He'll have to contact root@localhost for the same reasons. Now some people assume they're the same person anyway and want to give gary the opportunity to prove it and have BM take care of the issue instead of root (who is assumed to be gary). My problems with that areEven if remotehost wasn't owned by me and if I had no access to root or the root password, I could operate as above as long as I had permission from the owner and as long as the owner was agreeable to the setting up of ssh access as described above. My ssh setup specifically denies root connections over ssh as a security measure. None of the client management scripts I run over ssh require root privileges. For the way I operate, there is nothing extra to implement so no "effort" at all :-). Yes, it works remotely - I'm doing it. I have no control over other parts (outside of the user's own files) of a remote system if I don't have physical access or the root password. With physical access, I have complete control without any passwords. The proposed changes don't really affect me since I own and have physical access to all machines on which I run BOINC. I figure there'll always be a way to achieve what I want to do. Do you use boinccmd to stop clients? In that case now you'd need some other way to start them again, and you could also use that way to stop. The question is, should boinccmd (and boincmgr) do both or nothing.The running client on my machines is not 'owned' by some system process. My interest is purely from the point of view of casual linux users who may have become used to a certain way of running things and may be surprised if that way were to suddenly stop working. I don't think there'll be much of an issue for experienced users but I could easily be wrong. |
|
32)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91083)
Posted 14 Apr 2019 by Gary Roberts Post: Richard, thanks for the link to the SETI discussion. I've read that now and I think it confirms my opinion that many people who use Linux to crunch BOINC projects, do so in a 'single user' type environment. I was interested to see that many choose to install BOINC under /home with the files owned by themselves for easier editing and the avoidance of permissions issues. I was also interested to see mentioned the lack of the old Berkeley shell archive as a very easy way for an ordinary Linux user to set up their own single user system. It was that lack that forced me to learn how to build BOINC for myself :-). Last time I looked, the packages/generic/sea directory still existed, although I don't bother to build a self-extracting archive. I just take the executables for boinc, boinccmd and boincmgr from their build directories and immediately incoprorate them into a new template tree with the standard set of ancilliary files and the full project tree for my projects of choice, ready to copy into place for a new install. My personal opinion is that (perhaps at first launch time) a user who has installed the repo package (perhaps in a 'system' area like /var/lib/boinc and owned by a special user 'boinc') should be presented with a series of dialog boxes that get the information needed to properly 'adjust' the install if a single user, self-owned, standalone system (or other particular requirement) is preferred. This would be a script set up by the distro's package maintainer and customised to the particular idiosyncrasies of that distro. It's not really a job for the BOINC developers. Perhaps some sort of 'template' could be provided for the package maintainer or even for the end user if the package maintainer didn't provide a working version. Different packagers (and not just different distros) probably have particular preferences for scripting language and style to be used. On top of that are the different init systems, and different methods for controlling services that exist for different distros. This approach should benefit any users of a particular Linux distro who are having issues to do with how the package maintainer has set up that particular package and its associated 'adjustment' script. They can immediately give feedback and perhaps resolve the issue locally with the package maintainer without troubling the BOINC developers, or expecting them to be on top of all the idiosyncrasies of hundreds of distros. One final point to emphasise. There is really no need for the mantra, "If the user didn't start it, the user shouldn't be able to stop it." It should be quite trivial to have a popup window appear and announce something like, "This is a privileged operation. Please confirm by entering the administrator (root) password". Even on my lowly distro of choice, I have a simple icon on the task bar to launch a root shell. If I click it, a simple dialog pops up asking for the root password. If I can get that right, a root terminal session immediately appears. Otherwise access is denied. This happens for lots of point and click stuff where privilege escalation is needed. Utilities like gksu, kdesu, sudo and others are in the repo should I want to build this functionality into any scripts I write. If you want to know why my distros' policy is to frown on the ITMOTB use of sudo, check out this official policy statement If you want to know what ITMOTB stands for, you'll need to read the statement. It's quite entertaining :-). |
|
33)
Message boards :
BOINC Manager :
Opinions requested from home Linux users
(Message 91077)
Posted 13 Apr 2019 by Gary Roberts Post: Richard, you and ChristianB seem to continue a discussion that started somewhere else. I and probably most people here don't know its history ...The discussion seems to be here. Linux, being inspired by Unix, is by design a multi user system and should be run like that, even if used by a single person. Don't try to make it look, feel and act like Windows, you'll continually fight against its basic design.Linux has evolved from Unix, so is brilliant as a multi-user system, but it's a bit of hyperbole to suggest that it's fighting against its basic design when used as an extremely capable single user system :-). For the question of starting the client in a "service" install I second ChristianB, you shouldn't be able to stop what you haven't started.Except ... you can easily have the best of both worlds by having a simple popup appear that asks for the root password if the user wants to take that action. To my mind this covers both situations - the multi-user environment where only 'responsible' people have that password and the true 'single user is administrator' environment. I would think that most Linux systems that contribute to BOINC projects fall into the latter category so I think single user systems need to be catered for and not overly penalised by complete removal of existing functionality. How are you going to restart a remote client that was your (the local user's) only connection to the remote system, and you just killed it?I'm not sure if I properly understand what you mean but if on my machines, I were to shut down a remote client from a local BOINC Manager, I could easily login over ssh and restart that client immediately. For me, I don't particularly care whether or not the functionality is removed from the Manager because I can stop or start clients (I have 100 of them) very simply over ssh. Occasionally, I might use the local manager to view a remote headless client but all my monitoring and control is done by scripts communicating over ssh. The scripts use boinccmd to do all sorts of stuff. I'd be concerned if boinccmd functionality was being removed :-). |
|
34)
Message boards :
Questions and problems :
PC shutting down when Boinc Manager is on
(Message 90871)
Posted 2 Apr 2019 by Gary Roberts Post: ... I did not mean the "Manager" per se was shutting me down, but apparently either the jobs that it was running or some setting for how and when the jobs run.I've been running a lot of machines for a lot of years. When any of mine shut themselves down (or crash) during crunching (ie. when loaded rather than not loaded), it's rarely to do with settings or types of jobs. It's mostly to do with age related issues with various hardware components that are exacerbated by the load. In the last week or so, I've had three such examples. These three had long uptimes and then started displaying the symptoms with increasing regularity. When that happens, I take the machine out of service and take it apart. One of the three turned out to be a 'dry' running PSU fan which caused the machine to reboot due to temperature limits. I lubricate such fans if they are not too far gone, record the information and put it back into service. Routinely, I get 2+ years of further service without problems, before I need to repeat the lubrication. The other two were due to bulging capacitors on the motherboard. It used to happen with PSUs as well but not so much lately because all my PSUs older than 7 years have had capacitor replacements. I have a lot of good PSUs (80+ efficient and made by SeaSonic) that are around 12 years old. Around 2012/13, I started noticing machines shutting down while crunching and then being 'difficult' to restart. On investigation, I found several key capacitors on the low voltage side showing signs of bulging. I replaced these with good quality Nichicons (all such PSUs over a period) and I haven't so far had to do any replacements of the replacements - fans, yes but caps, no. It's a similar story with motherboards. I have a lot of machines, dual and quad core from 2008/2009 that use the above PSUs. All of them have had some sort of motherboard cap replacements. I usually just do the obviously swollen ones so sometimes 6-12 months later I might have to do a couple more of the 'originals' that now show signs. The vast majority of those machines are still in service supporting GPU crunching where the CPU speed is not that critical. They seem more reliable these days with no CPU load, as long as I keep checking the motherboard caps. At the moment, the three cases I mentioned are all back crunching without further issue. The purpose of all this is to reinforce the message that key hardware components do have a 'use by' date and that the hot, high stress environment of the crunching load does tend to shorten that. You mentioned in your first message that you'd had no problems "for years" so (without knowing how many years) I would suspect your hardware might have a similar sort of issue to what I've been describing above. I'm not suggesting that you will be able to 'fix' such a problem. I happen to be in the very fortunate position of owning a high quality soldering iron and enough free time and energy to research how to fix these sorts of issues even though I have no formal training as an electronics tech. I also grew up in an age where the ethos was to repair rather than throw away. Unfortunately that mindset seems long gone - mainly because, for most people, it's now far more economic to replace than to repair. |
|
35)
Message boards :
BOINC client :
Fedora 29 - Boinc 7.14.2-16
(Message 90760)
Posted 20 Mar 2019 by Gary Roberts Post: Hi,Unless something has changed very recently, I think version 7.14.2 is the current version. Individual Linux distributions will download the source code and package it for distribution to people using that distro. The packaging staff will probably make a number of tweaks to the basic source code to make the product 'suitable' for that particular distribution. I imagine the -16 bit tacked on at the end probably identifies a particular set of such tweaks. To my knowledge, it doesn't come from the BOINC devs. The distro I use doesn't package BOINC so when I want to try out a new version, I download and compile the code myself. I have 7.14.2 running on several machines with no issue like you mention. Unless you are doing something really strange in the way you launch the client, I'm guessing that some sort of bug has been introduced in the packaging process and you will need to report your findings to the Fedora packagers. I'm guessing they will be the only ones able to sort out the problem. |
|
36)
Message boards :
Questions and problems :
Update GPU.
(Message 90472)
Posted 3 Mar 2019 by Gary Roberts Post: Gary, I run AMD GPUs, my RX470 already draws 200W under substantial load, the later versions only take more.Jord, first you post 275W and now its changed to 200W and that's supposedly unacceptably higher than some unspecified nvidia card that supposedly draws 250W. And "later versions" draw more??? I'm certainly not trying to have an argument with you. I'm just asking for a bit of fairness and balance when claiming that AMD are simply just unacceptable power hogs. Also I'm talking about crunching, not gaming, so I don't care about "bells and whistles". I think it's really great for both gaming and crunching that AMD are working on becoming a better competitor to nvidia and I hope this trend continues. We will all benefit from more fierce competition between them and I hope Intel can join the fray as well, as they seem to be intending to do. Peter has been doing measurements while tweaking the performance of his newly acquired RX 570. Here is a direct quote from a recent posting of his in the thread I linked to. It refers to crunching Einstein tasks 2x on an RX 570. When I was running at default conditions (and my wife was not playing solitaire), the 2X elapsed times were 20:15. I've now specified a -40% power limitation using MSIAfterburner, which has given a box level power reduction from 197.9 to 178.1 watts, or 10% while suffering an Einstein output reduction of only 1.5%. That power reduction, plus use of my old fan curve in MSIAfterburner, got the reported GPU temperature down from 82C to 69C, and moderately low fan noise.If there is one thing I know about Peter, it's that he is fierce about power efficiency and extremely thorough in the tests he performs. The final thing you wrote that puzzles me is the following:- The VII is rated for 300W, which in a day and age where we're supposed to be using power efficient hardware is stupidly high. I mean, if Intel released a CPU tomorrow that would have a TDP of 300W, would you buy and use it, or would you laugh them out of the building?I have no idea why you are comparing a top of the line GPU with some fictitious CPU. The Radeon VII compares extremely favourably with nvidia's top of the line units on power efficiency. Here is page 8 of a very thorough review which compares a whole bunch of top end GPUs from both companies. Look at the graphic (3rd from the bottom of the page) for the system power consumption of the Radeon VII as compared to the 1080Ti and the 2080Ti. Work out for yourself how bad AMD has become in comparison to nvidia. Look at the gain over Vega 64. Lower power consumption with a dramatic increase in compute performance. AMD should be applauded, not bagged. |
|
37)
Message boards :
Questions and problems :
Update GPU.
(Message 90462)
Posted 3 Mar 2019 by Gary Roberts Post: ... they are ASUS HD 7850 cards.I have a bunch of HD 7850s crunching at Einstein. I find them still very productive and OK as far as power efficiency goes. I've got no intention of shutting any of them down any time soon. AMD seem to be on quite a roll at the moment. The new Radeon VII (far too expensive for me) has amazing output and there is new architecture (code-named Navi) which is reputed to be released later in the year and with more affordable models. If you can wait, it might be interesting to see how that lot performs. If you need to upgrade now, GPUs like the RX 570 or 580 can be had very cheaply right now - probably because of the need to clear surplus inventory as a result of the downturn in the mining boom :-). |
|
38)
Message boards :
Questions and problems :
Update GPU.
(Message 90460)
Posted 3 Mar 2019 by Gary Roberts Post: ... AMD GPUs use a lot of electricity.I guess you haven't kept up with AMD's improvements in recent years :-). Was true several years ago but much improved now. Don't take my biased opinion about that. You might like to have a look at this particular thread over at Einstein. It was started by Peter Stoll (archae86), a long time nvidia user, because of the 'better' power efficiency of nvidia as compared to AMD. That aspect was very important to him. If you read the entire thread (wall to wall text - I know) you might just be interested in the process he went through which currently has him threatening to ditch nvidia completely in favour of AMD. There is also another thread about the new Radeon VII. In the fairly recent posts, a user has one with very good performance at Einstein. Take a look at this particular message where he documents a theoretical RAC of 1.7M for the use of just 280 watts total power draw from the wall. |
|
39)
Message boards :
BOINC client :
Boincmgr auto-launches boinc client
(Message 90363)
Posted 1 Mar 2019 by Gary Roberts Post: How can I prevent boincmgr from auto-launching the client?By not launching the manager if the client service is not already running, perhaps?? I'm running the client as a service with its own user. Starting it as my UI user just because it happens to be stopped messes up things (e.g. reinitializes all projects in my personal home directory).Maybe I'm not understanding your situation. Presumably, your client starts automatically when you restart your system. If you launch the manager, presumably there would be no problem connecting to the existing client. You would need to deliberately stop the service to have the client be "not running", to cause the problem you describe. So with no client running, what would be the purpose for launching the manager? Why do you not restart the client service before deciding to launch the manager? As far as I'm aware, and as described in the page you linked to (last updated 9 years ago, so things could have changed), the behaviour of starting a client (if one isn't running) when you launch the manager, is the way it has always been. I use Linux exclusively and always launch the client with the --daemon switch before ever launching the manager. But I run the client as my normal user so I won't have your problem even if I do things out of sequence :-). |
|
40)
Message boards :
Projects :
News on Project Outages
(Message 90214)
Posted 22 Feb 2019 by Gary Roberts Post: ... uploads failed around the time that Jim1348 reported that his uploads were stuck, and they haven't moved since.Uploads had started failing somewhat earlier. On one of my machines an upload succeeded at 7:42PM UTC (Feb 21st), whilst the next one at 7:59PM, and all subsequent, have been fails. The problem started at least a half hour before Jim's report. Interestingly, on that same machine, there were a couple of uploaded tasks that were successfully reported at 8:41PM UTC, nearly an hour after the uploads started failing. Not too long after that however, even reporting must have failed since I've noticed another machine with 3 uploaded tasks that hasn't been able to report them. All my machines are out of work with zillions of tasks stuck in upload and with multi-hour back-offs ticking down. It's around 8:30PM here and I've been hoping the problem gets fixed so that I can run a script to cancel the back-offs and then head off home. The script will also replenish data files from my cache to stop unnecessary downloads for resend tasks that will inevitably turn up once each host is able to start getting fresh work. Hopefully this might get sorted soonish :-(. |
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.