That would work if it is only a "long" WU." If the program is in an endless loop or is on a diverging path it would never end. The 18 hour limit is there as a stop gap measure in those cases. I believe the 18 limit was also put in place because the scientists figured this would be sufficient for most of the machines to return a meaningful result most of the time. The fact remains there are some systems which are going to be too slow for this project, but I presume they are few and far between. There are also some molecules which are too big for even the fastest consumer grade machines and these would then get kicked over to the the scientists' own workstation cluster.
Cheers

Sek, I think you might (just might) be being a bit too simplistic. Some things have changed.

For a start, this is a beta so presumably new molecule (types?) are being explored, so the boundaries are being pushed. We don't know if it's the type of molecule that takes a lot of processing, or if the algorithm is not converging well (or whatever it does) with these new molecules.

I also think that the processor power spread of user computers is changing as power gets turned down and CPU count goes up, so as to consume less electricity. As I said in an earlier post, a time-limit is a very crude brake. I personally think it would be better to use the number of actual processing steps, but that might need too many changes or too long a processing time on the slowest machines to be practical.

At the end of the day we should all just let the scientists and the techies do their bit and decide the right way to go. But I don't see anything wrong with crunchers expressing opinions. What we say may influence decisions and that's how it should be.

Sgt. Joe, the endless loop prevention is actually build into all project setup files in the <rsc_fpops_bound> parameter. Usually WCG has it set at 10x estimated fpops of the current distribution. Given the high variability of task duration, this setting could actually lead to a premature kill / max_time_exceeded. Suppose the current mean would be 1.5 hours... then the task could be killed at 15 for an average performing device. Have no CEP2 production or beta to see what the limit is set at, but probably the app was hard-coded to have them die at 18 no matter the device speed.

Well, I can only assume they know something we don't, as this seems weird!

I say it's weird because I don't know of any algorithm which is time dependent. If it does a thousand cycles on a slow machine and is killed after a time limit, why should I let it do a million on a faster machine? What would that buy me?

But maybe they know something I don't.