FCI: Folding@Home Client Info (Web based client monitor)

[smoking2000]

qd is not involved in the TPF calculation other than supplying the queue index and PRCG numbers to find the WU in the FAHlog.

The reason why the TPF is not calculated for your latest WU is because FCI can only find the the queue index in question, but not the PRCG because it is corrupted.

From your FAHlog:

Code: Select all

1745 [17:51:37] Working on queue slot 00 [March 10 17:51:37 UTC]
1746 [17:51:37] + Working ...
1747 [17:51:37] - Calling './mpiexec -np 8 -host 127.0.0.1 ./FahCore_a2.exe -dir work/ -nice 19 -suffix 00 -priority 96 -checkpoint 30 -verbose -lifeline 2406 -version 629'
1748 
1749 [17:51:37] 
1750 [17:51:37] *------------------------------*
1751 [17:51:37] Folding@Home Gromacs SMP Core
1752 [17:51:37] Version 2.10 (Sun Aug 30 03:43:28 CEST 2009)
1753 [17:51:37] 
1754 [17:51:37] Preparing to commence simulation
1755 [17:51:37] - Ensuring status. Please wait.
1756 [17:51:37] Working with standard loops on this execution.
1757 [17:51:37] - Files status OK
1758 [17:51:41] - Expanded 30Called DecompressByteArray: compressed_data_size=Called DecompressByteArray: compressed_data_size=30323145 data_size=159726549, decompressed_data_size=159726549 diff=0
1759 [17:51:43] 15, Clone 11, Gen 47)
1760 [17:51:43] 
1761 [17:51:43] Assembly optimizations on if available.
1762 [17:51:43] Entering M.D.
1763 [17:51:43] ing M.D.
1764 [17:51:52] lone 11, Gen 47)
1765 [17:51:52] 
1766 [17:52:10] Entering M.D.
1767 [17:53:48] Completed 0 out of 250000 steps  (0%)

You can restart your FAH client on the hope that it will log the lines correctly then.

[rhavern]

@smoking2000

I'm running version 1.6.1 and looking at project 6012 on one of my machines. On the project page in FCI, I see the kfactor as 2.00 but the BF is listed as 1.00. I'm listed as 8.37 times minimum required speed, about 2.5 days before the preferred deadline. Shouldn't the BF>1?

Thanks, rhavern

[smoking2000]

The bonus factor is provided to FCI by qd, and qd will only show bonus factor if all the following conditions are met:
* Greater than zero points (pts)
* The final deadline is known (due: N days)
* The preferred deadline is known (preferred: N days)
* The project has greater than zero kfactor (kfactor)
* The approximate assignment time of the WU is known (issue or begin)
* The end or expect date of the WU is known (end or expect)
* A passkey is stored in the queue.dat for the WU (passkey)
* The WU is not deleted (status)
* WU completion is (expected) before the preferred deadline

I presume the project 6012 you're talking about, is the WU in Index 2 of your Olive SMP client. This WU indeed seems to meet all requirement, except for the passkey. The passkey: Yes reported by FCI is parsed from the client.cfg, but qd's bonus calculation requires the passkey to be stored in the queue.dat too. This used to be done always, then after some controversy it was no longer stored for some time, but recently it reappeared in the queue.dat. I'm not sure where it's decided to store the passkey in the queue.dat or not, whether that is the FAH client (most likely) or the FahCore, or possibly some negotiation between them or between the FAH client and the Work Server. Whatever the reason for not having the passkey in the queue index in question, it will prevent qd from calculating the bonus.

[smoking2000]

I just noticed that your Olive SMP client is still running qd fr 080, this release does not support the bonus factor yet. You'll need at least qd fr 081 for bonus support (and qd fr 082 is most recent).

Running your FCI client with --update-qd should get you the latest.

[rhavern]

Good spot. I did have --update-qd in my scheduled task, but I think my password needed quotes to be able to read past it. Working now, thanks!

[jimerickson]

am running subversion. keep getting this but ~/.fci/qd exists. what am i doing wrong?

Code: Select all

jimerickson@odysseus:~$ fci-client.pl
sh: /home/jimerickson/.fci/qd: not found
sh: /home/jimerickson/.fci/qd: not found
File does not exist:  at /usr/local/bin/fci-client.pl line 1273

[smoking2000]

You probably don't have the 32bit compatibility library installed to allow the 32bit qd to be executed?

Run fci-client.pl in verbose mode to see where and when it actually goes wrong.

[jimerickson]

thank you smoking2000 you are exactly right. just upgraded to ubuntu 10.04 so thats why i overlooked it. thank you for all you do.

[jimerickson]

smoking2000

is there any way to have fci "see" a windows gpu console client folding in wine on ubuntu?

[smoking2000]

Define "see".

My GPU clients all run on Linux, and FCI sees them just fine, just point fci-client.pl to the FAH client directory.

[jimerickson]

sorry for being so stupid smokin2000 i was just having problems with the config file syntax.

[smoking2000]

Not entirely your problem, my documentation is not full proof either

The documentation/INSTALL.<OS> file documents almost everything you need to know, the rest is documented somewhere in this topic.

You don't need to write the config file yourself, you can save it by running fci-client.pl with all the arguments you need to use and append --save-config to have them saved to the config file so you don't need to specify them for all runs thereafter.

This feature was completed in FCI v1.4 (before only stub code was available).

[jimerickson]

getting this message when updating client

Code: Select all

Not an ARRAY reference at /usr/local/share/perl/5.10.1/Date/Manip/Date.pm line 1352.

[smoking2000]

Please post the verbose output of fci-client.pl so the warning has context.

[smoking2000]

I just checked your FCI server, and see the error on the client page. The TPF calculation fails for some reason, and in your client.xml I see that the delta_format() routine is not working because it gets an unexpected date delta (e.g. +0:0:-0:1:15:51:11 where it should only have a plus or minus sign at the start of the string).

Since you recently upgraded to Ubuntu 10.04, you're likely using Date::Manip version 6.05 whereas Debian stable still uses Date::Manip 5.54. So I'll have to study the Date::Manip::Migration5to6 document to see what changes are required. I already see one related to this issue:

If you parse the strings "today", "yesterday", or "tomorrow" in order to get the time now, or 24 hours in the past/future, this will no longer work. These strings now refer strictly to the date (so "today" is the current day at midnight, "yesterday" is the previous day at midnight, etc.).

I'll have a look after I get back from work.