Because they use almost twice as much RAM and the consequent swapping would make them run much longer, so I'd expect them to do worse.

It's very probable Kremmen ran into the endless looping bug which is the only plausible explanation why running into the time exceed function. The workings are that a jobs of any project has the running current average flops in the header from which the device computes estimated time. In case of HPF2 that must have been exceeded by factor 6, which is the cut-off for this project.

Had one nearly myself yesterday before the eye caught a folding job running for 14 hours and at 48% when the machine normally does them in 4 to 5 hours. A suspend WCG (project tab!) and resume kicked it back to 1:50 hours and 44%. 12 hours lost in space.

I'll be updating the 'project matrix' in the website support forum shortly as noted that some of them changed their low/hi for ram and VM. FAAH is now on VM up to 360mb and HPF2 is down to 49mb lowest and 119.2 highest on RAM (BOINC) and 204mb on UD. Not for nothing does WCG set conservative minima for the eventualities on the System Requirement page.

No, it's not the only plausible explanation. Current CPU time/fraction done was consistently around 350,000 and looked to be on track for that all the time. However, "estimated CPU time remaining" started at around 100,000, which was quite silly.

The calculation of estimated time is often totally wrong. It seems pretty obvious that the likely time remaining should be current CPU time/fraction done. However, in the case of the software being moved from one piece of hardware to another, the software appears to come up with a totally bogus number. Maybe it's remembering irrelevant data from the previous machine somewhere instead of taking the current calculation as it should?

**Edited for improper language TKH**

See this interesting post on project time Here

NN