Posts by Bill Hepburn

InfoMessage
1) Message boards : BOINC Manager : 2 profiles: computer idle / working in the computer
Message 46675
Posted 9 Dec 2012 by Bill Hepburn
You might try adjusting your computing preferences. It's not a perfect solution, but it gives you most of what you want.

I, too, found that allowing the GPU to compute causes me problems when I am working, so I set "Suspend GPU work while computer is in use?" to yes.

I find that BOINC gets out of the way well enough that I don't need to "Suspend work while computer is in use".

Since it's a laptop, you might want to "Suspend work while computer is on battery Power" to give you more work time before the battery needs recharging.

Just go to one of your projects web sites, and it's there under "Preferences".
2) Message boards : Questions and problems : Multiple Projects
Message 45477
Posted 30 Aug 2012 by Bill Hepburn
I am convinced that something is weird with the "new" work fetch. There are far too many complaints that it doesn't fetch enough work, or what it does fetch is not what is expected. Some of this can be attributed to a lack of understanding on the part of the complainer, but I don't believe that it all can be.

The standard answer of "leave it alone and it will sort itself out on it's own" hasn't worked for me. I have mostly left it alone for a couple of months now and it's still weird.

I am running BOINC 7.0.28, on several machines. CPU runs Malaria, Rosetta, and LHC Sixtrack all with a resource share of 100. Work fetch seems to work reasonably well, at least I don't seem to run out of work very often, and the task list usually has a mix of projects. I have the "keep enough work" settings around .25 days each.

GPU is a totally different thing though. I run Seti with a resource share of 100, and Einstein at 5 on GPU only one computer. Machine is Win7 pro and an nVidea GTX 460 with 301.42 driver only. GPU crunching turns off when I use the computer, and all computing turns off in the afternoon (temperature and high utility rates).

I would expect Seti to run much (20 times) more than Einstein, Einstein filling in during Setis' maintenance and connectivity outages. However, Einstein runs about 4 times as much as Seti. I have seen it request tasks for Einstein and not Seti, even though it has been running Einstein for half a day or more. Of course that fills up the cache for a few more hours of Einstein.

It is curious.
3) Message boards : Questions and problems : Is resource share still considered?
Message 45015
Posted 21 Jul 2012 by Bill Hepburn
I am running BOINC 7.0.28, 64 bit on Windows 7 Professional, although I noticed this shortly after switching to BOINC 7.0.xx.

I run Seti with a resource share of 100, and Einstein at 5. Both run on the nVidea GTX 460 with 301.42 driver only. The i5 CPU runs Malaria, Rosetta, and LHC Sixtrack with a resource share of 100. GPU crunching turns off when I use the computer, and all computing turns off in the afternoon (temperature and high utility rates).

The CPU works as expected, but I would expect Seti to run much (20 times) more than Einstein, Einstein filling in during Setis' maintenance and connectivity outages. However, they both run about equally, and I have seen it request tasks for Einstein and not Seti, which of course fills up the cache for a few more hours of Einstein.

I have adjusted the keep enough and additional work settings (staying under 1 day total), and they both been at .25 days for quite a long while now. That works to keep the computer crunching, just not necessarily the projects I expect.

I really don't care, I have nothing against Einstein, I just never got interested. It is curious.
4) Message boards : BOINC client : WU stuck downloading prevent getting another projects work
Message 39610
Posted 12 Aug 2011 by Bill Hepburn
You are probably right. It just seems to me like it ought to be able to figure out that if it is out of work ready to start it should get some from anybody that has it. Figuring out how much might be a bit dicey, but some minimum amount should work. If the work that was stuck comes flowing in, so be it, it would be delayed by the amount of time the work unit in progress takes to reach its task switch interval or finish. I don't know if that would cause deadline issues later or not, probably would depend on how many units were stuck in the queue.

It really doesn't make all that much difference, when it goes idle, I save a bit of electricity. I haven't figured out what to do with all of those "credits" I have accumulated anyway.
5) Message boards : BOINC client : WU stuck downloading prevent getting another projects work
Message 39601
Posted 12 Aug 2011 by Bill Hepburn
And therein lies the rub. Those WUs may sit stuck in the queue for days (depending on how jammed up Seti is) while the "backup" project is never asked for work.

This seems to be the usual failure mode for the past several months. If this is how the scheduler is supposed to behave, it does away with the value of a "backup" project.
6) Message boards : BOINC client : WU stuck downloading prevent getting another projects work
Message 39594
Posted 11 Aug 2011 by Bill Hepburn
I'm using 6.12.33, but I seem to remember this problem in years gone by as well.

I am running SETI and Einstein on my GPU only. Rosetta, Malaria, and LHC run on the CPUs. All are equal priority 100, except Einstein which is 5.

