Posts by David Ball

1) (Message 4041)
Posted 18 Feb 2015 by David Ball
I've seen some talk in this thread about the nVidia GT 630 and wanted to mention that the GT 630 was released with two completely different chips powering it.

Two of the three variants of the GT 630 are Fermi based and one of the variants is Kepler based. The two Fermi based ones have 96 cuda cores and are basically a GT 440 with either DDR3 or GDDR5 memory and different clock rates. The Kepler based GT 630 has 384 cuda cores. All three variants are PCI Express 2.0.

There is also a GT 630 OEM version which appears to be Fermi based but has 192 cuda cores and is PCI Express 3.0. It draws twice the power of the Kepler card with 384 cuda cores. Also, several other specs for the OEM card match Fermi but not Kepler.

-- David
2) (Message 3906)
Posted 31 Dec 2014 by David Ball
During the long outage I removed asteroids from my machine. Now that the project is back up, I have been trying to re-attach my machine to asteroids but it waits a couple minutes on the

"Communicating with project
please wait..."

and then it says

"Failed to add project
please try again later
Click finish to close"

I've tried at various times of day and night but it always fails to add project. I have no problem viewing the project website in my web browser (Firefox 34.0.5) and I can even access my account and change the Resource share in the asteroids preferences. I just can't attach to asteroids@home.

I'm using BOINC client/manager version 7.4.36 on 32 bit Windows Vista with a core 2 E6420 (the original conroe 6400 but with 4 MB L2 cache instead of 2 MB) and 4GB of ram.

-- David
3) (Message 1295)
Posted 24 May 2013 by David Ball
I just increased my resource share for Asteroids@Home and the Asteroids@Home preferences page worked but it gives the following error once for each set of preferences. I have default and work preferences so I got it twice.

Warning: Creating default object from empty value in /home/boincadm/projects/boinc/html/project/ on line 206

I was able to change the preferences ok but I thought I should mention the error message.

David Ball
4) (Message 765)
Posted 31 Jan 2013 by David Ball
My buffers only run about .3 or .4 days total. I have different configs for duals and quads. I like to keep it where the BOINC manager tasks tab will fit on one page if possible. That's one reason the Seti WUs that have finished and can't report in clutter up the screen when I'm trying to get a complete picture of what's going on in that machine. FYI, Seti sends me an email if I don't participate for a while and they were so instrumental in getting BOINC going that I run about 1% Seti as sort of a BOINC tax. I long ago gave up on Seti finding anything. The projects that really interest me are the health related projects. Being in my late 50's, I have an interest in health projects making progress :-)

If you're wondering about the <dont_use_dcf/> in the schedular reply, go to the main BOINC data directory on your machine and look at the first few lines in a file called sched_reply_asteroidsathome.net_boinc.xml . You'll find that it starts with something like


When I saw the <dont_use_dcf/>, I searched the BOINC website for that phrase to find out what it did. I even found where David Anderson checked in a related changeset. See which begins with

Changeset 7df3c15 in boinc

Timestamp: 06/14/12 09:14:52 (8 months ago)
Author: David Anderson <davea@…>
Branches: master, client_release_6.8, client_release_7.0a, client_release_7.0b, rwalton/UndoWxWidgets30Merge, rwalton/wxWidgets30
Children: 18f4124
Parents: 5ee4f48
git-author: David Anderson <davea@…> (06/14/12 09:14:52)
git-committer: David Anderson <davea@…> (06/14/12 09:14:52)
Message: scheduler: send <dont_use_dcf> only if client is 7.0.28 or later.
svn path=/trunk/boinc/; revision=25759
Files: 9 edited

BTW, I got the C2Q Q6600 crunchers cheap and use them for heaters in the winter. They get shut down in the warm months. When I start them up after a several month absence, the BOINC client aborts all the WUs that are past deadline but have never started. I don't remember what it does with WUs that are months past the deadline but have already done some work. I might have had to abort those manually.

The machine that has 22 projects is sort of my master control where I see what's going on with all projects that are still active. It uses the work profile and some projects on it have the resource share set to 0.001 which means they never get work. The health related projects can go as high as a resource share of 35. I also run a small resource share like 3 on some newly started projects to help them get going and work the bugs out before they go into production. I have points in many projects that no longer exist. I guess I should put my project list in my sig on asteroids. :-)

One of these days, I'm going to download the BOINC client source and build it. I started as a programmer by writing programs and firmware in the 8080/8085/Z-80 days on CP/M and MP/M. I've written a lot of microprocessor assembler, C, and C++. When I started writing C++, we had to use "compilers" that output C code instead of compiling to machine level. Most lines of C++ produced about 6 to 8 lines of C code which mostly consisted of the characters '(' and ')'.

