Thought to have seen that 3 days was the new norm from before 4 days... seen this on FA@H and CEP2. If the torque was further reduced to 20% of original deadline for first repair, it can mean 3 things [or more]:

1) Silent tweak [techs are good at that], and a disk space issue is playing up, or a general performance [though not noticed anything from instant validating view and work fetch].
2) A bug.
3) Something cooking in Mobile v.v. the Invalid issue [more silence]. Maybe the automaton goes into high gear when a certain [fail] percent is exceeded.

Neither bothers me, but on the v7 client it does mean that if you have a cache setting on MinB [Minimum work Buffer] that is greater than half of the [shortest] deadline, these 2 day deadline tasks are jumped to the front, and THAT I'm not adverse to either. It allows for quicker migration of quorum complete results to the master database and move them off the live Result Status [The more there are live, the harder the pivotal Scheduler has to work].

P.S. Just checked that latest MCM and FAAH still have 10 day deadline for originals.

edit: added the Invalid angle.

edit2: Just has a first repair on a CEP2 task, also 2 day deadline, and jumping to top of queue i.e. it looks like a general move of 20% of original _0 deadline [think the definition cannot be varied per science app]

Ok. Thanks, Rob.
Now, the first 2 WUs with 2-day deadline are running with high priority. Hoping all of them are crunched up before to dead line time...

The amount of guessing we do is near infinite, but looking at the MCM batch numbers, maybe those are re-issues of tasks that never managed to get a complete quorum e.g. those ending up in a too-late state for all completed copies. It's all about getting 2 to come together without a restart on this science... At the same time received 0000338 with 10 days. Looking through the history, it's the highest batch I've seen yet on this project.

Two days is too short. It is arrogance thinking that I run WCG and only WCG on my computers. When deadlines become too short I turn off the spigot to drain and let other projects run. This results in less crunching on the project over all.

...I am sorely tempted to just let the WUs time out in protest.

The choice of 2 days has several nasty effects in the v7 client I don't like [that's me], BUT, must say, my Pending tasks dropped by 40% in the last 48 hours [who does not love that?]. Also, those 2 day deadline tasks have a very great certainty to have immediate validation, so I don't mind doing them.. instant credit [more love :D]. Eventually WCG will be torqued off when it had it's time share overrun, and remember [or be aware], that with the v7 client, there's block processing of a project... no attempt to balance on an hourly basis. Much more efficient for all the projects task scheduling [less unfinished tasks sitting in 'waiting to run']. Do agree, if tasks time out, they time out, no hard feelings. If tasks get started before the deadline, completed after deadline leading to a redundant copy [because the server had no chance to give an abort instruction prior to start], not likeable, but that happens in such a very small fraction of a percent that it is acceptable [to me]...

Clearly the 2 day push was due active tasks clogging the scheduler on MCM [can't specify per-science], and it being just a temp measure [Oh wish techs would explain that in a 30 second post so we can avoid these discussions]. Run a buffer that is no bigger than half of the shortest deadline of any project that's active on a client [so that is 1 day for a 2 day deadline] and you rarely miss one. BOINC learns... if part time crunching, it will only fetch part-time work... still meets deadline.

There's one moan. My 7.2.3x clients on Linux seems to run near double the amount of cached work than set [the TTCs]. I've got it set on MinB of 1 day and MaxAB of 0.00, but somehow continuously get work assigned that totals double that. With DCF fixed to 1.0 for the v7 clients, not quite understanding what's up with that. My suspicion is the FAHV/VINA running in half the time of what Windows takes, and just getting 'wrong' [Windows] FLOPS in the task headers. Given there's only a single work pool, probably not possible to fix that according platform performance. The second is CEP2. We all know they run 12 hours, yet without exception they arrive with near 24 hour TTC [due frozen DCF]. This has led to idling cores since 8 CEP2 buffered on an octo [per profile], but only 4 allowed to run concurrent [per app_config], made the client think it had enough work to cover all 8 cores... 'don't need' the log says. Thumbs down on that token. We need a solution in BOINC so fixed/max hours tasks are projected with fixed/max hours [and it's not the first time this is being brought up]. Less Triple Emming [MicroManagementMethods].

Now I have my second caffe lungo.