Missing Preferred bigadv target?

[Qinsp]

I'm probably going to miss the Preferred Deadline by 1-4 hours.

A) Does that count as failed unit?

B) Does it get normal SMP points?

Thanks, won't do that again. Needed a line in the sand.

[orion]

When a WU misses the preferred deadline it gets reissued to someone else.

You will receive the base points for it, no QRB. For an 8101 that will be 22,607.

If it misses the final deadline you receive no points.

For testing a system to see how it does on TPF for bigadv I would suggest doing this http://hardforum.com/showpost.php?p=103 ... tcount=433 It works really well and should be part of every bigadv system test before send it out into the great unknown.

[Joe_H]

When a WU misses the preferred deadline it gets reissued to someone else.

Correction, it may get reissued. Whether it does or not depends on when the WU gets returned, a WU may not get reissued for a period of time after the preferred deadline passes.

[orion]

I was under the impression that it always got reissued...I stand corrected and thank you.

[Jesse_V]

I'm pretty sure the reassignment is dependent on whether the WU was completed before the final deadline, i.e. the expiration.

[7im]

By policy, WUs get queued for reassignment a very short time after the Timeout (formerly Pref. Deadline).

I can't speak to the exact timing (next minute, next day), jumping to front of the line, etc.

[Qinsp]

Semi-related. Is this 1 hour delay normal? Look where it says "done". When do they "stop the clock" for the deadline?

Code: Select all

11:27:11:WU01:FS00:0xa5:logfile size: 190652
11:27:11:WU01:FS00:0xa5:Leaving Run
11:27:12:WU01:FS00:0xa5:- Writing 96308712 bytes of core data to disk...
11:27:35:WU01:FS00:0xa5:Done: 96308200 -> 91569947 (compressed to 5.8 percent)
11:27:36:WU01:FS00:0xa5:  ... Done.
12:47:47:WU01:FS00:0xa5:- Shutting down core
12:47:47:WU01:FS00:0xa5:
12:47:47:WU01:FS00:0xa5:Folding@home Core Shutdown: FINISHED_UNIT
12:57:22:WU01:FS00:FahCore returned: FINISHED_UNIT (100 = 0x64)
12:57:22:WU01:FS00:Sending unit results: id:01 state:SEND error:NO_ERROR project:8101 run:20 clone:4 gen:126 core:0xa5 unit:0x00000094088988e14f9993487455f94d

[Joe_H]

It is semi-normal for the delay in processing the results to send. The delay can be worse depending on the filesystem settings for your Linux install, search for posts on long write times connected to EXT4. A discussion of barrier settings is here. As for "the clock", it starts when the WU is downloaded for the first time and stops when it is uploaded.

[Qinsp]

Wow.

Is there a way to RAMDISK a Linux system? There is plenty unused RAM to fix this, since the disk write is pointless anyhow. It's using the disk as RAM.

DOH!! That took 5 seconds to find. http://www.linuxscrew.com/2010/03/24/fa ... untulinux/

How do I configure FAH to use the RAMDISK instead of the HDD?

[codysluder]

How do I configure FAH to use the RAMDISK instead of the HDD?

The fah data directory contains everything needed to process WUs except the actual client software. If you have room, you can move it to RAMDISK and make that the current directory before starting the software. If that's too much information, you can link RAMDISK in place of the WORK subdirectory. Be aware that if your system goes down, data on RAMDISK will be lost and any WU will be lost. You might as well set checkpoints to 30 minutes instead of 15. You can devise some kind of backup, but running 24x7 is a lot easier and the FINISH function can make it unnecessary.

[Qinsp]

Thanks!

There must be something else going on, but if altering the filehandling will improve the situation, I'll play with that.

That segment of the code needs to be profiled. No way you spend over 4,000 seconds doing 96mb of file moving. I don't care if you verify every byte and triple encode it.

My fileserver is shared by 20 computers. It's Linux EXT4.

I grabbed a folder with 48 directories, 429 files, and 162mb total. From a remote computer running WinXP, I copied it to my local drive from the EXT4 fileserver (14sec), then copied it back (12sec), then deleted both test directories, (7 sec). Note that it's going through the network with other computer traffic.

So actually reading/writing/deleting a LOCAL HDD a mear 96meg can't take more than 33 seconds for the actual EXT4 activities. I don't have any custom switches.

It's either caught in a loop, or it's waiting for something, then times out.

OR, it's still calculating something. If filehandling is to blame, there is something faulty in the code, not the switches.

[codysluder]

It has been explained somewhere on this forum by "tear" and he agrees that the code needs to be rewritten but it's a byproduct of changes made for EXT4. I don't understand it, but it has something to do with a lot of unnecessary "sync" operations in the code not playing nicely with the barriers concept. It can be bypassed by disabling barriers on EXT4 or by reverting to EXT3.

[Qinsp]

Darn. I wish I had known that before I had put EXT4 on 4 folding machines.

[Qinsp]

NTFS have any issues?

[Nathan_P]

NTFS have any issues?

For folding purposes, none that i am aware of, ran -bigadv under win 7 for several months and never had any problems.