FAH throwing away almost completed job

[nigelramsden]

I returned to my FAH client this morning to find it had thrown my current job away. It was 95% complete, representing 66.5 out of 70 hours of work. Looking at the log I see it timed out. This is madness.

 

Recently I've noticed that although a typical job takes my machine 3-5 hours to complete, a minority take over 2.5 days of uptime. This was such a job: at 8 hours, 5 days a week it would take nearly two weeks to complete. It happened there was a long weekend involved.

 

The title of this project is Folding At Home, not on your managed server farm. I don't want to leave my computer running at max heat output when I'm not there. But neither do I want to waste MIPS, cash and CO2 on a task that bails at 95%. Especially not with energy prices heading for the stratosphere.

 

Here are some helpful suggestions. I've read the threads saying it's hard to predict how long a unit will take before you download it. But within 15 minutes the client has calculated this pretty accurately. So why not provide a control saying how long you're prepared to wait for and get the client to abort if it's going to take longer. Or, better, extend the timeout if you're clearly on track to complete soon. Or even just provide a button allowing the user to reject the job early on?

[Gorgon]

I can see how that would be frustrating. If you could provide some details about your hardware and how your limiting it to folding for just 8 hours a day for weekdays we might be able to offer some suggestions.

 

Personally I don’t fold on my CPUs anymore. I just use GPUs for Folding and I run BOINC on my CPUs which tends to be a little more forgiving of being interrupted and more easy to schedule to run when electricity is least expensive.

[rkv_2401]

Hi, I can empathize with how irritating it is when that happens because I had similar problems when folding on my Surface 6.

 

This is more of a workaround than a solution, but what I found works for me is reducing the # of threads to 4 (or maybe 6, haven't tested this). The big WUs are only released for CPUs with more threads, and whilst F@h productivity might be reduced this way, at least it's far less likely to go to waste. Also, this would reduce electricity costs and heat generated.

[nigelramsden]

Sorry for the late response @Gorgon

 

My hardware is 2 x (2013-era) Xeon 2630s with 8 cores each. No GPU as it's a server.

 

I've tried max-packet-size = small and it's so far limited downloads to those taking 1 day to complete. But too small a sample size of jobs to be sure yet.

 

[Gorgon]

5 hours ago, nigelramsden said:

Sorry for the late response @Gorgon

 

My hardware is 2 x (2013-era) Xeon 2630s with 8 cores each. No GPU as it's a server.

 

I've tried max-packet-size = small and it's so far limited downloads to those taking 1 day to complete. But too small a sample size of jobs to be sure yet.

 

Nice! the e5-2630 v3 Haswells? (They're the only 8-core ones in the E5 lineup I believe) I'm still running an e3-1231-v3 on my Windows Daily Driver so around the same vintage.

 

How may threads are assigned to the Folding slot? If your running say 12 you could split it and assign 2 x 6t instead by changing the number of threads for the existing CPU slot from -1 to the new amount then creating a second CPU "slot" as desired. That may force smaller tasks to them. Also there is this weird issue with F@H where slots with threads equaling multiples of primes above 5 cause issues so what you set may be adjusted.