Boinc and DCF with GPU tasks

Holmis has addressed the project side. For you or others who might come across this, let me comment on the user side:

Consider low queue length, and consider restricting application types.

1. As Einstein has usually had pretty reliable work supply, reasons extended for deliberately requesting large amounts of work in advance which were applicable at SETI when they routinely shut down work distribution for several days a week, or had frequent unscheduled multi-day outages don't apply so strongly here. If you have something like a half day of requested pre-fetched work, the variations are much less likely to cause deadline misses, "panic mode" operation, and other undesired effects. As little as a sixth of a day is probably enough for most purposes.

2. Personally, I at any given time select a single flavor of CPU work and another single flavor of GPU work. Over a few weeks this usually settles to pretty accurate run time estimates for both flavors.

One place is the Boinc Manager, you open it then click on the projects tab, then your project, then properties on the left and scroll to the bottom of the page. In C:\programdata\boinc is a file called "client_state.xml", as you scroll thru it you will see a line like this:
1.000000

for each project. BE CAREFUL if you change the numbers though, it can be a HUGE mess if you set it wrong. The ideal setting is 1.0 so both of my above numbers are good enough.

But this one:
0.488683

is a little low. While this one:
3.018424

is a bit high. On both of the last two I would change the first number, before the decimal point to a ONE and then save the file and restart Boinc.

Apparently you can also just reset the project to set it back to the default settings. I think you will lose any workunits for that project though, both in progress and cached ones.

BRP5 tasks take around 3.3 times longer than BRP4G tasks and are awarded 3.3 times more credit. The difference in run time and the fact that both task types cause BOINC to make adjustments to the (single) DCF is not an issue you should be concerned about. Nor is the actual value of the DCF itself. It really doesn't matter if the DCF is 0.5 or 1.0 or even 5.0, if that is what it really needs to be.

In a perfect world, if the project supplied estimate is precisely the same as the actual crunch time, the DCF will be 1.0 and all will be happy.

In an imperfect world, the project supplied estimate might be twice (or half) the true run time and BOINC will adapt to this by progressively adjusting the DCF until it reaches 0.5 (or 2.0), at which point all will be happy again.

A real problem only arises when there are multiple searches at the one project where the different estimates disagree with the actuals in vastly different amounts, perhaps even in opposing directions.

For example, if BRP4G tasks took an hour and were estimated at 2 hours, and if BRP5 tasks took 3.5 hours and were estimated at 7 hours (ie estimates are both double the actuals), BOINC would fix this itself by reducing the DCF to 0.5, at which point, new tasks of either type would arrive with correct estimates.

However, if BRP4G took an hour but were estimated at 0.5 hours, whilst BRP5 took 3.5 hours and were estimated at 7, this would create a big problem. Each completed BRP4G task under this regime, would cause BOINC to push up the DCF towards 2.0 since they really take double the estimate. Each completed BRP5 task would still be causing BOINC to try to reduce the DCF towards 0.5. The DCF is likely to bounce around quite a lot depending on the numbers of different task types crunched.

So it doesn't really matter if estimates are inaccurate as long as the different searches have similar inaccuracies to each other in both magnitude and direction.

To be sure about what is happening, you should publish the estimates for each task type when you receive a new batch of work containing both types. Then we can see exactly the disparity between estimate and actual for both at a time when DCF is constant. You can't really tell by looking at different work fetch events because the DCF may have changed in the interim.

I haven't done any BRP4G for a very long time but my impression when I last did was that the ratio between estimate and actual was pretty much the same for both searches. However it could be quite different on different hosts with different types of CPUs and GPUs.

Another factor to consider is the number of concurrent GPU tasks that you are running. Do you run multiple concurrent tasks and is the concurrency factor different for the two searches?

For example, assume BRP4G tasks are estimated at 1 hour and take 1 hour when done singly. The DCF would be 1.0. You decide to run these 3x and you find that 3 tasks are now completed in 2 hours. Effectively you are completing a task every 40 mins but BOINC sees 2 hours. I don't know for sure how BOINC handles this but what seems to happen is that the DCF blows out to 2.0 and new tasks arrive with estimates that increase immediately to 2 hours. With a single DCF this could be a problem for other searches. All my GPU hosts run both CPU and concurrent GPU tasks. Running multiple GPU tasks causes the estimate for CPU tasks to blow out considerably due to this effect.

Happily for me, I like seeing the CPU tasks with estimates that are twice or three times what they actually take. I have a number of quad core hosts with AMD GPUs running tasks 4x. This means that 2 CPU cores are crunching and 2 are reserved for GPU support. BOINC still does work fetch based on 4 CPU cores but because the estimates are 2 to 3 times too large, I always end up with about the right amount of CPU work on each host anyway.

Cliff,

When you said it crashed...did it lock up or did it reboot? I noticed you are using AMD 8350 chip. I used to run that same chip as well. Only upgrade my machine a few weeks back due to issues of continued reboots or lock ups requiring forced reboots.

I know Mike loves the 8350 that he has but what I've learned from others who also have them is that you can't stress that chip like you can other AMD chips.

In a nutshell, you have 8 cores but only 4 floating points so if you try to stress that chip you have 2 cores fighting over that 1 floating point. Causes the computer to either reboot or freeze.

I ended up only using the Chip to support the GPUs and they did fine.

Just thought I'd mention this in case you continue to have problems.

Happy Crunching...

Zalster

One thing you could do is to limit Einstein to running either the BRP4 OR the BRP5 tasks, that way your DCF will stabilize, you only worry about the DCF PER project, as the Einstein DCF will NOT affect any other project.