Idea for increasing F@H power

[Picky88]

I have been folding for a few months now on my core i5 rig and have just hit 500,000 points yay!


It occoured to me that the client should download a new WU before the current one is finished, so that the computer can start on the new WU straight away. This may not make much difference to an individuals points per day, but if all the clients did this then the overall power of the folding@home project would be increased alot for a relatively small amount of time programming to make this change. Also it concerns me slightly that during the download of a new core my temps drop very rapidly and go back up again within a short space of time, which must decrease the life of the components at least slightly. If the new core was already downloaded then this abrupt temp change would happen alot less. Does this idea have any merit?

[7im]

Many people are of the same mind, and this has been suggested before. We'll have to wait and see if this gets added to the v7 client currently in development.

[Picky88]

Good to know. Thanks for your reply.

[uncle fuzzy]

One of the comments used against this idea is that we have to return the Generation X WU as quickly as possible so that the server can turn around and issue Generation X+1.

I have seldom received gen X followed by gen X+1. Notice I said "seldom". It has happened a few times.

That said, I still favor the idea

[codysluder]

Though not precisely on topic, see the reply I just gave here" viewtopic.php?f=20&t=15732&p=156115#p156115

From a total number of WUs completed standpoint, downloading earlier makes a lot of sense. Looking at it from a rapid-return basis it may not. When you measure the time spent working on individual WUs, is it better to delay the previous WU or the upcoming one? Downloading a WU before you are able to start processing adds to the time that it takes for you to complete that upcoming WU. Uploading the previous result first minimizes the time you spend processing that previous WU. It does appear that the present client follows the concept that minimizing the total time working on a specific WU is more important than the number of WUs that you complete and your suggestion stresses the number of WUs matters more than minimizing the schedule.

In fact, both are important. Hopefully, future software will have a reasonable compromise.

[Napoleon]

This is what happened to me quite recently:

Code: Select all

[08:16:02] Loaded queue successfully.
[08:16:02] 
[08:16:02] + Processing work unit
[08:16:02] Core required: FahCore_a3.exe
[08:16:02] Core found.
[08:16:02] - Autosending finished units... [August 21 08:16:02 UTC]
[08:16:02] Trying to send all finished work units
[08:16:02] Project: 6701 (Run 6, Clone 24, Gen 37)


[08:16:02] + Attempting to send results [August 21 08:16:02 UTC]
[08:16:02] - Reading file work/wuresults_02.dat from core
[08:16:02] Working on queue slot 03 [August 21 08:16:02 UTC]
[08:16:02]   (Read 43701802 bytes from disk)
[08:16:02] Connecting to http://171.64.65.56:8080/
[08:16:02] + Working ...
[08:16:02] - Calling '.\FahCore_a3.exe -dir work/ -nice 19 -suffix 03 -np 2 -priority 96 -nocpulock -checkpoint 30 -forceasm -verbose -lifeline 4652 -version 630'

[08:16:02] 
[08:16:02] *------------------------------*
[08:16:02] Folding@Home Gromacs SMP Core
[08:16:02] Version 2.22 (Mar 12, 2010)
[08:16:02] 
[08:16:02] Preparing to commence simulation
[08:16:02] - Ensuring status. Please wait.
[08:16:02] - Couldn't send HTTP request to server
[08:16:02]   (Got status 503)
[08:16:02] + Could not connect to Work Server (results)
[08:16:02]     (171.64.65.56:8080)
[08:16:02] + Retrying using alternative port
[08:16:02] Connecting to http://171.64.65.56:80/
[08:16:03] - Couldn't send HTTP request to server
[08:16:03]   (Got status 503)
[08:16:03] + Could not connect to Work Server (results)
[08:16:03]     (171.64.65.56:80)
[08:16:03] - Error: Could not transmit unit 02 (completed August 20) to work server.
[08:16:03] - 8 failed uploads of this unit.


