Over and over my system is getting this message, extremely irritating. I uninstall on my Mac and reinstall to get a new assignment but settings elsewhere on my machine seem to remember the old job and I can't break free. (In the process I seem to have upgraded to V 7.3.6) What should I do? (System gets 100% power, I have set Folding Core Priority to "Slightly Higher".)
INTERRUPTED happens when you intentionally PAUSE folding or when you make changes to parameters that alter how a FahCore operates. It also happens when the PAUSE function is invoked if you've got a slot set to fold only when idle.
It would be helpful to us if you could post the initial section of your log so we can see how you have configured the fahclient and suggest changes based on your needs.
ETA:
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time
To my knowledge, I haven't done anything to trigger this behavior. It just started happening. I have looked for any settings which might be causing FAH to get less than 110% of resources, e.g. tweaked the Folding Core Priority. Are there specific places you can suggest where a stray setting has been corrupted that I might go back and fix?
I noticed the following at the start of my log after I tweaked Folding Core Priority. Would access to more/all of the xml help?
Thanks
When you change <core-priority v='low'/> that cannot be applied without stopping and restarting the FahCore so you'll always get an INTERRUPTED message.
Changing core-priority is almost never useful -- unless you're running some other application that uses core-priority=idle, which would be unusual. The real question you have to ask yourself is what other unneeded applications are you running that are taking priority over FAH. If they're unneeded, shut them down rather than preempt them.
From the log segmented posted, I noticed the following:
1) Is there a specific reason that you chose to change the default action for the battery:
<pause-on-battery v='false'/>
2) You have posted in a thread that is for GPU project 11292. However, I can only see a CPU slot configured and no mention of GPU:
<slot id='0' type='CPU'/>
If you want to fold on a GPU that is supported, we can help you. If not, we can split the topic.
ETA:
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time
oops re GPU project 11292. I just saw what looked like unanswered problems re INTERRUPTED and posted here. Fine to split off.
I did the pause-on-battery switch because I'd just as soon my project keep working if I have to move my laptop from one place to another.
I changed core-priority to v='low' as another item from my kitchen sink of possible fixes.
Apps running on my Mac included Firefox, Safari and Chrome all monitoring separate twitter accounts. I just tried quitting the Chrome and Safari instances and I closed the Firefox sessions running twitter. Some facebook instances are still running on Firefox. (Didn't help, still went through the INTERRUPTED cycle.)
My point was that there were very few cases where changing priority would solve whatever your problem was, but you'll always get INTERRUPTED whenever you change priority. (I'm not sure about battery.)
Let's just say that if INTERRUPTED is a problem for you, don't make (unnecessary) changes.
Are you still encountering the issues? If so, can you post a fresh log after you restart your system and leave if running overnight so we can get a better picture of what is going on. Make sure that you include the initial section of the log which contain the system configuration and your fah set-up.
ETA:
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time
Here's the log after restart. Again, as far as I know, I made no changes, these INTERRUPTIONS started happening out of the blue. After a while of that I DID try making some changes, to no avail.
Thanks
In my experience with the A4 folding core on OS X, the FahCore returned: INTERRUPTED (102 = 0x66) message repeatedly showing up immediately after the 0xa4:Mapping NT from n to n entry in the log has usually meant the WU is bad or will not fold on my setup. If you are not doing anything else to pause the client folding, that is what I suspect is happening in your case. There is an open report on the core and client not discarding a WU after the 8 improper terminations mentioned in the log:
22:27:06:WU01:FS00:0xa4:Examination of work files indicates 8 consecutive improper terminations of core.
It is possible that the WU is not bad, but will fold for someone else with a different setup. But so far about two thirds of the WU's I have seen fail with this type of error did turn out to be bad for others as well. So far there are no reports in the database for this WU. I have notes at home on how to dump a WU under OS X, will check them after I get off work. Let us know if there is any change. In the meantime, I would suggest you undo any of the changes you have made as they are not doing anything useful. The pause on battery setting is one you can leave whichever way works for you. I happened to have made the same choice on my laptop, the magsafe adapter comes off fairly easily when the cat jumps into my lap and I just replug it in.
iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
The easiest way to dump the pesky WU is via FAHControl.
Delete the slot and create a new one:
Configure > Slots > select slot > click Remove > click Add > select CPU if not already selected > click OK > click Save.
I like that suggestion re remove/add the Slot but I don't see that the system went to get a new assignment. Still seems to want to work on:
Project: 7809 (Run 7, Clone 445, Gen 38)
The remove & add slot won't work as a method of dumping a WU in this situation. You need to run the client without the CPU slot for the client to dump the WU. Running the client with no slots won't work because the config will be invalid so it will simply recreate a default CPU slot before dumping. So the solution is to remove the CPU slot and add a GPU slot then run the client. Only after the client has dumped the WU can you then fix the config to have the CPU slot and no GPU slot.
I contend it is easier to stop/pause the client (to eliminate any file-lock problems) and then go to the work folder and delete the work queue folder that matches the WU. Then simply restart/unpause the client. Since the data in the work queue is gone, the client just dumps the old WU and gets a new one.