Can you run two rounds with <work_fetch_debug>1</work_fetch_debug> in the <log_flags> section of the cc_config.xml file and post its output, please?

Round 1:
<snipping some startup stuff>
30-May-2010 18:58:56 [SETI@home] General prefs: from SETI@home (last modified 28-May-2010 15:52:20)
30-May-2010 18:58:56 [SETI@home] Computer location: school
30-May-2010 18:58:56 [---] General prefs: using separate prefs for school
30-May-2010 18:58:56 [---] Preferences:
30-May-2010 18:58:56 [---] max memory usage when active: 2030.42MB
30-May-2010 18:58:56 [---] max memory usage when idle: 2030.42MB
30-May-2010 18:58:56 [---] max disk usage: 29.81GB
30-May-2010 18:58:56 [---] don't use GPU while active
30-May-2010 18:58:56 [---] (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
30-May-2010 18:58:56 [---] [wfd] Request work fetch: Prefs update
30-May-2010 18:58:56 [---] [wfd] Request work fetch: Startup
30-May-2010 18:58:56 [---] Not using a proxy
Initialization completed
30-May-2010 18:58:56 [---] [wfd] Request work fetch: Backoff ended for SETI@home
30-May-2010 18:58:56 [Einstein@Home] Restarting task p2030_54022_82328_0104_G58.97+02.54.C_3.dm_500_1 using einsteinbinary_ABP2 version 308
30-May-2010 18:58:56 [Einstein@Home] Restarting task p2030_54022_82328_0104_G58.97+02.54.C_3.dm_488_0 using einsteinbinary_ABP2 version 308
30-May-2010 18:58:56 [---] [wfd]: work fetch start
30-May-2010 18:58:56 [---] [wfd] ------- start work fetch state -------
30-May-2010 18:58:56 [---] [wfd] target work buffer: 259.20 + 363484.80 sec
30-May-2010 18:58:56 [---] [wfd] CPU: shortfall 0.00 nidle 0.00 saturated 366515.22 busy 0.00 RS fetchable 0.00 runnable 96.00
30-May-2010 18:58:56 [Einstein@Home] [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (comm deferred)
30-May-2010 18:58:56 [SETI@home] [wfd] CPU: fetch share 1.00 LTD -1115.32 backoff dt 0.00 int 0.00
30-May-2010 18:58:56 [Einstein@Home] [wfd] overall LTD -366905.85
30-May-2010 18:58:56 [SETI@home] [wfd] overall LTD -1115.32
30-May-2010 18:58:56 [---] [wfd] ------- end work fetch state -------
30-May-2010 18:58:56 [---] [wfd] No project chosen for work fetch
30-May-2010 18:59:51 [---] Exit requested by user

Round 2

<same snipping>
30-May-2010 19:00:00 [---] General prefs: using separate prefs for school
30-May-2010 19:00:00 [---] Preferences:
30-May-2010 19:00:00 [---] max memory usage when active: 2030.42MB
30-May-2010 19:00:00 [---] max memory usage when idle: 2030.42MB
30-May-2010 19:00:00 [---] max disk usage: 29.81GB
30-May-2010 19:00:00 [---] don't use GPU while active
30-May-2010 19:00:00 [---] (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
30-May-2010 19:00:00 [---] [wfd] Request work fetch: Prefs update
30-May-2010 19:00:00 [---] [wfd] Request work fetch: Startup
30-May-2010 19:00:00 [---] Not using a proxy
Initialization completed
30-May-2010 19:00:00 [---] [wfd] Request work fetch: Backoff ended for SETI@home
30-May-2010 19:00:00 [Einstein@Home] Restarting task p2030_54022_82328_0104_G58.97+02.54.C_3.dm_500_1 using einsteinbinary_ABP2 version 308
30-May-2010 19:00:00 [Einstein@Home] Restarting task p2030_54022_82328_0104_G58.97+02.54.C_3.dm_488_0 using einsteinbinary_ABP2 version 308
30-May-2010 19:00:00 [---] [wfd]: work fetch start
30-May-2010 19:00:00 [---] [wfd] ------- start work fetch state -------
30-May-2010 19:00:00 [---] [wfd] target work buffer: 259.20 + 363484.80 sec
30-May-2010 19:00:00 [---] [wfd] CPU: shortfall 0.00 nidle 0.00 saturated 366396.79 busy 0.00 RS fetchable 0.00 runnable 96.00
30-May-2010 19:00:00 [Einstein@Home] [wfd] CPU: fetch share 0.00 LTD 0.00 backoff dt 0.00 int 0.00 (comm deferred)
30-May-2010 19:00:00 [SETI@home] [wfd] CPU: fetch share 1.00 LTD -1115.32 backoff dt 0.00 int 0.00
30-May-2010 19:00:00 [Einstein@Home] [wfd] overall LTD -366800.05
30-May-2010 19:00:00 [SETI@home] [wfd] overall LTD -1115.32
30-May-2010 19:00:00 [---] [wfd] ------- end work fetch state -------
30-May-2010 19:00:00 [---] [wfd] No project chosen for work fetch
30-May-2010 19:00:38 [---] Exit requested by user

I don't see anywhere that BOINC thinks it's going to miss any deadlines.
So it's probably not going to.

The host with deadlines coming up first was one of the quads. That deadline is noon June 2. Until this morning that work slumbered unprocessed while days of work later in FIFO order by any definition of FIFO I can think of was processed.

As of now it has changed selection behavior, and all four currently executing units are work with June 2 deadlines--had it continued previous behavior it would instead most likely be processing work with deadlines in the June 3 through June 9 range. Two of the four currently executing tasks are labeled "Running, deadline warning" in the status field as represented by BoincTasks 0.58. BOINCView, however, represents the status as simply "running". Boinc Manager directly on the host also simply reports "running" I have not spotted this "deadline warning" status before, but as I recently have mostly used BOINCView for my monitoring, it is possible I missed some cases. As I've changed BT versions, it is possible "deadline warning" and "High Priority" are the same thing.

While the order of task selection within queue remains whimsical, not FIFO, it remains the case that the selection is within the set of tasks already downloaded before the host changed from BOINC 5 to 6.

I'll report again after the fact, but for the moment I think this task selection ordering is likely to turn out to be well described this way:

1. Boinc6 selects tasks for execution within work downloaded under boinc5 in a whimsical order.

2. While the order is whimsical compared to FIFO or just customary behavior, it is taken into account by the means used to judge whether High Priority or other than standard processing is needed.

3. As a result, if the whimsical order left unchanged is estimated to give excess deadline miss risk, a previously healthy system may enter High Priority immediately on conversion from 5 to 6, and may stay that way for quite some time.

4. Happily, both the High Priority and "deadline warning" conditions (if they are distinct) make non-whimsical (soonest deadline) choices when active. So under ordinary steady-state use conditions of consistent material, any actual deadline risk from 5 to 6 conversions seems likely to be low.

5. Work downloaded under boinc5 will generally be finished before new work downloaded under 6 starts. At that boundary, the effects discussed in this note will largely be past.

Possibly it is relying on information written by version 5 for which the interpretation has changed in version 6.

That would be the way that short term debt and long term debt is calculated.
For BOINC 5 both STD and LTD had zero as their mean number.

I have a candidate. Happily my system backup has been running lately, and happily client_state.xml is stored is a different place on version 6 than on version 5. So I was able to look directly at a comparison of the portions relating to a particular task (or result in official BOINC-speak). The <result> section contains two differences--added tags in v6.

Here is the result section for a task downloaded under v5 but still undone today, as it was in the v5 Client_state.xml.

<result>
<name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0</name>
<final_cpu_time>0.000000</final_cpu_time>
<exit_status>0</exit_status>
<state>2</state>
<platform>windows_intelx86</platform>
<version_num>308</version_num>
<wu_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216</wu_name>
<report_deadline>1275533654.000000</report_deadline>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_0</file_name>
<open_name>results.cand0</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_1</file_name>
<open_name>results.cand1</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_2</file_name>
<open_name>results.cand2</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_3</file_name>
<open_name>results.cand3</open_name>
</file_ref>
</result>

And here as it now is under v6. The two differences are additions. I've colored them red.
<result>
<name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0</name>
<final_cpu_time>0.000000</final_cpu_time>
<final_elapsed_time>0.000000</final_elapsed_time>
<exit_status>0</exit_status>
<state>2</state>
<platform>windows_intelx86</platform>
<version_num>308</version_num>
<wu_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216</wu_name>
<report_deadline>1275533654.000000</report_deadline>
<received_time>0.000000</received_time>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_0</file_name>
<open_name>results.cand0</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_1</file_name>
<open_name>results.cand1</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_2</file_name>
<open_name>results.cand2</open_name>
</file_ref>
<file_ref>
<file_name>p2030_53986_07137_0063_G68.22-01.47.C_5.dm_216_0_3</file_name>
<open_name>results.cand3</open_name>
</file_ref>
</result>[/code]

For comparison, here is the result section for a task downloaded under v6. I've highlighted the same sections.

<result>
<name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544_0</name>
<final_cpu_time>0.000000</final_cpu_time>
<final_elapsed_time>0.000000</final_elapsed_time>
<exit_status>0</exit_status>
<state>2</state>
<platform>windows_intelx86</platform>
<version_num>308</version_num>
<wu_name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544</wu_name>
<report_deadline>1276395124.000000</report_deadline>
<received_time>1275185511.066874</received_time>
<file_ref>
<file_name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544_0_0</file_name>
<open_name>results.cand0</open_name>
</file_ref>
<file_ref>
<file_name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544_0_1</file_name>
<open_name>results.cand1</open_name>
</file_ref>
<file_ref>
<file_name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544_0_2</file_name>
<open_name>results.cand2</open_name>
</file_ref>
<file_ref>
<file_name>p2030_54067_74228_0193_G65.55-01.90.C_4.dm_544_0_3</file_name>
<open_name>results.cand3</open_name>
</file_ref>
</result>

Obviously v5 did not store <received_time> in this section. Under v5 to v6 conversion it appears that the tag is created (for compatibility) but population with the value 0.0 (giving imperfect compatibility).

If, as seems to me likely, the v6 scheduler currently gives high priority to this received_time value, then the whimsical behavior I have reported has an attributable basis, and good reason to terminate as soon as v5 downloaded work is finished.