#965 FAHControl cannot save config.xml - Linux system

Moderators: Site Moderators, FAHC Science Team

#965 FAHControl cannot save config.xml - Linux system

Postby art_l_j_PlanetAMD64 » Wed Jan 23, 2013 12:55 am

One of my two Debian Linux v6.0.6 machines here cannot save config.xml from the v7.2.9 FAHControl Configure editing window. The two systems are partitioned differently, so that probably explains what is happening.

The #1 Debian Linux system was the first one I installed and set up, and when it came to the partitioning step, I chose the option of the installer automatically setting up separate partitions as follows:
  • / ext3 v1.0
  • /usr ext3 v1.0
  • /var ext3 v1.0
  • /tmp ext3 v1.0
  • /home ext3 v1.0
This is the system that cannot save the config.xml file.

The #2 Debian Linux system was (obviously) the last one I installed and set up, and when it came to the partitioning step, I chose the option of the installer automatically setting up only a single partition:
  • / ext4 v1.0
I had to manually choose the ext4 filesystem type, the default (as above) is ext3. This system can save the config.xml file.

When the #1 system fails to save the config.xml file, this is the message that is displayed:
On client "local" 127.0.0.1:36330: Failed to rename '/etc/fahclient/config.xml' to 'configs/config-20130122-222517.xml': Invalid cross-device link
obviously (I believe) referring to the separate partitions.

I see that this was addressed in Ticket #965, whose status is listed as "(closed defect: fixed)", although it also says "milestone set to v7.2.13". Do I need to re-download and install FAH v7.2.9 in my #1 Linux system to fix this fault? Or do I have to manually edit /etc/fahclient/config.xml until the bugfix is released? Please let me know. Thanks!
art_l_j_PlanetAMD64
Over 1.04 Billion Total Points
Over 185,000 Work Units
Over 3,800,000 PPD
Overall rank (if points are combined) 20 of 1721690
In memory of my Mother May 12th 1923 - February 10th 2012
art_l_j_PlanetAMD64
 
Posts: 472
Joined: Sun May 30, 2010 3:28 pm

Re: #965 FAHControl cannot save config.xml - Linux system

Postby 7im » Wed Jan 23, 2013 4:44 am

It means the fix is contained in a yet unreleased future version of the client so reinstalling 7.2.9 won't help. Manual editing will have to get you through until then.
How to provide enough information to get helpful support
Tell me and I forget. Teach me and I remember. Involve me and I learn.
User avatar
7im
 
Posts: 10189
Joined: Thu Nov 29, 2007 5:30 pm
Location: Arizona

Re: #965 FAHControl cannot save config.xml - Linux system

Postby Jesse_V » Wed Jan 23, 2013 6:29 am

Please be very careful when manually editing. It's something that's usually avoided so that the configurations don't get accidentally corrupted.

As 7im said, some upcoming version will fix it. Please be patient.
F@h is now the top computing platform on the planet and nothing unites people like a dedicated fight against a common enemy. This virus affects all of us. Lets end it together.
Jesse_V
Site Moderator
 
Posts: 2851
Joined: Mon Jul 18, 2011 5:44 am
Location: Western Washington

Re: #965 FAHControl cannot save config.xml - Linux system

Postby art_l_j_PlanetAMD64 » Wed Jan 23, 2013 6:34 am

Jesse_V wrote:Please be very careful when manually editing. It's something that's usually avoided so that the configurations don't get accidentally corrupted.

As 7im said, some upcoming version will fix it. Please be patient.

OK, I actually looked at the config.xml file from the "good" Debian Linux system, and I can copy the few lines I need from one config.xml file to the other. It was mainly to get next-unit-percentage set to 100.
art_l_j_PlanetAMD64
 
Posts: 472
Joined: Sun May 30, 2010 3:28 pm

Re: #965 FAHControl cannot save config.xml - Linux system

Postby Jesse_V » Wed Jan 23, 2013 6:39 am

art_l_j_PlanetAMD64 wrote:It was mainly to get next-unit-percentage set to 100.

I'm curious as to why you did that. Next-unit-percentage is usually set to 99 so that the next WU can download as the current one is finishing up. This avoids the upload/download downtime that was present in v6. Just recently, Bruce recommended 98% of 99%.
Jesse_V
Site Moderator
 
Posts: 2851
Joined: Mon Jul 18, 2011 5:44 am
Location: Western Washington

Re: #965 FAHControl cannot save config.xml - Linux system

Postby bruce » Wed Jan 23, 2013 6:57 am

Jesse_V wrote:Bruce recommended 98% of 99%.
I woudln't call that a general recommendation. That recommendation was addressing a specific roundoff problem in one protein in one FahCore. In that particular case, it only makes a difference of a few minutes.

