The short answer is "yes." However, the results may not be as intended. If you are tempted to try that, please read this first. If you still want to try it, please make a backup of your Folding@Home folder and all files and subfolders before you start so you can go back if it doesn't go well for you.
Thank you, dandelion , for finding the topic for us. :)
Changes in IE settings for IE7 prevent the client from uploading work if the "Use Internet Explorer Settings" parameter is set to yes. You will see this in your log file:
When you get to the "Use Internet Explorer Settings?" question, type no.
Even after correcting this parameter, you may continue to see reports of failed attempts to return work. You may see something similar to this in your console window or fahlog.txt file:
(In this instance, the user has 2 WUs that are unable to be sent.)
In some cases, the WU is actually submitted, but the client is not receiving acknowledgement, so it does not do its normal post-submission cleanup. The client repeatedly attempts to resubmit the same work unit.
If you keep close track of your stats and can verify that you received credit for the FIRST submission, the WU can be deleted (see below). If you aren't sure, post the line like this from your fahlog.txt file (in this format, please)
sortofageek (or any Folding Community Forum moderator) can query the stats database to check on submitted WUs. If she replies that the WU has been successfully received and credited, you can delete the wuresults_xx.dat file, where xx is the unit number referenced in the error messages.
A thread discussing one instance of this issue is here.
When attempts to send the work unit (WU) to the server fail, the program will queue the WU results so that they are not lost. The same problem that caused the upload to fail may also cause the "get work" to fail. If Ctrl+C will not shut down the program, it is safe at this time to use the "x" in the window's upper right corner to close the window or click the upper left corner of the window and select close to stop the program. When the problem is corrected, restart the program and no data will have been lost.
If you know your internet connection is up, have checked and found the problem is not the Stanford servers, try reconfiguring your client for this particular setting:
Use Internet Explorer Settings [no] (yes/no)? If your client is currently configured with a no answer to this question, change that setting to yes and try again. If your client is configured as yes, change to no and retry.
If you notice a work unit does not upload after completion, check the FAHlog.txt file in your F@H folder for an error message like this:
[03:30:41] - Server reports digital signature does not match. [03:30:41] (May be due to corruption during network transmission or a corrupted file.) [03:30:41] - Error: Could not transmit unit 02 (completed May 13). Keeping unit in queue.
The most likely cause is running an older version of the F@H client. If this is the case, download the latest final client. Shut down the client properly just after the end of a completed frame. Place the new client in your F@H folder. Be sure to change the shortcut to point to this new client's executable file. Restart the client. The work unit(s) in the queue should then go home.
If your client will not connect after the upgrade, please see the following FAQs:
LINCS warning followed by an Early WU End message is an indication that progress of a Work Unit was terminated due to Simulation Instability. Following log entries show this message:
[01:20:01] Completed 132000 out of 200000 steps (66) [01:20:05] + Writing 'sec_per_frame = 1050.500000' to config [01:20:05] + Working ...Timered checkpoint triggered. [01:43:59] Quit 101 - Fatal error: [01:43:59] Step 133288, time 266.576 (ps) LINCS WARNING
[01:43:59] relative constraint deviation after LINCS: [01:43:59] max 0.000464 (between atoms 70341 and 70343) rms 0.000007 [01:43:59] [01:43:59] Simulation instability has been encountered. The run has entered a [01:43:59] state from which no further progress can be made. [01:43:59] If you often see other project units terminating early like this [01:43:59] too, you may wish to check the stability of your computer (issues [01:43:59] such as high temperature, overclocking, etc.). [01:43:59] Going to send back what have done. [01:43:59] logfile size: 76172 [01:43:59] - Writing 76858 bytes of core data to disk... [01:43:59] ... Done. [01:43:59] [01:43:59] Folding@home Core Shutdown: EARLY_UNIT_END [01:44:04] CoreStatus = 72 (114) [01:44:04] Sending work to server
[01:44:04] + Attempting to send results [01:44:04] - Reading file work/wuresults_02.dat from core [01:44:04] (Read 76858 bytes from disk) [01:44:09] - Uploaded at ~15 kB/s [01:44:09] - Averaged speed for that direction ~36 kB/s [01:44:09] + Results successfully sent [01:44:09] Thank you for your contribution to Folding@Home.
In this case a WU ended early, however partial results were sent to Stanford for partial credit.
This happens due to bad work units as Larry the weatherman explains this thread: /forum/remark,11699582~mode=flat
+ Attempting to get work packet - Connecting to assignment server - Error: Getwork failed, and no other work to do Sleeping for about x minutes then retrying
Possible problems: •Your Internet connection is down.
•Network congestion on the Internet or at Stanford.
The client will continue to retry until that particular server has been re-started or the assignment server switches you to another available work server after about 20 minutes.
You can, in the meantime, try stopping and re-starting the client several times, maybe more!
There is a trick, from the FAH olden days, that still works for FAH (most of the time) if you have a dynamic WAN IP address: •Shutdown the client.
•Force an WAN IP address change.
•Re-start the client. Again, it may require several shutdowns and re-starts.
+ Attempting to send results - Connecting to server (171.64.122.xxx) - Error: Could not transmit unit xx. Keeping unit in queue.
The client will attempt to transmit a complete WU twice before it moves on and downloads a new work unit for processing. The results will be kept in the work folder until the next time it has to transmit another WU. Once the client completes the WU, it will attempt to send all queued work again! You can force a retry, by stopping and re-starting the client! The client will retry sending the queued work units every six hours. There is more info in this thread.
Possible problems:
•Your Internet connection is down.
•Network congestion on the Internet or at Stanford.
The most likely cause of this, is that the GUI client uses OpenGL and it is not included in some of the older video drivers.
To fix it, you will need to update the drivers for your video card and you may have to update the Microsoft DirectX drivers as well.
Even with the updated drivers applied, other users are still experiencing problems with the GUI client crashing occasionally. Stanford is aware and is looking into what might be causing these crashes.