I have only seen this on SETI/Einstein. When SETI downloads get stuck (the network traffic thing), the computer runs out of GPU work pretty quickly and never tries to get Einstein work. If SETI just runs out of work (nothing stuck in the download queue), it downloads Einstein as expected and keeps on working. CPU projects seem to work as expected.

Any ideas?
7) Message boards : BOINC Manager : Malaria Control
Message 10849
Posted 11 Jun 2007 by Bill Hepburn
This is probably exactly the wrong place to ask this, but has anyone seen malariacontrol.net lately? I can't seem to be able to raise them, and since I currently support them, SETI and Rosetta, only one is getting any time (not that they are complaining). Is there any possibility hat the malaraacontrol problem and the SETI problems are the same problem (an intense hatred for AMD 64x2 or something :0) - I don't know whether there are also problems in non Linux boxes)?

I'm seeing the same thing and I'm running Windows on Intel iron so you can't blame AMD for this one. Completely separate projects, on completely separate continents... coincidence I would guess. Odds are somebody will be coming to work at malariacontrol shortly and kick their servers.

8) Message boards : BOINC Manager : Odd quirk in scheduling 5.8.16
Message 10501
Posted 26 May 2007 by Bill Hepburn

Shortly after I posted here, a couple of WU's finished and it started others. So I decided it probably was a Rosetta problem and posted there. Now looking at the log, the only mention of that WU was the two lines when it started. Nothing about stopping or pausing it. Oh well, the CPU ate it. Curious, but no big deal.

the few times I've seen this behaviour is actually with a message 'waiting for memory' when a model got too big for the ram allocated to BOINC. The defaults for memory allocation is I think still 50% when in use and 90% when idle (from the 5.8.x versions). Have you checked at the Rosetta forum?

9) Message boards : BOINC Manager : Odd quirk in scheduling 5.8.16
Message 10499
Posted 26 May 2007 by Bill Hepburn
BOINC 5.8.16 running as a service on WinXP Pro.

I am attached to Rosetta, Malaria, and Seti on a Pentium D. I have set my "switch every interval" to 300 minutes to allow work units to complete before switching.

The machine has been on overnight. I just noticed that there is a completed Seti and Malaria WU to upload. There is a Rosetta WU running (1:30 and 50%) and a Malaria WU at (1:00 and 75%). There are no report deadlines for the next couple of days. All short term debt values are between +1000 and -1000. Nothing odd there. But there is another Rosetta WU sitting at 2:15 and 75% "Waiting to run".

There are WUs from all projects waiting to start. I am a bit baffled why the one Rosetta WU might have gotten stopped, and even more baffled why it would have started a new Rosetta with one partially completed. The one waiting has a deadline closer than the one running.

Of course, in a few hours I'm sure they will all be completed, uploaded, and gone from sight. but it does seem odd.
10) Message boards : BOINC client : Scheduler and CPDN
Message 2856
Posted 29 Jan 2006 by Bill Hepburn
I certainly won't try to justify bad estimates. It is annoying that a bad estimate makes a problem with the work scheduler when it is working exactly as it should.

I wonder what would happen if you let CPDN run in EDF until it runs through about half the model. That would probably take about three months. By then, it would probably think it would need about 5000 hours more and probably drop out of EDF. Figuring out exactly when that would happen is more than my brain can handle right now.

I have to wonder if the folks at CPDN think they only want (or need) really hot computers. In the past few months we have gone from the SLABs to the sulphur models. Now you say there is a new one that will take even longer. I suppose that as long as they get enough computer horsepower from hot machines, they are happy, and nothing much will change. If their requirements get too out of hand, they may have to rethink things, or mayby Moore's law will keep them going indefinitely.

Cheers.
11) Message boards : BOINC client : Scheduler and CPDN
Message 2845
Posted 29 Jan 2006 by Bill Hepburn
That's a problem with those long run times for CPDN. It's even worse since CPDN does such a poor job of estimating how long it will take. BOINC is supposed to figure out a correction factor for each project after it has run a number of work units. The rub is that with a CPDN work unit taking several months, it will be a year before the correction factor does much good. There doesn't seem to be a lot of interest on the part of the program (priorities, and staffing I assume) to fix the problem.

In theory, you should be able to just not worry about it, let it run in and out of EDF mode.

I have a machine (1.7 GHz) that will really take about 2000 hours to do a work unit (which it thinks it will be 3000). Since there are only 8760 hours in a year (24 * 365), it enters EDF fairly often (I normally run 4 projects on that machine). It goes into EDF, runs off the other projects (since their deadlines are first), then runs CPDN for several days until it decides it is out of danger. Then, it downloads something else and runs it pretty much exclusively (CPDN has run up a lot of debt by this time) then it goes into EDF again. In a wierd sort of way, it's neat to watch.

Having said all that, if the estimates were better, the problem wouldn't be quite as bad, but CPDN is starting to look like a project that isn't good for these "slow" computers unless you want to it exclusively.


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.