What you use is entirely up to you. Change it from the default setting if you have a good reason. Personally, I use different settings on different machines and/or different slots.
bruce
 
Posts: 20140
Joined: Thu Nov 29, 2007 11:13 pm
Location: So. Cal.

Re: #965 FAHControl cannot save config.xml - Linux system

Postby art_l_j_PlanetAMD64 » Wed Jan 23, 2013 7:00 am

Jesse_V wrote:I'm curious as to why you did that. Next-unit-percentage is usually set to 99 so that the next WU can download as the current one is finishing up. This avoids the upload/download downtime that was present in v6. Just recently, Bruce recommended 98% of 99%.

On very long TPF WUs, downloading the next WU at 99% will significantly decrease the QRB of the next WU, especially if (as I have seen a couple of times) the first WU has a TPF of over 30 minutes, and the next WU has a TPF of less than 5 minutes. The download time of my ISP is so fast, that the next WU starts up almost as soon as the upload of the previous WU has completed.
art_l_j_PlanetAMD64
 
Posts: 472
Joined: Sun May 30, 2010 3:28 pm

Re: #965 FAHControl cannot save config.xml - Linux system

Postby art_l_j_PlanetAMD64 » Wed Jan 23, 2013 8:19 am

Here is a typical upload/download sequence from one of my computers here:
Code: Select all
05:31:50:WU01:FS00:0xa4:Completed 49999998 out of 50000000 steps  (100%)
05:31:50:WU01:FS00:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
05:32:00:WU01:FS00:0xa4:
05:32:00:WU01:FS00:0xa4:Finished Work Unit:
05:32:00:WU01:FS00:0xa4:- Reading up to 36696 from "01/wudata_01.trr": Read 36696
05:32:00:WU01:FS00:0xa4:trr file hash check passed.
05:32:00:WU01:FS00:0xa4:- Reading up to 600128 from "01/wudata_01.xtc": Read 600128
05:32:00:WU01:FS00:0xa4:xtc file hash check passed.
05:32:00:WU01:FS00:0xa4:edr file hash check passed.
05:32:00:WU01:FS00:0xa4:logfile size: 82317
05:32:00:WU01:FS00:0xa4:Leaving Run
05:32:01:WU01:FS00:0xa4:- Writing 1260805 bytes of core data to disk...
05:32:01:WU01:FS00:0xa4:Done: 1260293 -> 906580 (compressed to 71.9 percent)
05:32:01:WU01:FS00:0xa4:  ... Done.
05:32:01:WU01:FS00:0xa4:- Shutting down core
05:32:01:WU01:FS00:0xa4:
05:32:01:WU01:FS00:0xa4:Folding@home Core Shutdown: FINISHED_UNIT
05:32:01:WU01:FS00:FahCore returned: FINISHED_UNIT (100 = 0x64)
05:32:01:WU01:FS00:Sending unit results: id:01 state:SEND error:NO_ERROR project:6338 run:46 clone:18 gen:2 core:0xa4 unit:0x000000050002894b50d1deaac485e585
05:32:01:WU01:FS00:Uploading 885.83KiB to 155.247.166.219
05:32:01:WU01:FS00:Connecting to 155.247.166.219:8080
05:32:02:WU00:FS00:Connecting to assign3.stanford.edu:8080
05:32:02:WU00:FS00:News: Welcome to Folding@Home
05:32:02:WU00:FS00:Assigned to work server 155.247.166.219
05:32:02:WU00:FS00:Requesting new work unit for slot 00: READY smp:2 from 155.247.166.219
05:32:02:WU00:FS00:Connecting to 155.247.166.219:8080
05:32:03:WU00:FS00:Downloading 16.75KiB
05:32:03:WU00:FS00:Download complete
05:32:03:WU00:FS00:Received Unit: id:00 state:DOWNLOAD error:NO_ERROR project:6338 run:43 clone:6 gen:5 core:0xa4 unit:0x000000080002894b50d1dea539b81cc2
05:32:03:WU00:FS00:Starting
05:32:03:WU00:FS00:Running FahCore: /usr/bin/FAHCoreWrapper /var/lib/fahclient/cores/www.stanford.edu/~pande/Linux/AMD64/Core_a4.fah/FahCore_a4 -dir 00 -suffix 01 -version 702 -lifeline 1316 -checkpoint 15 -np 2
05:32:03:WU00:FS00:Started FahCore on PID 3363
05:32:03:WU00:FS00:Core PID:3367
05:32:03:WU00:FS00:FahCore 0xa4 started
05:32:04:WU00:FS00:0xa4:
05:32:04:WU00:FS00:0xa4:*------------------------------*
05:32:04:WU00:FS00:0xa4:Folding@Home Gromacs GB Core
05:32:04:WU00:FS00:0xa4:Version 2.27 (Dec. 15, 2010)
05:32:04:WU00:FS00:0xa4:
05:32:04:WU00:FS00:0xa4:Preparing to commence simulation
05:32:04:WU00:FS00:0xa4:- Looking at optimizations...
05:32:04:WU00:FS00:0xa4:- Created dyn
05:32:04:WU00:FS00:0xa4:- Files status OK
05:32:04:WU00:FS00:0xa4:- Expanded 16639 -> 55804 (decompressed 335.3 percent)
05:32:04:WU00:FS00:0xa4:Called DecompressByteArray: compressed_data_size=16639 data_size=55804, decompressed_data_size=55804 diff=0
05:32:04:WU00:FS00:0xa4:- Digital signature verified
05:32:04:WU00:FS00:0xa4:
05:32:04:WU00:FS00:0xa4:Project: 6338 (Run 43, Clone 6, Gen 5)
05:32:04:WU00:FS00:0xa4:
05:32:04:WU00:FS00:0xa4:Assembly optimizations on if available.
05:32:04:WU00:FS00:0xa4:Entering M.D.
05:32:05:WU01:FS00:Upload complete
05:32:05:WU01:FS00:Server responded WORK_ACK (400)
05:32:05:WU01:FS00:Final credit estimate, 670.00 points
05:32:05:WU01:FS00:Cleaning up
05:32:10:WU00:FS00:0xa4:Completed 0 out of 50000000 steps  (0%)
05:35:53:WU00:FS00:0xa4:Completed 500000 out of 50000000 steps  (1%)
05:39:56:WU00:FS00:0xa4:Completed 1000000 out of 50000000 steps  (2%)
05:44:07:WU00:FS00:0xa4:Completed 1500000 out of 50000000 steps  (3%)

