Large wu 16410 vs Core2Duo Laptop - Abort??

[peterjammo]

One of my old core2duo laptops has just been given a 16410 wu. It must be pretty big as its base points are 4476, and my estimated time to complete is 2.5 days. The description calls it a high priority. While I'm comfortable that my machine can get through it, and the allowed time is nearly 6 days, given the high priority would it be better to abort it and let it be re-allocated to almost anyone else to fold quicker?

If so, how do I abort? Running Linux Mint 19.3.

[JimboPalmer]

F@H is never better off if you abort WUs. It has to detect that a time limit has elapsed and a WU is missing, then reassign it. You can finish before that same time limit and not cause more work for the assignment servers.

[peterjammo]

OK, thanks for that.I wasn't sure whether there was a way to abort that would allow immediate reallocation. I'll happily let it grind away at the job. Stabilised estimated PPD is nearly twice what I usually get on that machine, which also suggests to me that it's a pretty high priority project. Estimated TPF is almost 4 times my usual number too,so it must be pretty chunky.

[Neil-B]

https://apps.foldingathome.org/psummary may give you a bit more ... yes is it big iirc I had a few starched my TPF out a bit as well

[bruce]

F@H is never better off if you abort WUs. It has to detect that a time limit has elapsed and a WU is missing, then reassign it. You can finish before that same time limit and not cause more work for the assignment servers.

Consider maybe you've already worked on that WU for half a day. If you did abort, it would have to go back in the queue to be assigned to someone else and it might take a while to get to the top of that queue. The person it gets assigned to is likely to have a faster CPU than your Core2Duo but would that mean that the completion date would be earlier? Who knows.

Are you sure it has been running long enough for the estimated completion date_time to be re-estimated with actual data? Initial guesses for a new project are often SWAGs.

I'll pass on a suggestion that this project should require at least N CPU-threads for some N.

[peterjammo]

Again, thanks for the advice. Currently done 19% at about 11 hrs and saying 2.11 days to complete. Was saying 5.9 days limit last night, but I'd rather not open the browser on the 1Gb ram on that machine to recheck. Can you check the limit from FAHControl?

I'd have thought 4 thread min for this type would be a sensible minimum.

[Joe_H]

Yes, FAHControl shows three date/time figures for the running WU towards the bottom right, depending on the size window you have it in you might need to scroll down. Top figure is when the WU was assigned, middle is the Timeout when bonus point end, and the last is the Expiration or Deadline at which point the WU is discarded.

The times are in UTC or Zulu time, that Z at the end, and match the timestamps in the log. You just need to apply the offset from UTC to you local time to convert.

[peterjammo]

Thanks Joe,

Expiration is 6th April, ETA 1.7 days now. Should manage that ok...

[peterjammo]

Just while I think of it, if the laptop was to die while running, can I switch the hdd to another (Linux Mint so that works fine and I have 1 identical unit running which could be used once it's wu is complete) and complete the wu that way?

[Joe_H]

You should be able to swap the HDD into another system as long as they are very close in configuration hardware wise.

[peterjammo]

Got just above 80% complete, then I noticed that the status had gone to updating. Came back live after a bit, worked for another hour or so then the status went to updating again. When it came back up this time, it was no longer doing 16410, but had started a fresh wu. I tried to look at the log, but my mouse had frozen. I rebooted and looked in for the log in var/lib/fahclient/logs found the relevant log, but it won't fully open. Says i/o error after loading part through. 2.5 days wasted. Hope it gets reallocated before the 7 day timeout is reached in this case.

Am I right in thinking that the i/o error in the log suggests an hdd problem on the machine?

[Joe_H]

Sounds like that, or the disk ran out of space holding the temporary work files.

[peterjammo]

Shouldn't be space on this one. I formatted and new installed Mint 19.3 just to run this. I'll set it to finish and when it's done with the current wu I'll run some disk checks. Because this one was put together out of leftovers, it's only got 1g of ram. I know FAH isn't ram hungry, but is there a lower limit?

[peterjammo]

Sounds like that, or the disk ran out of space holding the temporary work files.

Disk check came back clear. Is there possibly a space issue with a default Mint 19.3 installation vs where the temp work files go?

I've just picked a wu on another Mint 18.3 machine that has settled at 2.7 days to process.Is there anything I can do or check to give it best chance of completing. Before it loaded I'd run bleachbit to free as much disc space as I could, and checked the hdd.

Neil-B's suggestion seems wise for the big wu s.

I'll pass on a suggestion that this project should require at least N CPU-threads for some N.

[Neil-B]

Much as I'd like to get the credit I believe you might be quoting bruce