[08:16:03] + Attempting to send results [August 21 08:16:03 UTC]
[08:16:03] - Reading file work/wuresults_02.dat from core
[08:16:03]   (Read 43701802 bytes from disk)
[08:16:03] Connecting to http://171.67.108.25:8080/
[08:16:03] - Couldn't send HTTP request to server
[08:16:03]   (Got status 503)
[08:16:03] + Could not connect to Work Server (results)
[08:16:03]     (171.67.108.25:8080)
[08:16:03] + Retrying using alternative port
[08:16:03] Connecting to http://171.67.108.25:80/
[08:16:04] - Couldn't send HTTP request to server
[08:16:04]   (Got status 503)
[08:16:04] + Could not connect to Work Server (results)
[08:16:04]     (171.67.108.25:80)
[08:16:04]   Could not transmit unit 02 to Collection server; keeping in queue.
[08:16:04] + Sent 0 of 1 completed units to the server
[08:16:04] - Autosend completed
[08:16:12] - Assembly optimizations manually forced on.
[08:16:12] - Not checking prior termination.
[08:16:12] - Expanded 1762701 -> 2248525 (decompressed 127.5 percent)
[08:16:12] Called DecompressByteArray: compressed_data_size=1762701 data_size=2248525, decompressed_data_size=2248525 diff=0
[08:16:12] - Digital signature verified
[08:16:12] 
[08:16:12] Project: 6076 (Run 0, Clone 190, Gen 79)
[08:16:12] 
[08:16:12] Assembly optimizations on if available.
[08:16:12] Entering M.D.
[08:16:18] Using Gromacs checkpoints
[08:16:19] Resuming from checkpoint
[08:16:19] Verified work/wudata_03.log
[08:16:19] Verified work/wudata_03.trr
[08:16:19] Verified work/wudata_03.edr
[08:16:19] Completed 144386 out of 500000 steps  (28%)
[08:19:07] Completed 145000 out of 500000 steps  (29%)
[08:43:46] Completed 150000 out of 500000 steps  (30%)
[09:08:25] Completed 155000 out of 500000 steps  (31%)
[09:30:48] Completed 160000 out of 500000 steps  (32%)
[09:53:11] Completed 165000 out of 500000 steps  (33%)
[10:15:32] Completed 170000 out of 500000 steps  (34%)
[10:37:56] Completed 175000 out of 500000 steps  (35%)
[11:00:18] Completed 180000 out of 500000 steps  (36%)
[11:22:39] Completed 185000 out of 500000 steps  (37%)
[11:44:58] Completed 190000 out of 500000 steps  (38%)
[12:07:33] Completed 195000 out of 500000 steps  (39%)
[12:29:57] Completed 200000 out of 500000 steps  (40%)
[12:53:09] Completed 205000 out of 500000 steps  (41%)
[13:15:36] Completed 210000 out of 500000 steps  (42%)
[13:37:59] Completed 215000 out of 500000 steps  (43%)
[14:00:48] Completed 220000 out of 500000 steps  (44%)
[14:16:04] - Autosending finished units... [August 21 14:16:04 UTC]
[14:16:04] Trying to send all finished work units
[14:16:04] Project: 6701 (Run 6, Clone 24, Gen 37)


[14:16:04] + Attempting to send results [August 21 14:16:04 UTC]
[14:16:04] - Reading file work/wuresults_02.dat from core
[14:16:04]   (Read 43701802 bytes from disk)
[14:16:04] Connecting to http://171.64.65.56:8080/
[14:23:36] Posted data.
[14:23:36] Initial: 0000; - Uploaded at ~94 kB/s
[14:23:37] - Averaged speed for that direction ~94 kB/s
[14:23:37] + Results successfully sent
[14:23:37] Thank you for your contribution to Folding@Home.
[14:23:37] + Number of Units Completed: 12

[14:23:39] + Sent 1 of 1 completed units to the server
[14:23:39] - Autosend completed
[14:24:33] Completed 225000 out of 500000 steps  (45%)
[14:48:17] Completed 230000 out of 500000 steps  (46%)

This is related to the server problem discussed elsewhere, I believe. My point is, the existing client is able to move on if there's a problem with upload (some servers are down). Notice the resend attempt occurring every 6 hours and how the previously completed WU was finally uploaded succesfully smack in the middle of processing a new one. There is also a neat 3rd party app - Langouste - to ease the pain.

I would be quite surprised (not to mention disappointed) if the upcoming v7 didn't optimize the client's upload/download behaviour. However, it isn't just the client, PG has also the server side to deal with. What goes on in there is a big to me. Still, it looks like certain essential pieces for such an improvement are already built in, just not used to their full potential at the moment, whatever the reason is.

[bruce]

There's no doubt that some changes that reportedly will (or might) be included in v7 will also require changes to the server code. I have little doubt that some of those server changes are slipped in gradually. We have to remember that a change to the server code has to be made very carefully. Not only does the new code have to work with any changes planned for V7, it has to keep working with v4 and v5 and v6. Moreover, real-time fixes to server code can quickly become a disaster. Suppose a bug is introduced which shuts down those currently running a released client. Suddenly FAH has a lot of very angry people.

There already are multiple versions of server code running simultaneously. For example, the GPU servers do not support passkeys. From the donor perspective, that's not a critical feature since the SMP projects with a bonus that does depend on passkeys are the ones that really need them to work -- and they do. All that had to be done to the code on the GPU servers was to make sure that it ignored the passkey if someone happened to have a client version that did report a passkey. Eventually, all pf the servers will support passkeys, of course, but it's a change that could be phased in gradually and is still going on.