Another scheduler instance is running for this host - - - ? ? ?

It's not the scheduler that's "lost its mind" - it's your BOINC client :-).  The scheduler may have many other quirks but it doesn't have any impact on what your client thinks its cache of tasks will need time-wise.

Let me hazard a guess.  The DCF jump from 0.85 to 7.40 is a factor of 8.7.  It might have been caused by a single task taking 8.7 times as long as its estimate suggested it should.  There are many possible reasons for that and I don't know which host has the problem but I'd be looking to find some task on that host that completed with an unusually long crunch time.

One possibility is that the 0.85 DCF was created by some fast finishing GRP tasks.  GRP tasks tend to create a DCF even significantly lower than that.  This would have lowered the estimate for GW tasks to well below what they actually take.  The 7.40 value could have been created by a single GW task (estimated far too low) that took rather longer than normal.  I see DCFs of around 4 or so for my GW tasks.  There are the occasional slow tasks that could take it to above 7.

There are two ways to handle the inaccurate task estimates for GW as compared to GRP.  Either, don't run both GPU searches on the one machine, or, keep the cache size to less than 0.5 days.  You would think that a 1 day cache would be safe but according to your figures, you had rather more than that at the time the DCF jumped by 8.7 times.  To have 25 days of CPU work after the jump, you must have had close to 3 days worth before the jump.  For the GPU tasks, the corresponding figure would have been around 1.5 days.  Those sort of figures are quite believable - the actual work on hand does often stray a bit above what the cache setting says.

All the above is pure conjecture on my part.  If something else other than a very slow finishing task causing the sudden jump in DCF turns out to be the true reason, it would be very interesting to know the details.

That's an impossible wish as there isn't "something modern" to update to :-).  In any case, that wouldn't solve the problem. As I've said, the real issue is that the two GPU searches have very inaccurate estimates in the opposite directions to each other.  If they were both inaccurate in the same direction, the single DCF could probably cope.

Because Locality Scheduling is vital in allowing both volunteers and project servers to cope with the volume of data downloads, the highly customised server code here is probably destined to stay that way.  When the GW app matures, it's possible the estimate for those tasks might get a lot better.  One can always hope.

Go back and read what was actually written.  I'm quite sure you had a 1 day setting.  I said that quite often that setting can turn into more than that amount of actual work.  The normal DCF swings can easily do that.

None of that is relevant to the discussion here.  What other projects do or don't do has no bearing on how the Einstein scheduler handles its work requests.  The scheduler doesn't "tell the client" - it's the other way around.  The client tells the server 'seconds of work' (for both CPU and GPU if necessary) and the value of DCF when it makes a request.  The server uses that information to work out what to send to meet the request.  The server doesn't know if the DCF value given is good, bad, or indifferent.  It just uses what it is given.

How is that relevant?  Because of the need for Locality Scheduling, Einstein has chosen to use its own highly customised version of the BOINC server code.  That code was originally based on some much earlier BOINC standard version but has been significantly (and continually) modified over the years to meet Einstein requirements.  I can remember a very clear statement many years ago that it was a much more onerous task to try to keep up with BOINC versions as they rolled out than it was to stay with their own customised version.  The reason given was that each new BOINC version would require an horrendous number of patches to adapt it to what they needed.  Essentially, they chose to have their own unique version - which included DCF.  We, the volunteers, either work out how to live with that or we choose to move on.  That's a bit brutal but it's just the way it is.

The fact that you got to start this thread at all is probably a testament to the latest update to the Einstein server code that (at least temporarily) had some sort of a bug in it.  How much more "modern" than that can you get :-).

Keith, I need to be gone so I'll have to fully answer tomorrow if you wish.

In the meantime, how do you explain the following.  I just went to the BOINC directory on the closest host of mine and issued the following commands.  What was returned is shown immediately following each command.

[gary@ryzen-01 BOINC]$ grep duration_correction sched_request_einstein.phys.uwm.edu.xml
    <duration_correction_factor>3.108055</duration_correction_factor>
[gary@ryzen-01 BOINC]$

 

[gary@ryzen-01 BOINC]$ grep duration_correction sched_reply_einstein.phys.uwm.edu.xml
[gary@ryzen-01 BOINC]$

So, for Einstein, who is telling who exactly what the duration correction factor actually is?  It's sent in the request and not received in the reply.

When you first attach to the Einstein project, your state file (in the brand new Einstein Project section) will contain a default value of 1.000000 for DCF.  If the very first Einstein task completed takes twice as long as its estimate, you can watch the client adjust all the other tasks on the tasks tab of BOINC Manager to have (immediately and without server consultation) a corrected estimate that will be exactly (for this artificial example) double the previous estimate.  If you looked in the state file, you would see the change to 2.000000 there as well.

If your very first task took exactly half as long as the estimate, the DCF would be reduced below 1.000000 by 10% of the error in the estimate.  If this pattern of half the original estimate was repeated over time, the DCF would converge progressively on 0.500000.  It's done that way to prevent over-fetching if a single task only had a 'once-off' fast finishing time.

For either example, when your client makes its next scheduler request, it will always report to the scheduler the current value in the state file that it has control over.  You also have control over this.  If you stop BOINC and edit the value in your state file, the client (without question) will immediately read the new value on restart and believe it.  I have done this many times to correct damaged values.  I'm certainly not recommending that as a standard course of action.

It doesn't matter what other projects do.  We are discussing Einstein behaviour.