From the time that the first WU was completed (05:31:50), until the time that the new WU download was completed (05:32:03) was a total of 13 seconds.
art_l_j_PlanetAMD64
 
Posts: 472
Joined: Sun May 30, 2010 3:28 pm

Re: #965 FAHControl cannot save config.xml - Linux system

Postby bruce » Wed Jan 23, 2013 7:03 pm

art_l_j_PlanetAMD64 wrote:... was a total of 13 seconds.

That's not uncommon, but it proves nothing.

On many projects the completed WU package is larger, the time spent compressing the data is longer, the speed of the HD may be slower, the filesystem may have the ext4-barriers problem, the 100% roundoff problem may or may not be present, the download may take longer (depending on the speed of the connection and the size of the next WU), etc. Of course that has to be compared to the anticipated frame time between 99% and 100%. I have seen it take as much as 3-5 minutes without the ext4 problem and upwards of 15 minutes to compress the files if you have the ext4 problem.

I maintain that the donor should have the right to choose without us dictating what's right for them.
bruce
 
Posts: 20140
Joined: Thu Nov 29, 2007 11:13 pm
Location: So. Cal.

Re: #965 FAHControl cannot save config.xml - Linux system

Postby art_l_j_PlanetAMD64 » Wed Jan 23, 2013 7:39 pm

bruce wrote:
art_l_j_PlanetAMD64 wrote:... was a total of 13 seconds.

That's not uncommon, but it proves nothing.

On many projects the completed WU package is larger, the time spent compressing the data is longer, the speed of the HD may be slower, the filesystem may have the ext4-barriers problem, the 100% roundoff problem may or may not be present, the download may take longer (depending on the speed of the connection and the size of the next WU), etc. Of course that has to be compared to the anticipated frame time between 99% and 100%. I have seen it take as much as 3-5 minutes without the ext4 problem and upwards of 15 minutes to compress the files if you have the ext4 problem.

I maintain that the donor should have the right to choose without us dictating what's right for them.

Thanks, bruce, for pointing this out. I was not suggesting that it was for everyone, as I said here. Each folder should use the information about their own system's performance, and the factors you mentioned above, to evaluate their choice for the value of next-unit-percentage. I will add a link to this post in the one I linked to just above, so that anyone thinking about using the value of 100 for next-unit-percentage will have a better understanding of the tradeoffs of that decision. Having said that, all 6 of my folding systems here do benefit from having next-unit-percentage set to 100. And (thank you, bollix47!) I did get the ext4 problem fixed on the Linux system that was being slowed down. :)
art_l_j_PlanetAMD64
 
Posts: 472
Joined: Sun May 30, 2010 3:28 pm


Return to V7.2.x -- Windows/Linux Release & OSX Beta

Who is online

Users browsing this forum: No registered users and 1 guest

cron