Page 1 of 1

Problem after an unwanted shoutdown

Posted: Thu Mar 18, 2021 3:53 pm
by DiegoC
Hello Everybody,

It's Diego

It's about two days i had an unwanted immediate shoutdown.

Now I have 2 work in progress.

One is the work in progress my pc is doing (all ok with this one)

the Other work is work 17231
in Eta: unknown
with progress of 100%
in state: cleanup

It's about 2 day in in that state cleanup and I'd like to delete this work.

May anyone tell me how to delete work from queue in fahcontrol?

Thank you for any help

Diego C

Re: Problem after an unwanted shoutdown

Posted: Thu Mar 18, 2021 9:40 pm
by iero
What is the expiration date on the "failed" WU? In any case it will drop itself at that date, since it will have expired.

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 6:54 am
by bruce
DiegoC wrote: the Other work is work 17231
in Eta: unknown
with progress of 100%
in state: cleanup

It's about 2 day in in that state cleanup and I'd like to delete this work.

May anyone tell me how to delete work from queue in fahcontrol?

Thank you for any help

Diego C
It looks like you're causing the problem. There is no valid way to delete a WU which is in cleanup. You shouldn't be deleting WUs anyway without a really good reason. FAHClient manages the queue and when a WU is finished, it will automatically be deleted. That is called CLEANUP, meaning FAHClient is trying to remove the file from the queue.

If you've opened those files using some other program (Browsing in "/work" is not supported except viewing the log through FAHControl.) If you've opened a work file -- say with an editor -- FAHClient's efforts to cleanup that file will be blocked by the OS.

Please explain what you intended to do and why. Post the applicable segments of FAH's log.

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 1:27 pm
by DiegoC
To iero
Thank you iero so I will wait the expiration date of work...

To Bruce
well it was a stupid reason i think . Unfortunately I put my hand onto the pc for 4 5 sencond and unfortunately my power button is on top of pc so the pc went in an unwanted immediate power off. I think this created the problem.

if you want to share how to delete Wu then i will do that otherwise i will wait for expiration date.

The main point is that work will be purged sooner or later
In any way thank you too

Diego

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 5:15 pm
by DiegoC
Bruce wrote:
Please explain what you intended to do and why. Post the applicable segments of FAH's log.

To Bruce

From Log
17:09:33:WU01:FS00:Cleaning up
17:09:33:ERROR:WU01:FS00:Exception: boost::filesystem::status: La directory o il file è danneggiato e illeggibile: "work/01/viewerFrame66.json"

i didn't try to edit or view nothing .... nothing unusual except of the pc stop I said happened

I don't know what is that java file

May you explain what's happening?

Tell me if you want further detail in order to reassign the work unit PRCG 17231 (247, 4, 32) (it's enought to identify the work unit?)

Bye

Diego

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 10:12 pm
by bruce
Yes, stupid shutdowns do happen. I'm surprised that killed the WU but there's a small chance it did.

What does FAH's log say?

Are you running Windows/Linux/MacOS/etc.?

I looked up that WU and it was successfully completed by somebody called "DidFah" on team 40051

I can't tell if Gen 33 has been assigned yet or not.

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 10:50 pm
by DiegoC
Yes It's me DidFah

I use my real name for forum Diego C

:))

So the work unit is safe

....

Perhaps is it better I finish the current work unit in progress then I reinstall Fah? Does it fix cleanup problem?

Diego

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 11:20 pm
by bruce
Right. Now the only issue is waiting for FAH to complete it's cleanup processing or you learning to do it manually.

I'd recommend restarting or just forget about it.

Re: Problem after an unwanted shoutdown

Posted: Fri Mar 19, 2021 11:29 pm
by DiegoC
Bruce said:
Right. Now the only issue is waiting for FAH to complete it's cleanup processing or you learning to do it manually.

Here the Fah log of today
17:09:33:WU01:FS00:Cleaning up
17:09:33:ERROR:WU01:FS00:Exception: boost::filesystem::status: La directory o il file è danneggiato e illeggibile: "work/01/viewerFrame66.json"

it say that directory or file is damaged or unreadble "work/01/viewerFrame66.json"

if it's quite simple to delete it manually sure tell me what to do.

Re: Problem after an unwanted shoutdown

Posted: Sat Mar 20, 2021 12:26 am
by bruce
Yes, you posted that earlier. I doubt you can delete that file when FAH is running.

