Why deleting a work unit is bad

[Xilikon]

I know it's bad to delete a work unit in progress. However, I failed to see evidence about the reasons why it's bad... All I know that work units is created in a sequential fashion and deleting one will cause a delay for the next ones.

Is there are links from the PG commenting on them ?

[PantherX]

The problem arises when you dump the WU, there isn't any way for the Servers to know if you have dumped it or not. They wait for the Preferred Deadline then reassign. Now, for SMP2 WUs, the Preferred Deadline is short (3 to ~4) Days and the Bonus system encourages faster WU return and penalizes for dumping WU (>=80% Return rate). GPU WUs have a variable deadline and the Classic WUs have the longest. So the most severe impact of dumping the WUs will be on the Classic Client's research and the least on SMP2 WUs while the GPU2 WUs will be in-between them (of course, this is oversimplified and the actual picture comes from the Preferred Deadlines that each Project has).

Currently, there are plans to introduce the Bonus Points to the Classic Client which will discourage WU dumping. However, I am not aware of the details.

A quick search revels this:
{PG Member} DanEnsign -> viewtopic.php?p=10334#p10334
{Site Admin} bruce -> viewtopic.php?p=134170#p134170

Do note that I am against intentional dumping of any WUs. However, accidents can happen and it is "okay" as long as you learn from your mistakes and avoid repeating them.

[Punchy]

I disagree that the least severe impact is on SMP2. The shortest time impact is with SMP2, but then again SMP2 is much more time-critical. If the deadlines for each project are related to their time criticality, then the overall impact on each project is equally severe.

[Xilikon]

Anyone ?

[7im]

You need a comment from PG saying that dumping WUs is bad? One would think the obvious logic of reality would suffice. Dumping a WU slows things down while we wait for that WU to expire and get reassigned. It can result in a delay of several months in the larger CPU WUs.

But when logic escapes those few, point them at the 80% completion rate requirement of the QRB program. PG has added points incentives to NOT dump WUs, and that's the strongest message of all.

[Xilikon]

You need a comment from PG saying that dumping WUs is bad? One would think the obvious logic of reality would suffice. Dumping a WU slows things down while we wait for that WU to expire and get reassigned. It can result in a delay of several months in the larger CPU WUs.

But when logic escapes those few, point them at the 80% completion rate requirement of the QRB program. PG has added points incentives to NOT dump WUs, and that's the strongest message of all.

For me, the logic will suffice but for some people, if no statement from the PG is made about that officially, it mean it's not bad

Anyway, there will be one official statement soon

[VijayPande]

You need a comment from PG saying that dumping WUs is bad? One would think the obvious logic of reality would suffice. Dumping a WU slows things down while we wait for that WU to expire and get reassigned. It can result in a delay of several months in the larger CPU WUs.

But when logic escapes those few, point them at the 80% completion rate requirement of the QRB program. PG has added points incentives to NOT dump WUs, and that's the strongest message of all.

For me, the logic will suffice but for some people, if no statement from the PG is made about that officially, it mean it's not bad

Anyway, there will be one official statement soon

If one needs some official statement here, I am happy to make it. As mentioned above, dumping WUs means that the WU will sit, unproductive, until it times out. This slows down the science since we often need to wait for most RUN/CLONE combinations to get to a certain point. It is because dumping WUs are so bad that we have instated the QRB.

[theteofscuba]

if they had some extra cash to spend on development i'd suggest a way to cancel a work unit and notify the server (maybe even upload a partially completed wu) .. even though it isn't something that is needed often. i've had to abandon some wus in the past every now and then when configuring and reconfiguring f@h clients. but then again, it is not needed unless work units become somewhat scarce. and if the users are nice enough to tell it to cancel.

emphasis on "if they had some extra cash"

[bruce]

This feature has been requested before. Maybe it will be in v7, but we'll have to wait and see.

I'm not sure it would be as valuable as you think, though. If the WU is already about to expire, the server would treat the notification as an early notification of that expiration so the benefit would be small since the WU has already been delayed by some amount.

Also, if it's easy to dump WUs, some folks will use it for the wrong reasons. Along with such a feaure I'd recommend that the PG look hard at appropriate penalties for over-use of this feature. Judging only by my own performance, I feel the 80% bonus requirement is entirely too lax. I don't keep a systematic count, but I'll bet that less than 1% of the WUs assigned to me expire or would need to be dumped.

