Your machine has essentially entered into the old 'Earliest Deadline First' (EDF) mode. The client wont get work until nothing in the task-buffer is computed to go overdue per the BOINC scheduler.

I am getting this message as well on all 3 machines for the first time ever.

I have a 2.5 day cache and when I look at the report deadlines and the to completion times the jobs would be completed with 5 days + to spare.

All 3 machines are still requesting work to fill the cache to 2.5 days, but instead are being refused work and are receiving this message.

This is not like the old EDF , which I have seen before. This is something else.

Edit: BTW, there is nothing pre-empted or suspended on my machines.

Edit2: Checked again. Jobs would be finished with even more than 5 days+ to spare. Deadlines are either 03/04/2007, 04/04/2007 or 05/04/2007.

Yes, but are those deadlines before or after the 'connect to'? If before, the EDF - which technically does not exists anymore in it's old form for 5.8, but was used here as easy 'oh yeah' - kicks in i.e. 1.5 days is before 2.5 days, when the next scheduled connect is expected. Given that there is the 1 day safety factor, the 'panic mode' as is described takes hold.

Still cant understand whole sets of 19 copies for HPF2 being distributed.... there is no rush. Have asked in the CA room if the technicians have an answer to that.

If you are still running the network default of 0.1 day, ANY new unexpected workunit can interfere with the deadline.

If it sends you a LOT of 1 day workunits, it makes sense that the others might get pushed out beyond the deadline. I usually don't get more than 1 of them in the same download, so they can sneak in with no problems to the other workunits.

I see this happen more often when when running multiple BOINC projects. When a new project is attached, it seems to pretend that it can run the entire queue and fill it up with a complete set to run between network visits. After that, other things previously in the queue get the "can't finish in time error".

If you already have a queue of 2.5 days or whatever, it might also be worth setting the network days back to something like 0.1 to 0.5 before adding a new project, and then set it up to 2.5 or wherever it was after only a few new workunits download. That way you won't get too many.
If it happens to be a long download, I have managed to set the project to "won't accept new tasks" before another one is sent. I'll accept new tasks again shortly after I play with network days and I check the profile.

You also have to watch the project mix amounts in each new project BOINC profile, which will default to 100.0. If your previous projects were 25, 25, 25 and 25, the new project would then get 50% of allocation (100 / the new total of 200) and the others 12.5% each. I run and change that number when joining, just before starting or joining a team. These wild fluctuations can affect due dates.

Differences in due dates can also make a big difference when running multiple projects. Pick similar due dates, which range from a few hours to a few months for the climate simulation projects. Well...those can't really be practically combined with others. I tried it, and one CLIMATE project workunit said that IT couldn't finish before the due date.