Dena,

If your cache is set permanently to over 4 days cache, the client should eventually stop receiving these 'repair' jobs. The rule is that if a device does report work frequently over 2 days, the client is taken out of the highly reliable group... but it takes some days of WCG work reporting... it's not like the first few results coming in late.

Someone wrote somewhere else that on Sunday he stopped all project work fetches, increased the cache size from normal to a number to be able to bridge the outage and then allowed Seti only to backfill. After he sets the cache back to low and allows all projects to fetch work again. The scheduler then takes care for the short deadline jobs to be completed in time... the cache is effectively being emptied first before work fetch resumes.

The good part is the debt system will balance things out, so after the rushing and cache emptying has ended, your other other projects will return to get more time to compensate, but that works over multiple days, a week sometimes and with this Seti scheme it will be a permanent disarray of days where no work of them is done.

Thanks for continuing to contribute to WCG.

edit: think Seti goes completely off-line, so advise to flip on the scheduled connecting function and set it to for instance 1 hour a day so other projects can report that what is done... from 23:00 to 24:00 UTC. In the client you can set the network schedule for each day, then activate the Network based on preferences. I'm sure over at the alien seekers forum someone will have written up a workaround for their problem that's effecting the whole grid community.

Well all hello broke loose last night. As I have been returning work units I have been issued mostly repair units to refill my queue. This locked out normal processing for WCG and the long term work units have aged to the point that they are now classed as high priority work units. I now have both cores processing WCG in high priority and none working on SETI work units.
I could abort some work units to clean this mess up now, but I am not going to do that to my wingman. What I am doing instead is setting No New Task on WCG so I don't get any more repair units and see if I can flush the WCG work units through normal processing. I like to run set and forget because I have other things to do with my time, but till this problem is corrected I will need to spend more time than I want to spend hand feeding WCG.
It is a big mistake issuing repair units with short times on them because they will often force high priority mode. High priority was intended to allow the client to clean up problems on it's end. What the short dead line is doing is forcing high priority mode to clean up records you don't want hanging around on the server. This causes problems on the client because it takes away some if it's ability to manage work leading to the problem I now face.
I question how well the debit balancing works under some conditions. I know of three ways it might not work as one might expect and I am exposed to all of them.
1. I run a resource share of 100%/100% for SETI and WCG. The idea being if a project lacks work, I am not to worried about payback. This has worked out well for WCG as SETI has a good deal of down time One was around three weeks when they had a server outage without a fall back system or the money on hand to replace it. They run on a shoe string budget and outages due to hardware failure are not uncommon.
2. If not running 100%/100%, I suspect share is not applied if a project runs out of work. I consider this a fair decision because some projects may go months without work so share should only be applied when work is available for the project.
3. I turn my system off about 8 hours a day and I am unsure if the share information is retained through a power off cycle.
As for playing around with when you get work for SETI, you don't do that. With SETI you get work when you can because the pipe is blocked to the point where you get a download window when you can find one. Here is a link to show you why you don't control SETI downloads. Link to Cricket
From what I gather, some SETI crunchers do crunch WCG work units but often they only crunch SETI and run a 10 day queue to avoid work shortages. I try to spread the word that WCG always has work units so they will never run dry but many would rather complain about the lack of work units instead of joining a useful second project. Go figure.

P.S. I have been running a 4 day queue for several weeks now and SETI has a 4.4 day turn around time. I would assume that WCG has about the same turn around time by now and I am still getting repair units. I don't mind the idea of repair units as long as I can process them like normal units.

Dena,

As you found, the receipt of repair jobs perpetuates that opinion at WCG that your client is still reliable. There's dirty ways to be knocked out such as grabbing a bunch of work and then suspending them for over 4 days and then complete them, but maybe a mail to the support team will allow them to flip a switch.

I think Seti is down for 3 days and then there's 4 days of competition to upload. To me there's some design with intend in what they're doing there more than meets the eye. They know people will be hoarding work so the caching will only cause more of the panic state conditions, Seti getting the prime attention. Not true of course, but if it were, real bad BOINC citizenship ;>)

And yes share information is a part of actual computed time, be it an hour a day or all day. Part time crunching will make the balancing to take longer to equilibrate though.

4.4 days deadline is very hmmm with their pipe problems i.e. they try squeezing 7 days production into 4 days network availability, but guess they're tremendously short on storage resources too so they have to off-load also at much higher pace.

Frankly, I think you're better off to schedule 15 days WCG and then 15 days Seti. Much less of a race. At the end of the month each have their equal share without constant competition.

Would that work for you?

There's no problem with retaining the info even if you shut-down for 8 hours/day, BOINC-client also knows you does shut-down for 8 hours/day and adjust how much work it should get to keep your cache-size full.

As for how resource-share is balanced, short-term it's not, but long-term it should be more or less trying to follow your settings. But of course, a 0.1%-share or something will generally always get too much work, while a project like LHC@home that can take many months between work will never manage to reach even a low share like 25% or something...


It's always been like this, even SETI@home expressely advices users to join other projects, still 80% - 90% is only attached to SETI@home. Going by http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php roughly 5.5% of SETI-computers also runs WCG, with the most popular project alongside SETI being Einstein@home at 11.3%.

On the flip-side, 7.3% of WCG-computers also runs SETI@home.


WCG doesn't display this kind of info, but lots of WCG-work in HP doesn't neccessarily mean it's a high turnaround...

In any case, as mentioned in my other post, setting "Connected..." > 4.01 days should stop you getting the repair-WCG-work.