Hope this answers some of your remaining questions.
5) (Message 762)
Posted 30 Jan 2013 by David Ball
Dagorath said:
That's why you need to keep a small cache. What has happened is they screwed up the numbers that allow BOINC to estimate how long the tasks take. I'm getting the same thing... estimate of 12 minutes but they end up needing 3 hours. However I keep a very small cache so I won't have any trouble meeting deadlines. These guys screwed up this week, next week it will be some other project, it's a never ending cycle. Either you plan ahead for the screw ups and have it easy by setting a small cache or you run into deadline trouble and fight with it all the time. Take your pick, whatever creams yer twinky.

OK, so what are you using for min and max work buffer size? Between having an almost non-existant buffer, and having <dont_use_dcf/> in the scheduler reply, I can think of several potential problems. I'm using the currently recommended BOINC version on Vista 32 bit - BOINC client 7.0.28. From what I can tell, <dont_use_dcf/> was originally intended to prevent going into EDF mode.

FYI, I had never noticed the <fetch_minimal_work>1</fetch_minimal_work> flag until I had written the parts below based on using a very short work queue. it's been a while since I had to get into cc_config.xml.

1. Since it's being told to ignore DCF in the project scheduler reply, it's not just ignoring that project for EDF mode decisions, it's never incrementing the DCF at all for that project. On my machines, I'm seeing estimates from 17 - 20 minutes and actual run times in the 5 hour range. With time estimates like that, even with very small buffer sizes, the quads are getting something like 40+ WUs. Also, what does this do to other projects which don't return <dont_use_dcf/> in their scheduler reply.

2. Some projects like RNA have work units with estimated runtimes of almost 60 hours. Will it fetch work for these if I shrink the cache size on the quads so that it will only ask for 20 minutes * 4 cores?

3. What about busy projects like Seti where it can take many tries to actually get through to the scheduler and the BOINC client will apparently move on to another project.

4. What about projects like POEM where people have multi-day buffers and snatch up all the GPU WUs within a very short period of time and the rest of the day there aren't any GPU WU available unless someone aborts one.

5. Some projects are so busy that it makes the admins mad if you keep contacting them over and over because your cache isn't big enough or you have the <report_results_immediately>1</report_results_immediately> flag set or have the <max_tasks_reported>N</max_tasks_reported> flag set to a small value.

I'm not sure if it's because some projects are returning <dont_use_dcf/> or that I have a small work queue but I'm seeing other projects (LHC for example) where they cut it really close on going into priority mode on some WUs of about 10 hours even though that is the only project with WUs due in the next several days and there are no asteroids WUs on the machine.

On a side note, this could actually help projects like EON where the WUs really do take only 20 minutes to run. With a short work queue and EON limiting the number of WUs allowed to 2 * core count, I'm already having problems getting any work done on EON unless I set everything else to not fetch work from any other projects on one of my machines. I'm not positive but, from what I can tell, once a quad gets 8 WUs and is refused further WUs, the BOINC client penalizes the projects priority and moves on to another project.

FYI, of the 22 projects the machine I'm writing this on, 5 of them have <dont_use_dcf/> set in their sched replies: Asteroids, POEM, NFS, Milkyway and WCG.

It's late and I'm exhausted so I hope this makes sense. I'm sure I left some other things out but this should get some discussion started.
6) (Message 750)
Posted 27 Jan 2013 by David Ball
Dagorath wrote:
Given the CPU speed your other concern would be deadline. It looks to be 14 days so I would say there's a good chance you would be able to complete one. DCF for this project is close to 1 on my hosts so tasks are giving good duration estimates here. Usually that means if the scheduler figures it'll be OK it usually is.

What are you seeing for DCF now? Mine was about 1 and the estimated duration was about correct. With the latest batch of WU, the estimated duration is in the 17 to 20 minute range on my machines but they're taking about 5 - 6 hours to complete. The GFLOPS estimate (31501) on the current WU which begin with ps_130122_98 is much lower than the previous WUs. I wish I had written down the GFLOPS estimate on an old WU when I first noticed this and still had one but I just thought something (maybe a command from the server) had reset the DCF to 1 on my crunching machines (mostly C2Q Q6600s). IIRC, the old GFLOPS estimate was at least one or 2 digits longer and began with "18".

I'm running BOINC 7.0.28 on Vista 32 bits on all the machines. My one Vista 64 bit machine (another Q6600 quad) has been down for a disk failure. It even fails the short test in S.M.A.R.T.. Since 32 bits is no longer enough, I'm going to be doing some OS upgrades to 64 bit soon - have more memory on order and already bought Win7 pro (full version) for one machine and the cheap Win8 upgrade for another. I think the Win8 upgrade will let me switch a machine from 32 to 64 bits if it sees the valid Vista installation or I give it the number from the Vista certificate HP stuck on the box. All the quads are HP boxes which came with Vista pre-loaded. I'm also planning to upgrade a machine from Vista to the latest CentOS Linux version so I can do some server software development and testing locally.

Are you seeing the same DCF and time estimate problem on recent WUs?