Of course there is a small percentage of my WUs which do have EUE errors. Of those, some are reported to the server and some are deleted by the client. I believe that the client should be smart enough to report all EUEs to the server. What I do not know is which count against the 80% bonus requirement and which do not and how that might change if there are more reports.

[jebo_4jc]

I agree that 80% sounds lax on its face, however I can also say I was thankful it WAS that lax just recently.

I tried to run smp (n - 1) on a dual xeon box recently. Might have been smp -15 on a dual nehalem system if I recall. The end result was approximately 150 instant EUEs over the course of a few hours while that box was unattended. I don't know what my exact WU completion percentage is, but I was glad it is high enough to withstand 150 simultaneous EUEs while staying above 80%.

[7im]

...

i've had to abandon some wus in the past every now and then when configuring and reconfiguring f@h clients.

Most times the client can simply be udpated, or copied and moved, and not touch the WU. Under what conditions does reconfiguring a fah client require you to abandon a WU?

[Grandpa_01]

I also agree that the 80% is too lax but there was one time when 80% was not enough due to a bad series of WU's that would EUE instantly and report back to the server, which took me below the 80% mark. Even with that happening I still think it should be raised to 90% or 95%. If anybody should have a problem with the 80% completion rate it should be me all 4 of my rigs run at 4.2+ GHz and I am continually playing with the OC on them which most of us know can cause stability problems and lost WU's. With that said I would venture to say my completion rate remains 99%+ so I would say that the majority of people who drop below 98% either have a bad OC bad hardware or are cherry picking. I have always believed that 80% was way too generous and that Stanford should take another look at it.

The smp and bigadv WU's are actually very stable although some say the 6701's are problematic which I do not believe. I will say they are slow worthless pieces of crap and it irritates me to fold them (Rant) and they do require a very stable OC, I still cannot say I have lost a single one that was not my fault, and there is really no ligament reason to delete one or any other WU, other than if the WU fails more than once at the same spot then it might be a bad WU. If a person believes they have a bad WU it should be reported to this forum.

[Qinsp]

...

i've had to abandon some wus in the past every now and then when configuring and reconfiguring f@h clients.

Most times the client can simply be udpated, or copied and moved, and not touch the WU. Under what conditions does reconfiguring a fah client require you to abandon a WU?

If you are running XP, and attempt to change the configuration, you can lose the job. Win7 seems to be stable. XP is broken. Any change can (and often is) lethal because the CONFIG code itself is bad. It's not the job, it's that you cannot restart the client without removing everything first. The only way I've been able to restart is by wiping out the whole install and reinstalling.

When the CONFIG crashes, it won't let you make anything but a blank config file, and that won't finish the job.

Yes, if there were detailed instructions on the work-arounds, you could save the job. But most the "fixes" posted on the forum do not work. It has nothing to do with renaming the executable, it crashes either way. It does not affect 100% of XP machines apparently, but on this one I'm typing from, it will crash 100% of the time like clockwork. Config == RIP WU.

[sswilson]

...

i've had to abandon some wus in the past every now and then when configuring and reconfiguring f@h clients.

Most times the client can simply be udpated, or copied and moved, and not touch the WU. Under what conditions does reconfiguring a fah client require you to abandon a WU?

It doesn't happen often, but hardware swaps (sometimes we forget to run a -oneunit, and need the hardware right away... ), OS reloads, and/or extended reworking of hardware setups (WC setup / cleaning can sometimes run longer than a day...).

I run 3 dedicated rigs (GPU + SMP2) 24/7, and do my best to complete all WUs accepted by my machines, but probably have 10 or so WUs over the space of a year which end up in the garbage bin for whatever reason. Having a (monitored to prevent abuse) -release switch or something similar would benefit the work timeline in those cases.

[bruce]

Nobody disputes that an occasional WU will be lost, but let's be realistic. What percentage of the WUs that you've been assigned were lost because of a hardware swap where you forgot to run -oneunit?

An allowable loss rate of 20% of the SMP WUs is HUGE compared to the number of WUs that are actually lost -- unless someone is intentionally cherrypicking.