I've been told there's a problem with the DCF swinging back and forth, any idea when this will be fixed and what about the insane back offs? I'm using 6.10.58 x64 on Windows 7 x64 for the moment, no I'm not about to run 6.13.xx as I've read the warning and 6.12.xx doesn't enthuse Me much either, If there was a version that acted like 6.10.58 on uploads and downloads, ok, but until then, No way Jose. I'm running 3 GTX295 cards in one PC, eventually though I'll have the water version up that will have 6 water cooled GTX295 cards installed. I'm also running the latest BoincTasks 1.29 x64 as the manager.

---

Play MULE, 42 is irrelevant

I've been told there's a problem with the DCF swinging back and forth, any idea when this will be fixed

It can't be fixed, unless application specific DCFs are introduced, which requires a whole new client and back-end that supports that. Until that time, one DCF for all.

and what about the insane back offs?

Changeset [trac]changeset:24775[/trac]: client: tweak parameters of file xfer backoff to reduce backoff intervals somewhat.

---

I've been told there's a problem with the DCF swinging back and forth, any idea when this will be fixed

It can't be fixed, unless application specific DCFs are introduced, which requires a whole new client and back-end that supports that. Until that time, one DCF for all.

Well, not quite. I think the questioner is referring to a specific set of circumstances, which you may not be following.

Under the "runtime estimates" code changes associated with CreditNew, DCF is effectively redundant. Instead, averages are maintained on the server - not only per application, but even per application_version. The net figure accessible to users is the APR or Average Processing Rate - when this is being properly managed by project servers, client DCF remains close to 1.0000, even for a mix of applications and devices (CPUs and GPUs). It actually works, and has worked at SETI for about 15 months.

Unfortunately, a well-meaning but flawed attempt to cope with problems caused by anomalous results (which confuse the averaging system) led to DA himself applying a code patch which broke the APR mechanism at SETI. That was in early September: the project is still suffering the after-effects. It's well known what needs to be done to rectify matters, but unfortunately a straight reversal of the code patch will cause as many problems as the patch did in the first place. It has to be a carefully graduated sequence of changes: neither David, nor the over-stretched SETI staff, have found time amongst their other fire-fighting duties to put them into effect.

I've been told there's a problem with the DCF swinging back and forth, any idea when this will be fixed

It can't be fixed, unless application specific DCFs are introduced, which requires a whole new client and back-end that supports that. Until that time, one DCF for all.

and what about the insane back offs?

Changeset [trac]changeset:24775[/trac]: client: tweak parameters of file xfer backoff to reduce backoff intervals somewhat.

Well what I meant by the DCF is when It swing back and forth like a clocks pendulum and fairly wildly at that. I was reading that someone had changed the dcf and introduced the problem, I was told the DCF was a Seti problem, then a Boinc problem and that It was the cause of peoples Racs going down when their offline for a few hours a day, I don't crunch during the day as the house would heat up too much(no a/c), 12 hours at most right now, I could go offline with 11,025 and come back online to 10,625 or so, shouldn't It be building and not struggling to maintain itself? On Einstein My rac grows, even after being offline for more than 12 hours, If I'm consistent at doing work there on My 6 gpus, yet on Seti the performance is weak and faltering and yet I use x38g, I tried x41g and It was worse and It wasn't always this way.

On the backoffs, sounds like something for v7 I gather.

---

Play MULE, 42 is irrelevant

I've been told there's a problem with the DCF swinging back and forth, any idea when this will be fixed

It can't be fixed, unless application specific DCFs are introduced, which requires a whole new client and back-end that supports that. Until that time, one DCF for all.

Well, not quite. I think the questioner is referring to a specific set of circumstances, which you may not be following.

Under the "runtime estimates" code changes associated with CreditNew, DCF is effectively redundant. Instead, averages are maintained on the server - not only per application, but even per application_version. The net figure accessible to users is the APR or Average Processing Rate - when this is being properly managed by project servers, client DCF remains close to 1.0000, even for a mix of applications and devices (CPUs and GPUs). It actually works, and has worked at SETI for about 15 months.

Unfortunately, a well-meaning but flawed attempt to cope with problems caused by anomalous results (which confuse the averaging system) led to DA himself applying a code patch which broke the APR mechanism at SETI. That was in early September: the project is still suffering the after-effects. It's well known what needs to be done to rectify matters, but unfortunately a straight reversal of the code patch will cause as many problems as the patch did in the first place. It has to be a carefully graduated sequence of changes: neither David, nor the over-stretched SETI staff, have found time amongst their other fire-fighting duties to put them into effect.

Thanks Richard, until the people who can fix the patch problem can apply a NEU patch(pun intended), I'll try and get the spad to limp along, no matter how crazy It drives Me.

---

Play MULE, 42 is irrelevant