They are starting to lengthen again. Went from 10 minutes to 30 minutes and current ones are approximately 95 minutes each. For reference, prior to the 10 minute ones, the machine was running 245-250 minutes a task.

No, I don't think a 24 hours queue is dangerous. I currently have had a 1.5 day (36 hours) queue for some time (aprox. 1 year) and nothing has happened. Now, could the scenario you described really happen? Yes. Is it likely that it will happen? No. And if it did happen, the only thing that would happen is that the excess WUs would timeout and be sent out again to be crunched. So no danger. I'm sure there are crunchers that have queues bigger than those described above. On a couple of times, for DDDT2 I would have a 10 day queue, so I could capture all the WUs possible (and yes, I would lose some WUs at the very end which just got sent out again). Now this is an excellent opportunity to discuss what is the ideal queue to carry and why. Comments?

CJSL

Gotta keep crunching, there's a world to save...

No based upon what evidence? Also with too long of a queue and with a minimum quorum of two, if the result is returned and the wingman takes a lot longer, that WU sits there and takes storage up. Not long ago MCM had an issue where the WU results were bigger than normal but still in what the project said was possible. This caused storage issues and caused the project to be temporarily disabled. Add in large WU results and big queue depths and some WU results might sit for over a week before the wingman returns their result.

I have also seen where large queues actually slow the processing down. WU's can be aborted on the server side as well and when your computer communicates with the project servers it validates the WU's in your queue; more WU's more processing required. I don't run a long queue in WCG but did on another BOINC project and noticed when I would increase the queue depth processing went down, reduced the queue and processing went up. The WU times were always consistent but crept up when the queue depth was increased.

Under MCM1 there have been short running WU as well, usually it is just 10,000 WU's though and not multiple sets in a row. By running a shorter queue, I ran quite a few of the short units whereas the people with longer queues only got a few. Your machine viewed them as standard runtime WU's which is how mine viewed them but kept downloading more of them as the current running ones were approaching 100%. On several machines that had 12 or 16 concurrent WU's running on them they were almost always downloading additional WU's and reporting completed ones and this went on for several hours before the WU times started to increase again. On a typical day I complete around 500 WU's spread over mainly MCM1 and CEP2 with a few FAAH results. On the 6th I was at over 800, so I did 50% and so far on the 7th, I'm at over 2,700. So in my case, a shorter queue allowed me to run through more WU's.

The large WU's caught them off guard even though the sizes being returned did fall into the range the project said was possible. Just because something hasn't happened doesn't mean it won't.

Large WU results and long queues played a role role in the recent shutdown. Add in changing run-times and you have the trifecta.