I think that's the version number that the scheduler reports, not the server version number. The scheduler of version 1.0.4 hasn't had many changes in the past 2-12 years. See https://github.com/BOINC/boinc/tree/server_release/1.0/1.0.4/sched

Or look at https://github.com/BOINC/boinc/blob/server_release/1.0/1.0.4/version.h.

That's where the scheduler picks up the 713 from

#define BOINC_MAJOR_VERSION 7
#define BOINC_MINOR_VERSION 13

Yup. MilkyWay confirms my suspicions - it's a generic bug in BOINC, or at least a 'design flaw': the sort of thing that has to be picked up by thinking, not by automated syntax checkers.

I ran the test machine down to empty - no tasks remaining. Then allowed MilkyWay to ask for work.

14/01/2021 19:30:21 |  | [work_fetch] Request work fetch: project work fetch resumed by user
14/01/2021 19:30:22 |  | [work_fetch] target work buffer: 8640.00 + 864.00 sec
14/01/2021 19:30:22 |  | [work_fetch] shortfall 38016.00 nidle 4.00 saturated 0.00 busy 0.00
14/01/2021 19:30:22 | Milkyway@Home | [sched_op] CPU work request: 38016.00 seconds; 4.00 devices
14/01/2021 19:30:24 | Milkyway@Home | Scheduler request completed: got 23 new tasks
14/01/2021 19:30:24 | Milkyway@Home | [sched_op] estimated total CPU task duration: 39233 seconds

So I got what I was asking for - or did I?

My request was for 9,504 wall-seconds, or fullCPU-seconds. On a quad core with four idle cores, that translated into 38,016 core-seconds. But the tasks I received were MT, using all four cores. So I got 39,233 fullCPU-seconds. 10.6 hours of work, not the 2.64 hours target. A four-fold over supply.

BUG: The server estimates the duration at
https://github.com/BOINC/boinc/blob/master/sched/sched_send.cpp#L429 (estimate_duration_unscaled) and
https://github.com/BOINC/boinc/blob/master/sched/sched_send.cpp#L477 (estimate_duration)

The comment says

// estimate the amount of real time to complete this WU,
// taking into account active_frac etc.
// Note: don't factor in resource_share_fraction.
// The core client doesn't necessarily round-robin across all projects.

but it's not true: there's no 'ncpus' term in either calculation. That comment was written in the days of single-core CPUs, and the answer is in core-seconds. For MT tasks, that's wrong by a factor of ncpus. The more cores your CPU has, the more wrong it is.

You mean I was right?!?

It took some time to turn your general remarks in message 101928 into a reportable bug report - the question 'why?' is important when considering reports like that.

But yes, you were right ;-)