Are you running Windows/Linux/MacOS/etc.?

Re: Problem after an unwanted shoutdown

Posted: Sat Mar 20, 2021 1:36 pm
by DiegoC
SOLUTION

FOR THE ONES WITH A CLEANUP PROBLEM WU FILE: file è danneggiato e illeggibile: "work/01/viewerFrame.. .json

Scenario: Tipically in this scenario the OS I use don't let you delete a damaged file but try:

First of all push finish button in fahcontrol then just wait the wu you're doing come finished then:
1) Uninstall Fah in order to have stopped the Fah program or as you want to call the Fah running routine
2) Launch chkdsk /x from admin user in command prompt and then look if file damaged still exist or then try delete it.
3) Reinstall FAH

Have a nice time there.

Diego

Re: Problem after an unwanted shoutdown

Posted: Sun Mar 21, 2021 12:02 am
by bruce
Depending on the structure of the filesystem that's running on your system, an unexpected loss of power often corrupts the file system because open files are partly written to disk and partly still cached in RAM. DiegoC recommendation to run chkdsk is probably the only thing you can to to correct that error. The filesystem's index will tell the OS where the file starts and how long it's supposed to be but it won't really be that size and chkdsk will figure that out and correct it but that can only happen when no other application might update the disk indexes.

Re: Problem after an unwanted shoutdown

Posted: Fri Oct 07, 2022 7:31 pm
by djchandler
This happens with every restart since I started running a native Windows client. It does not happen in a virtual machine running Linux. I have not run Linux on the AMD Ryzen 7 5700G other than as a VM or container. The GPU hardware interfaced via X. therefore the MS hypervisor can only see the CPU.

If I get an unwanted GPU client, I immediately pause all clients, and delete the GPU slot. The default settings just barely complete on time. If I limit to less than 12 GPUs, they won't make it, and my computers performance is unacceptable if I let it run. The GPU client is trying to run on a Ryzen 7 5700G with nothing but what is on the main chip (besides my CPU.) There is apparently no way to stop this from happening, so I resort to brute force.

Don't bother Microsoft; the openGL and openCL components they provide are NOT currently configurable. Just run a VM if you want CPU only in Windows. That's too bad.

Re: Problem after an unwanted shoutdown

Posted: Fri Oct 07, 2022 8:54 pm
by djchandler

Code: Select all

 <config>
  <!-- Folding Core -->
  <checkpoint v='10'/>
  <core-priority v='low'/>

  <!-- Folding Slot Configuration -->
  <cause v='HIGH_PRIORITY'/>

  <!-- Network -->
  <proxy v=':8080'/>

  <!-- Slot Control -->
  <pause-on-battery v='false'/>
  <power v='FULL'/>

  <!-- User Information -->
  <passkey v='8663b3b16d850b5ff8ebd84353fb32b0'/>
  <team v='4600000000000000'/>
  <user v='me'/>

  <!-- Folding Slots -->
  <slot id='0' type='CPU'>
    <cpus v='8'/>
  </slot>
</config>
Editing config.xml does nothing as well. Just let F@A manage it.
Running A8 on 8 cores is yielding > or = 1,200,000 pts./week as currently configured with no GPU slot. Everything takes a HUGE hit from the GPU client on the Ryzen 7 5700G.

Re: Problem after an unwanted shoutdown

Posted: Fri Oct 07, 2022 11:08 pm
by BobWilliams757
Djchandler

I think it's a different things in your case than what the OP is describing. In your case the GPU is identified as soon as you start F@H. This was an intentional and desired feature of the client so that rather than manually adding GPU's they would be detected. So in your case the CPU identifies, as well as the (on chip) IGPU. Both can work individually or at the same time.

If you want to fold on CPU only, you can set the GPU to "pause on start" in the expert mode tab. This will still show the integrated graphics, but they won't start folding unless you want it to. You can use the same command for the CPU if wanted, to ensure nothing folds until instructed. I'm not quite sure what your statement on "If I limit to less than 12 GPUs, they won't make it" implies, so I can address that.

As for performance, both CPU and iGPU can take a hit if using both at once. Using only one or the other gives much better results, even if the end PPD is slower than the two combined. Based on your number stated though, I suspect you might be running on both. I doubt that CPU is producing 170k+ PPD.