| Info | Message |
|---|---|
| 1) Message boards : BOINC client : multiple NVIDIA GPUs
Message 42829 Posted 2 Mar 2012 by Metod, S56RKO |
Just for the record: now I'm running BOINC CC 7.0.18 and it still doesn't want to run tasks with requirement of more than 1.0 NVIDIA resource (thus leaving both GPUs idle). |
| 2) Message boards : BOINC client : multiple NVIDIA GPUs
Message 42827 Posted 2 Mar 2012 by Metod, S56RKO |
On this host I have multiple projects running: CPDN, Seti, Einstein and now Moo!. I don't have proper CUDA application for Seti (yet, see problem description right at the end of this post), Einstein provides with nice CUDA application. However, during this tests I disabled Einstein so it's only Moo! that wants to use NVIDIA. As BOINC CC decided NVIDIA resources were not ample enough, both GPUs stayed idle. If I edit client_state.xml and decrease count of CUDA for Moo! to 1.0, BOINC CC starts a couple of Moo! tasks. This is far from ideal as both tasks want to run on both GPUs. There's some discussion on Moo! boards about making dnetc application nicer - so that it would only occupy designated GPU and not all of them. However, as this project is only a wrapper around different type of distributed computing project, it's not totally in hands of project management to make needed changes to the crunching (I just can't call it science) application. I already tried to run newer BOINC CC but I'm unable to use Berkeley-provided executable - my OS distribution is somehow elderly so system libraries are too old. I probably should compile BOINC CC on my own. I would like to get some indication about whether this problem (single task requiring multi-GPU resource) is known to developers and if there had been some work done about it before I jump on it. |
| 3) Message boards : BOINC client : multiple NVIDIA GPUs
Message 42823 Posted 2 Mar 2012 by Metod, S56RKO |
I've recently installed two video cards in my Linux box. They are Nvidia GT 430. BOINC CC sees them just fine:02-Mar-2012 13:30:51 [---] Starting BOINC client version 7.0.2 for x86_64-pc-linux-gnu 02-Mar-2012 13:30:51 [---] This a development version of BOINC and may not function properly 02-Mar-2012 13:30:51 [---] log flags: file_xfer, sched_ops, task, coproc_debug, cpu_sched, cpu_sched_debug 02-Mar-2012 13:30:51 [---] Libraries: libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18 02-Mar-2012 13:30:51 [---] Data directory: censored 02-Mar-2012 13:30:51 [---] Processor: 8 AuthenticAMD Dual-Core AMD Opteron(tm) Processor 8218 [Family 15 Model 65 Stepping 2] 02-Mar-2012 13:30:51 [---] Processor: 1.00 MB cache 02-Mar-2012 13:30:51 [---] Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 02-Mar-2012 13:30:51 [---] OS: Linux: 2.6.36.1 02-Mar-2012 13:30:51 [---] Memory: 63.05 GB physical, 56.83 GB virtual 02-Mar-2012 13:30:51 [---] Disk: 66.40 GB total, 20.64 GB free 02-Mar-2012 13:30:51 [---] Local time is UTC +0 hours 02-Mar-2012 13:30:51 [---] NVIDIA GPU 0: GeForce GT 430 (driver version unknown, CUDA version 4.20, compute capability 2.1, 1024MB, 1001MB available, 280 GFLOPS peak) 02-Mar-2012 13:30:51 [---] NVIDIA GPU 1: GeForce GT 430 (driver version unknown, CUDA version 4.20, compute capability 2.1, 1024MB, 1001MB available, 280 GFLOPS peak) 02-Mar-2012 13:30:51 [---] OpenCL: NVIDIA GPU 0: GeForce GT 430 (driver version 295.20, device version OpenCL 1.1 CUDA, 1024MB) 02-Mar-2012 13:30:51 [---] OpenCL: NVIDIA GPU 1: GeForce GT 430 (driver version 295.20, device version OpenCL 1.1 CUDA, 1024MB) 02-Mar-2012 13:30:51 [---] NVIDIA library reports 2 GPUs Tasks requiring NVIDIA coprocessor run fine until their requirement is <coproc><count>1.0</count></coproc>. If this gets larger than 1.0, then it doesn't work at all. One example is project Moo! Wrap, which is a wrapper for DNETC projects. Their science application grabs all available GPUs. Project scheduler this correctly indicates by setting coproc count to 2.0. However BOINC CC claims that my system doesn't have enough NVIDIA GPUs available: 02-Mar-2012 13:30:53 [Moo! Wrapper] [cpu_sched_debug] insufficient NVIDIA for dnetc_r72_1330613363_72_192_0 Any idea about this? |
| 4) Message boards : BOINC client : OS X GPU Calculations While Running as Daemon
Message 42822 Posted 2 Mar 2012 by Metod, S56RKO |
I have read that on Linux versions X needs to be loaded before BOINC loads, in order to be able to detect the GPU. Not really, only the kernel driver needs to be loaded. Indeed this part gets done when X server starts. One can, however, load this driver by hand. A gotcha: this is true for NVIDIA. I have yet to discover a way of doing it with ATI/AMD drivers. |
| 5) Message boards : BOINC client : Preferences for task priority?
Message 21857 Posted 16 Dec 2008 by Metod, S56RKO |
I'm currently running BOINC on my Linux OS ... Which breed of Linux? Some breeds including Ubuntu are reportedly lowering CPU clock when there are no normal-priority tasks running. Well, low priority really means that task doesn't insist on getting any decent amount of CPU power anyway. Best advice for machines that are supposed to run BOICN projects would be to de-activate such functionality of OS. Power management rings the bell for me ... If your try to run BOINC apps with normal (or not so much niced) priority, then it can get into the way when machine is not used only for interactive work, but also for some more serious jobs (like gaming ;-) ). |
| 6) Message boards : BOINC client : Coarse-grained throttling and efficiency
Message 21596 Posted 1 Dec 2008 by Metod, S56RKO |
I'm curious as to why BOINC throttling was designed to be coarse-grained. Is this a more efficient throttling method or is it just easier to implement? Maybe I'm wrong but I don't know any OS that would allow application to define how much of a CPU it should allow (eg. 50%). The only thing that OS does do (and it should do it well) is to schedule between apps that want to get CPU according to their priorities and across CPUs available (if there are more than one). If you see split 70:30 between CPUs with only one app running then that means that scheduler of your OS of choice doesn't do its job too well. Which in turn means that the only way of telling OS that an app shouldn't run as much as possible is to suspend it occasionally. Which is, as you noticed, a bit coarse-grained. Much like your microwave oven that only has magnetron with fixed power. If you place two cups of food into the oven, each cup (or rather its contents) will get roughly half of radiation (and thus energy). The only way of reducing CPU power scheduled for BOINC app is to reduce CPU's clock. Ubuntu Linux does it for low-priority jobs (BOINC processes are generally such) which was not really welcome by many dedicated BOINC users. |
| 7) Message boards : BOINC client : How to install BOINC in freebsd.
Message 20083 Posted 11 Sep 2008 by Metod, S56RKO |
2) Should the options following CONFIGURE_ARGS= be inside double quotes? njnu1115 does not use the quotes, Metod does. Which form is correct? As this is Makefile they probably shouldn't be enclosed by double quotes. Mea culpa. [edit] I don't know much about FreeBSD either ... [/edit] |
| 8) Message boards : BOINC client : How to install BOINC in freebsd.
Message 20059 Posted 9 Sep 2008 by Metod, S56RKO |
/usr/ports/net/boinc-client/ While your solution most likely works it's not how it should be done. The problem is that it will request linux client even from the projects that are offering FreeBSD client (or are going to). The proper way to do is to use --with-boinc-alt-platform=i686-pc-linux-gnu instead and leave the 'original' boinc platform setting intact. Or rather fix it to be correct for FreeBSD (I'm not sure about the correct one, it might as well be i386-unknown-freebsd or something). [edit] According to official? list of BOINC platforms, it's rather i686-pc-freebsd or x86_64-pc-freebsd, depening on OS bitness. Which means that complete CONFIGURE_ARGS line would look like this: CONFIGURE_ARGS="--disable-server --with-boinc-platform=i686-pc-freebsd --with-boinc-alt-platform=i686-pc-linux-gnu" or CONFIGURE_ARGS="--disable-server --with-boinc-platform=x86_64-pc-freebsd --with-boinc-alt-platform=i686-pc-linux-gnu" for AMD64 / X86_64 FreeBSD. [/edit] |
| 9) Message boards : BOINC client : HOW TO install BOINC with Fedora 9 ?
Message 19663 Posted 21 Aug 2008 by Metod, S56RKO |
PS: The following is from /var/log/messages I've deleted a couple of lines from your messages, but please note time stamps ... Probably booting kernel and loading network interface driver: Aug 14 07:26:24 localhost kernel: sis190 Gigabit Ethernet driver 1.2 loaded. Aug 14 07:26:24 localhost kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 19 (level, low) -> IRQ 19 Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Read MAC address from EEPROM Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Unknown PHY transceiver at address 1. ... Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Using transceiver at address 1 as default. Aug 14 07:26:24 localhost kernel: 0000:00:04.0: SiS 191 PCI Gigabit Ethernet adapter at f88bc000 (IRQ: 19), 00:1e:33:03:02:ae Aug 14 07:26:24 localhost kernel: eth0: RGMII mode. Aug 14 07:26:24 localhost kernel: eth0: Enabling Auto-negotiation. Then, probably early during initialization, NetworkManager gets started: Aug 14 07:26:28 localhost NetworkManager: <info> starting... Aug 14 07:26:28 localhost NetworkManager: <info> eth0: Device is fully-supported using driver 'sis190'. Then something strange: kernel driver declares ethernet link not ready and notifies NetworkManager of it: Aug 14 07:26:32 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Aug 14 07:26:32 localhost NetworkManager: <info> (eth0): device state change: 1 -> 2 Aug 14 07:26:32 localhost NetworkManager: <info> (eth0): bringing up device. Aug 14 07:26:32 localhost NetworkManager: <info> (eth0): preparing device. Aug 14 07:26:32 localhost NetworkManager: <info> (eth0): deactivating device And then, after a while, voilá, kernel driver finds ethernet link alive: Aug 14 07:26:42 localhost kernel: eth0: mii ext = 0000. Aug 14 07:26:42 localhost NetworkManager: <info> (eth0): carrier now ON (device state 2) Then it takes a short while to get network interface configured: Aug 14 07:26:44 localhost NetworkManager: <info> address 192.168.11.2 Aug 14 07:26:44 localhost NetworkManager: <info> netmask 255.255.255.0 Aug 14 07:26:44 localhost NetworkManager: <info> gateway 192.168.11.1 Aug 14 07:26:44 localhost NetworkManager: <info> nameserver '192.168.11.1' If you observe time stamps carefully you can see that it takes 16 seconds between starting network configuration (NetworkManager in your case) and finishing it (marked by LAN connectivity ready). The most disturbing period of time is those 10 seconds when ethernet link is considered not ready. There are a couple of reasons for that. One is delay caused by peer device (ethernet switch / router) during which some kind of auto-negotiation can take place. This was not so uncommon years ago, but should be almost instant these days. The other possibility is that this is caused by kernel driver and/or userland software (NetworkManager) if parts of network interface (MII transciever in particular) gets reset during some stage of initialization. Some time is then needed to recover. There are many other possibilities as to why there's a 10 second delay. As I already wrote in my post, the root of your problems is the fact that network gets configured in background (to speed-up the booting procedure). I also described a good cure: make a sleep-loop until default route gets configured. |
| 10) Message boards : BOINC client : HOW TO install BOINC with Fedora 9 ?
Message 19177 Posted 5 Aug 2008 by Metod, S56RKO |
Mex, please, could you try changing the following line in the *original* init script: This is ugly as normally desktops don't run DNS server. Rather than straight sleeping for 12 seconds, one could implement a search for default route to appear. With optional max delay, such as this: MAXWAIT=30 # wait for no longer than 30 seconds
WAIT=0
ISROUTE=`/sbin/route -n | grep "^0.0.0.0" >/dev/null; echo $?`
while [ ${ISROUTE} -eq 1 -o ${MAXWAIT} -gt ${WAIT} ]; do
sleep 1
ISROUTE=`/sbin/route -n | grep "^0.0.0.0" >/dev/null; echo $?`
let WAIT=${WAIT}+1
done
This should mostly take care of no net connectivity at boot time. The problem of users with laptops using WiFi sporadically still remains though. Hmmm ... I'm sure that the loop could be done a bit more elegant by moving the route construct to while line directly. I couldn't figure it right now ... [edit] Anyway its really strange to me that your network takes so long to come up. Mex, I wonder if you're using static IP addresses or DHCP assigned ones? I've seen quite long network startup times when DHCP was in play ... sometimes DHCP servers just take some time to respond. |
| 11) Message boards : BOINC client : Version 6.2.14 Will Not Install Properly
Message 19150 Posted 4 Aug 2008 by Metod, S56RKO |
Does anyone apart from me think that the 'Customize installation options' step of the installer could confuse many users? I can't but agree. I find the installation process for 6.2 quite confusing, while I consider myself quite advanced user. Specially as it (IMHO needlessly) differs from the one for 5.x quite much. For example: what's wrong with allowing user to select account under which boinc should run? My guess is that majority of my upgrade problems arise from the fact that the account used is forcibly different and that there's a clash with security permissions between the two. |
| 12) Message boards : BOINC client : Version 6.2.14 Will Not Install Properly
Message 19044 Posted 1 Aug 2008 by Metod, S56RKO |
Is there a nice way to upgrade from 5.10.x to 6.2.14 on Windows? I've tried on a couple of boxes and after long struggles I somehow managed to do it on all but one (reverted to 5.10 on that one). The funny thing is that I can't seem to get it working even if cleanly installed. Any thoughts about that? [edit] Ah ,yes, I'm running boinc as service (or whatever it's called these days. [/edit] |
| 13) Message boards : BOINC client : BOINC v6.2.14 Install on Ubuntu Problems !!!
Message 19026 Posted 1 Aug 2008 by Metod, S56RKO |
I actually have 2 version of BOINC installed right now so I need to do a little work to see if I can't move files from the old v5.10.45 Directory to the new v6.2.14 Directory, if not I'll just run out the Wu's and leave the v5.10.45 where it's at in case I don't like the v6.2.14 and need to go back to it again ... :) You can move projects and work-units from old to new installation: 1) Stop any/both boinc 2) From old installation, copy the following: client_state.xml, account_*.xml, gui_rpc_auth.cfg and remote_hosts.cfg to the root of new installation (that's where the new binaries are). 3) You need to copy (recursively) also the following: slots and projects - these are file folders. Destination of these folders is again root of the new installation. 4) Make sure that account that will run boinc has read and write permissions on all the new files (special care needs to be taken for those you've copied in steps 2 and 3). 5) start the new boinc A side note: I try not to fiddle with start-up scripts etc. too much. So I rather start boinc CC from cron job every 5 minutes or so. The process is not straight though as usually it's not safe to blindly start new boinc instance while another one is already running. |
| 14) Message boards : BOINC client : HOW TO install BOINC with Fedora 9 ?
Message 18915 Posted 29 Jul 2008 by Metod, S56RKO |
Next time I boot my notebook, I will type "chkconfig --list" and post the output BEFORE I restart the client, as the current output is after a restart when the client is able to connect to the projects servers. My guess is that you got bitten by delayed DHCP configuration. There are two strategies to start while network configuration is done via DHCP:
|
| 15) Message boards : BOINC client : BOINC Communication Bandwidth Question
Message 16150 Posted 31 Mar 2008 by Metod, S56RKO |
I'm not sure if there is any standard on uppercase/lowercase 'k', but it doesn't usually matter. In IT, standards seem to be governed by marketing guys. In science, though, there's standard saying that lower case letters are used as prefix for unit multiplier smaller than 1 while upper case letters are used as prefix for unit multipliers larger than 1. Notable exceptions from this standard are prefixes 'k', 'h' and 'da' which all denote multipliers larger than 1. They are lower case due to historical reasons (da is particularly ugly beast being two-letter prefix). See also Definitions of the SI units. |
| 16) Message boards : BOINC client : Dual core
Message 15791 Posted 11 Mar 2008 by Metod, S56RKO |
If CPDN gives work with a deadline that has a far enough deadline so it will stick to its Resource Share all the way through, I'd consider computing there again. Some work given out by CPDN recently really had too short deadlines. But things are changing for better ... last WUs I've received from CPDN have estimated CPU time of 25 days on my P4 Xeons and deadline set to 5 months in future. That looks fine to me. |
| 17) Message boards : BOINC client : Problem with cpu use on HyperThreading & multicore app
Message 15372 Posted 12 Feb 2008 by Metod, S56RKO |
But when I run x264, a multicore aware video encoding application, BOINC is not respecting something and never lets go of one of the cores and forces that other core to share time with x264. This of course gives lackluster encoding performance but can only be remedied by stopping the BOINC service. If you're not setting CPU affinity manually and you're using official BOINC Core Client (which doesn't have CPU affinity setting functionality), then it's really not up to BOINC CC to move science applications from one (logical) CPU to another if needs arise. That's up to OS CPU scheduler - some OSes have more decent ones than the others. |
| 18) Message boards : BOINC client : sharing project files
Message 14260 Posted 11 Dec 2007 by Metod, S56RKO |
I have 2 Ubuntu instances on two different drives within a single machine (one 64bit, one 32bit). Basically I've been running 32bit for a while but want to move towards 64 bit Ubuntu. As a part of testing it I'd like, when I boot to either system, to work on the same project files. Is this possible? If so how? If your 64-bit Ubuntu is set up so that you can run 32-bit applications, then you should be able to run the same BOINC instance in either of your Ubuntus. Just run 32-bit BOINC under either bitness ... |
| 19) Message boards : BOINC client : Linux x64 5.10.28
Message 13930 Posted 17 Nov 2007 by Metod, S56RKO |
I've just tried to install 5.10.28 x86_64 on various non-Ubuntu boxes that I have. I'm running boinc as service and I don't use boinc manager on those boxes, so my experience is a bit limited. Anyhow, here's what I found out:
|
| 20) Message boards : BOINC client : Scheduler weakness
Message 13214 Posted 23 Oct 2007 by Metod, S56RKO |
When a project is in a deferral for any reason (including NNW and suspensions) the LTD basically does not change. It changes when another project or projects is hogging the CPU or the queue on the host. There is some drift when all LTDs are normalized but it usually takes much longer to make a substantial difference. I agree with what you write. But: the problematic behaviour is when client can not connect project scheduler (eg. when project scheduler itself is down) ... in this case LTD builds up. As far as I can see this case (connection to project scheduler unsuccessful) is handled just the same way as the case when client doesn't request any work due to other reasons (eg. EDF, too low LTD, ...). |
Copyright © 2025 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.