Page 1 of 3
Instructions for coding new clients?
Posted: Mon Jun 06, 2011 6:26 pm
by wheelguy12
Thought there would be a stickey on this, and scanning the posts didn't see any such animal, so - where can I find instructions that would be useful for creating new client applications? I also looked at the stickey list of current client apps, and none seem to do what I need for my particular situation, so I'm probably going to write a client using C#.
The only things I have been able to gather so far (may be way off base here, but...)
* clients have to use command line arguments to run the cores
* clients have to parse the log files to get current progress of the cores
* clients have to screen scrape the fah web site to get team and user stats
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 6:32 pm
by bruce
The V6 client is closed source and not being developed. Parsing the log files has been the only way to support V6 but it's strongly discouraged, particularly since the V7 client (which is currently in beta) has an interface for developers which will be supported. Please see the
V7 FAHClient Open Beta forum and
the Developers Den forum.
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 6:36 pm
by 7im
Rather than develop a client monitoring program for the older clients, start developing for the new V7 client. And rather than a sticky, there is a whole forum section...
Developer's Den 
The client can run command line arguments, but are not required to. They can also be set in the configuration file.
Parsing the log file is the current way, but not the future way.
Monitoring programs to do not to screen scrape to get user stats. Stat flat files are published. Read more here:
http://folding.stanford.edu/English/Stats
More info on V7:
https://fah-web.stanford.edu/projects/FAHClient/wiki
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 6:56 pm
by wheelguy12
Yep, I looked at both of those forums also - still no info there about monitoring and controlling the cores. Here are the basic steps that I need to control...
1. download work unit(s) for a given core
2. run core on the given work unit
3. upload result(s) for a given work unit/team/member
Are all of these steps controlled from a given core's command line? If not, then how?
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 7:05 pm
by bruce
The FAHClient manages the downloading of WUs and the initiation of the FahCores. This is closed source and protected by the EULA. You should read it. Only clients downloaded from Stanford are allowed to connect to their servers. You may not write a new CLIENT, but you can replace FAHControl (which is open-source) to manage the client provided by Stanford.
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 7:10 pm
by 7im
The fah client handles those tasks. Your monitoring tool cannot.
FYI, the work unit determines the core needed, so you cannot download a work unit for a core. It has to be the other way around.
The user name and team number are specified in the client configuration. The fah client reads those settings, and sends it back with the completed work unit.
And WU download and upload uses encrypted communications to assure data security. No 3rd party tool will ever be allowed to handle downloading and uploading work units.
It may help to be more specific about your progamming goals, so we can point you in the right direction.
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 8:03 pm
by wheelguy12
What I am trying to do is this - download enough work to keep my machine busy while it is disconnected from the Internet. It should do this in an automated manner so that I don't have to manually configure the controller every day (like has to be done in the V7 client UI now).
Can this be done by coding for the V7 client? I noticed that someone else posted exactly this same problem on this forum 2 years ago, so perhaps some way of doing this has been created by now.
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 9:02 pm
by wheelguy12
Finally found a link to instructions for communicating with the V7 client. It sounds like I should be able to do what I need by writing a bit of code to continually create enough "slots" while on line to keep the machine busy while off-line, and just have this little tender app running all the time while V7 is running. Here is the link in case someone else is looking for it...
https://fah-web.stanford.edu/projects/F ... eInterface
Thanks again for all the help - wow, you guys are fast too
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 9:06 pm
by k1wi
Do note that slot loading (did I just coin a new term?) is not advised by PG, because it slows the project down (hence why it is not offered natively). You will need to take into account the deadlines of each work unit and the quick return bonus. You may time out and you will receive fewer points...
Re: Instructions for coding new clients?
Posted: Mon Jun 06, 2011 10:10 pm
by 7im
wheelguy12 is running a GPU client, which finishes a WU every few hours, so he needs 8 or more to keep the card folding all day, because the PC only has wireless via phone a few hours a day.
The reason there is not a good solution for this, is because there is no good solution. Caching of work units goes against the goals of the project. The faster the completed work units come back, the faster the science gets done. If you hold a work unit for 24 hours, then you are holding the next generation of work unit going out for 24 hours instead of just 3 hours. By folding offline, you are adding 21 hours delay to every work unit you fold.
Work units are serial in nature. They are time slices, and holding on to one slice holds up the rest. Caching is something that is not supported nor recommended. Sorry.
That being said, until the project formally prevents such actions, or adds enough points disincentive to stop doing this, it can still be done.
Personally, I would use X number of v6 GPU command line clients. Then run them as scheduled tasks at staggered intervals. Then shut them all down at a certain time that you plan to connect each day. Then run X more scheduled tasks so start each client for 5-10 minutes, in staggered steps. This allows each client upload any completed work, and download the next. Then back to the 3 hour stagger...
Re: Instructions for coding new clients?
Posted: Wed Jun 08, 2011 2:19 am
by wheelguy12
I understand what you mean about the work units being serial in nature. So, in terms of the speed of finishing a single project element, yes - being offline will hold up that project element. Just as a slow machine taking a work unit slows down the other work units behind it. But, for the larger goal of getting more projects done, it is clearly more beneficial to run 24 hours instead of 6. If this is correct, then adding a capability to automatically queue work that can compensate correctly for the speed of the machine, and the patterns of time it is on line would be beneficial to the project as a whole.
I haven't thought of running multiple v6 command line clients. I suppose that as each one finishes, it will patiently wait for connectivity and upload the results followed by a download of the next work unit. No coding needed! That sounds like the solution for me, so I'll give it a try. The last time I fired up 20 slots in the V7 client, my machine had finished them, and was sleeping when I came home. I just need to find some way to prevent thrashing of the clients for attention of the GPU. Suggestions?
Re: Instructions for coding new clients?
Posted: Wed Jun 08, 2011 3:03 am
by bruce
The point is that you're not only delaying one WU, you're planning on delaying a whole bunch of them. Not only does that mean the project runs slower, but that means the project must create extra WUs. If there are N people working on a project, and each of them have work to do, that's an ideal situation. Whenever somebody competes a WU, the server creates a new WU and assigns it to them Since N is not a constant, and can only be estimated, FAH must have K extra WUs sitting on the server so that they don't run out of work, but those extra K WUs also delay the project because nobody is working on them so it's slowed down to N/(N+K).
Now assume that somebody queues up a bunch of WUs and the server runs out of work units to assign. ---> Angry people .... and FAH must increase K, slowing down the project even further.
My suggestion is to create longer WUs. I don't know if it's possible, but let's suppose that you had an option to be assigned WUs from a project that ran for 10 or maybe 100 times as long a simulated time as the present WUs . . . and some method to choose those WUs. Wouldn't that be a significant improvement? It wouldn't be a perfect solution, but from the scientific side of things, it would sure beat the solutions that have been discussed here.
Re: Instructions for coding new clients?
Posted: Wed Jun 08, 2011 5:58 am
by GreyWhiskers
I posted the chart below a few weeks ago after looking in some detail at the seemingly unending series of Nvidia GPU work units in P6801. The design of this project was to have a very wide set of "Runs" (over 10,000 seemingly) that each iterate through an arc of Gens or Time Steps.
My analysis below is speculation, but it may support that it might not be that bad for projects designed like this for some donors to queue up their WU results for a day. With thousands of WUs released for each gen, and a four day cycle, there should be enough time. This is enabled by what I might term a "Wide" design - thousands of Run/clone sets processed in each generation - each time step. The data set below also shows that there are occasional "catch-up" events when the system has proceeded to a subsequent time step, or gen, but has a few WUs out of the Wide arc that didn't get in in time, so are sent out (maybe sent out again if for what ever reason a WU missed its deadline) late.
BTW, as of this moment, P6801 us up to Gen 18. Server 171.64.65.64 has a current backlog of 135,738. I myself have finished at least 615 p6801 WUs in the last 2 1/2 months on my MSI GTX560Ti moderately clocked at 950 MHz.
I traced getting first a couple of days of gen 0, and within that gen, cycling through Clone 1-2-3-4. Within gen 0, clone 1, it iterates through each of the runs. I think that as the results from the, say, 4 clones times 10,000 runs in gen 0 are turned in, that the FAH back end software will generate the work units for gen 1, and load them all up to the servers. It seems that it is taking about four days to cycle through all the WUs for a given gen.
Now, this project 6801 design may be unique, but with what seems like a four day time cycle, it may just support the kind of queuing that wheelguy12 is asking about. But, there are no guarantees in this business.
Anatomy of a series of GPU Work Units from the trenches
Code: Select all
Project Run Clone Gen Download Date
6801 6848 1 0 4/1/2011 14:23
6801 7683 1 0 4/1/2011 16:46
6801 5112 2 0 4/2/2011 0:03
6801 5911 2 0 4/2/2011 2:27
6801 6709 2 0 4/2/2011 4:50
6801 7476 2 0 4/2/2011 7:13
6801 8278 2 0 4/2/2011 9:36
6801 9082 2 0 4/2/2011 11:59
6801 9853 2 0 4/2/2011 14:23
6801 5657 3 0 4/2/2011 16:46
6801 6464 3 0 4/2/2011 19:09
6801 7254 3 0 4/2/2011 21:32
6801 8012 3 0 4/2/2011 23:56
6801 8776 3 0 4/3/2011 2:19
6801 9521 3 0 4/3/2011 4:43
6801 5234 4 0 4/3/2011 7:06
6801 6026 4 0 4/3/2011 9:29
6801 6821 4 0 4/3/2011 11:52
6801 7601 4 0 4/3/2011 14:16
6801 8426 4 0 4/3/2011 16:39
6801 9214 4 0 4/3/2011 19:02
6801 5000 0 1 4/3/2011 21:25
6801 5786 0 1 4/3/2011 23:48
6801 6589 0 1 4/4/2011 2:12
6801 7365 0 1 4/4/2011 4:35
6801 8155 0 1 4/4/2011 6:58
6801 8944 0 1 4/4/2011 9:21
6801 9734 0 1 4/4/2011 11:44
6801 5534 1 1 4/4/2011 14:08
6801 6340 1 1 4/4/2011 16:31
6801 7135 1 1 4/4/2011 18:54
6801 7920 1 1 4/4/2011 21:17
6801 9465 1 1 4/5/2011 2:04
6801 5245 2 1 4/5/2011 4:27
6801 6037 2 1 4/5/2011 6:50
6801 6829 2 1 4/5/2011 9:14
6801 7646 2 1 4/5/2011 11:37
6801 8441 2 1 4/5/2011 14:00
6801 9232 2 1 4/5/2011 16:23
6801 5042 3 1 4/5/2011 18:46
6801 9865 2 1 4/5/2011 21:09
6801 6584 3 1 4/5/2011 23:33
6801 7356 3 1 4/6/2011 1:56
6801 8104 3 1 4/6/2011 4:19
6801 8892 3 1 4/6/2011 6:42
6801 9707 3 1 4/6/2011 9:06
6801 5368 4 1 4/6/2011 11:29
6801 6175 4 1 4/6/2011 13:52
6801 6960 4 1 4/6/2011 16:15
6801 7776 4 1 4/6/2011 18:38
6801 8576 4 1 4/6/2011 21:02
6801 9345 4 1 4/6/2011 23:25
6801 5100 0 2 4/7/2011 1:48
6801 5864 0 2 4/7/2011 4:11
6801 6601 0 2 4/7/2011 6:34
6801 7393 0 2 4/7/2011 8:58
6801 8182 0 2 4/7/2011 11:21
6801 8979 0 2 4/7/2011 13:44
6801 9774 0 2 4/7/2011 16:08
6801 5560 1 2 4/7/2011 18:31
6801 6341 1 2 4/7/2011 20:54
6801 7082 1 2 4/7/2011 23:17
6801 7860 1 2 4/8/2011 1:40
6801 8565 1 2 4/8/2011 3:59
6801 9291 1 2 4/8/2011 6:16
6801 5043 2 2 4/8/2011 8:33
6801 5767 2 2 4/8/2011 10:49
6801 6501 2 2 4/8/2011 13:06
6801 7254 2 2 4/8/2011 15:22
6801 7996 2 2 4/8/2011 17:39
6801 8767 2 2 4/8/2011 19:56
6801 9521 2 2 4/8/2011 22:13
6801 5211 3 2 4/9/2011 0:29
6801 5942 3 2 4/9/2011 2:46
6801 6637 3 2 4/9/2011 5:02
6801 7350 3 2 4/9/2011 7:19
6801 8067 3 2 4/9/2011 9:36
6801 8816 3 2 4/9/2011 11:56
6801 9565 3 2 4/9/2011 14:13
6801 5146 4 2 4/9/2011 16:30
6801 5866 4 2 4/9/2011 18:46
6801 6601 4 2 4/9/2011 21:03
6801 7345 4 2 4/9/2011 23:20
6801 5003 0 3 4/10/2011 7:49
6801 5777 0 3 4/10/2011 10:06
6801 6531 0 3 4/10/2011 12:23
6801 7267 0 3 4/10/2011 14:40
6801 8006 0 3 4/10/2011 16:56
6801 8745 0 3 4/10/2011 19:13
6801 9456 0 3 4/10/2011 21:29
6801 5136 1 3 4/10/2011 23:46
6801 5808 1 3 4/11/2011 2:03
6801 6486 1 3 4/11/2011 4:20
6801 7138 1 3 4/11/2011 6:36
6801 7839 1 3 4/11/2011 8:53
6801 8533 1 3 4/11/2011 11:10
6801 9258 1 3 4/11/2011 13:26
6801 9985 1 3 4/11/2011 15:43
6801 5724 2 3 4/11/2011 18:00
6801 6452 2 3 4/11/2011 20:17
6801 7141 2 3 4/11/2011 22:34
6801 7854 2 3 4/12/2011 0:50
6801 8537 2 3 4/12/2011 3:07
6801 9208 2 3 4/12/2011 5:23
6801 9877 2 3 4/12/2011 7:40
6801 5579 3 3 4/12/2011 9:56
6801 6323 3 3 4/12/2011 12:13
6801 7045 3 3 4/12/2011 14:29
6801 7772 3 3 4/12/2011 16:46
6801 8481 3 3 4/12/2011 19:02
6801 9201 3 3 4/12/2011 21:19
6801 9931 3 3 4/12/2011 23:36
6801 5364 4 3 4/13/2011 1:52
6801 6044 4 3 4/13/2011 4:08
6801 7094 4 3 4/13/2011 7:35
6801 7838 4 3 4/13/2011 9:51
6801 8580 4 3 4/13/2011 12:08
6801 9331 4 3 4/13/2011 14:24
6801 5059 0 4 4/13/2011 16:41
6801 5774 0 4 4/13/2011 18:57
6801 6507 0 4 4/13/2011 21:14
6801 7218 0 4 4/13/2011 23:31
6801 7218 0 4 4/14/2011 0:47
6801 8306 0 4 4/14/2011 3:04
6801 9016 0 4 4/14/2011 5:21
6801 9811 0 4 4/14/2011 7:55
6801 5496 1 4 4/14/2011 10:12
6801 6211 1 4 4/14/2011 12:28
6801 6924 1 4 4/14/2011 14:45
6801 7645 1 4 4/14/2011 17:01
6801 9926 1 4 4/15/2011 0:15
6801 5616 2 4 4/15/2011 2:33
6801 6322 2 4 4/15/2011 4:51
6801 7022 2 4 4/15/2011 7:09
6801 7726 2 4 4/15/2011 9:26
6801 7412 2 5 4/15/2011 11:44
6801 9127 2 4 4/15/2011 14:02
6801 9731 2 4 4/15/2011 16:20
6801 5383 3 4 4/15/2011 18:37
6801 6081 3 4 4/15/2011 20:57
6801 6757 3 4 4/15/2011 23:13
6801 7424 3 4 4/16/2011 1:29
6801 8073 3 4 4/16/2011 3:44
6801 8719 3 4 4/16/2011 6:00
6801 9389 3 4 4/16/2011 8:16
6801 2262 4 4 4/16/2011 10:32
6801 5411 4 4 4/16/2011 12:48
6801 6117 4 4 4/16/2011 15:04
6801 6842 4 4 4/16/2011 17:20
6801 7534 4 4 4/16/2011 19:36
6801 8221 4 4 4/16/2011 21:52
6801 8881 4 4 4/17/2011 0:08
6801 9527 4 4 4/17/2011 2:24
6801 5182 0 5 4/17/2011 4:40
6801 5837 0 5 4/17/2011 6:55
6801 6520 0 5 4/17/2011 9:11
6801 7226 0 5 4/17/2011 11:28
6801 7950 0 5 4/17/2011 13:43
6801 8652 0 5 4/17/2011 16:00
6801 9356 0 5 4/17/2011 18:15
6801 5041 1 5 4/17/2011 20:31
6801 5706 1 5 4/17/2011 22:47
6801 6372 1 5 4/18/2011 1:03
6801 7041 1 5 4/18/2011 3:19
6801 7685 1 5 4/18/2011 5:35
6801 8328 1 5 4/18/2011 7:51
6801 8996 1 5 4/18/2011 10:08
6801 9711 1 5 4/18/2011 12:26
6801 5416 2 5 4/18/2011 14:44
6801 6118 2 5 4/18/2011 17:02
6801 6825 2 5 4/18/2011 19:20
6801 7539 2 5 4/18/2011 21:38
6801 6646 3 5 4/19/2011 11:20
6801 7365 3 5 4/19/2011 13:44
6801 8075 3 5 4/19/2011 16:01
6801 8766 3 5 4/19/2011 18:18
6801 9458 3 5 4/19/2011 20:34
6801 2855 4 5 4/19/2011 22:51
6801 5392 4 5 4/20/2011 1:07
6801 6048 4 5 4/20/2011 3:24
6801 6707 4 5 4/20/2011 5:41
6801 7381 4 5 4/20/2011 7:58
6801 9596 4 5 4/20/2011 15:22
6801 5245 0 6 4/20/2011 17:42
6801 5933 0 6 4/20/2011 19:59
6801 6625 0 6 4/20/2011 22:16
6801 6395 0 7 4/21/2011 0:32
6801 7917 0 6 4/21/2011 2:49
6801 8550 0 6 4/21/2011 5:05
6801 9202 0 6 4/21/2011 7:22
6801 9853 0 6 4/21/2011 9:38
6801 5529 1 6 4/21/2011 11:55
6801 6221 1 6 4/21/2011 14:11
6801 6922 1 6 4/21/2011 16:28
6801 7585 1 6 4/21/2011 18:44
6801 8248 1 6 4/21/2011 21:01
6801 8946 1 6 4/21/2011 23:17
6801 9600 1 6 4/22/2011 1:34
6801 5237 2 6 4/22/2011 3:50
6801 5911 2 6 4/22/2011 6:07
6801 6558 2 6 4/22/2011 8:23
6801 7250 2 6 4/22/2011 10:40
6801 7932 2 6 4/22/2011 12:57
6801 8614 2 6 4/22/2011 15:14
6801 9320 2 6 4/22/2011 17:30
6801 9982 2 6 4/22/2011 19:47
6801 5600 3 6 4/22/2011 22:04
6801 6238 3 6 4/23/2011 0:20
6801 6898 3 6 4/23/2011 2:37
6801 7535 3 6 4/23/2011 4:53
6801 8164 3 6 4/23/2011 7:10
6801 8838 3 6 4/23/2011 9:28
6801 9491 3 6 4/23/2011 11:45
6801 2699 4 6 4/23/2011 14:01
6801 5345 4 6 4/23/2011 16:18
6801 5992 4 6 4/23/2011 18:34
6801 6622 4 6 4/23/2011 20:51
6801 7264 4 6 4/23/2011 23:08
6801 7867 4 6 4/24/2011 1:24
6801 8502 4 6 4/24/2011 3:41
6801 9145 4 6 4/24/2011 5:58
6801 9829 4 6 4/24/2011 8:14
6801 5502 0 7 4/24/2011 10:31
6801 6206 0 7 4/24/2011 12:48
6801 6876 0 7 4/24/2011 15:05
6801 7553 0 7 4/24/2011 17:21
6801 8221 0 7 4/24/2011 19:38
6801 8882 0 7 4/24/2011 21:56
6801 9536 0 7 4/25/2011 0:13
6801 5142 1 7 4/25/2011 2:29
6801 5793 1 7 4/25/2011 4:46
6801 6438 1 7 4/25/2011 7:03
6801 7086 1 7 4/25/2011 9:19
6801 7747 1 7 4/25/2011 11:36
6801 8357 1 7 4/25/2011 13:53
6801 9008 1 7 4/25/2011 16:09
6801 9638 1 7 4/25/2011 18:26
6801 5297 2 7 4/25/2011 20:43
6801 5909 2 7 4/25/2011 23:00
6801 6530 2 7 4/26/2011 1:16
6801 7173 2 7 4/26/2011 3:33
6801 7845 2 7 4/26/2011 6:00
6801 8508 2 7 4/26/2011 8:17
6801 9155 2 7 4/26/2011 10:33
6801 7281 2 7 4/26/2011 12:50
6801 5427 3 7 4/26/2011 15:07
6801 5032 4 7 4/27/2011 9:19
6801 5032 4 8 5/1/2011 7:23
6801 6995 4 8 5/1/2011 9:40
6801 7784 4 8 5/1/2011 11:56
6801 8403 4 8 5/1/2011 14:13
6801 9204 4 8 5/1/2011 16:30
6801 5030 0 9 5/1/2011 18:46
6801 5779 0 9 5/1/2011 21:03
6801 6510 0 9 5/1/2011 23:19
6801 7089 0 9 5/2/2011 1:36
6801 7845 0 9 5/2/2011 3:53
6801 8531 0 9 5/2/2011 6:09
6801 9021 0 9 5/2/2011 8:30
6801 9804 0 9 5/2/2011 10:46
6801 5602 1 9 5/2/2011 13:03
6801 6410 1 9 5/2/2011 15:19
6801 7185 1 9 5/2/2011 17:36
6801 7925 1 9 5/2/2011 19:53
6801 8680 1 9 5/2/2011 22:09
6801 9456 1 9 5/3/2011 0:26
6801 5079 2 9 5/3/2011 2:42
6801 5734 2 9 5/3/2011 4:59
6801 6560 2 9 5/3/2011 7:15
6801 7382 2 9 5/3/2011 9:32
6801 8463 2 9 5/3/2011 12:59
6801 9245 2 9 5/3/2011 15:15
6801 5001 3 9 5/3/2011 17:32
6801 5791 3 9 5/3/2011 19:48
6801 6535 3 9 5/3/2011 22:05
6801 7281 3 9 5/4/2011 0:21
6801 7886 3 9 5/4/2011 2:38
6801 8651 3 9 5/4/2011 4:55
6801 9416 3 9 5/4/2011 7:11
6801 1741 4 9 5/4/2011 9:28
6801 5043 4 9 5/4/2011 11:44
6801 5832 4 9 5/4/2011 14:01
6801 6621 4 9 5/4/2011 16:18
6801 7403 4 9 5/4/2011 18:34
6801 8217 4 9 5/4/2011 20:51
6801 8933 4 9 5/4/2011 23:08
6801 9648 4 9 5/5/2011 1:25
6801 5419 0 10 5/5/2011 3:41
6801 6166 0 10 5/5/2011 5:58
6801 6969 0 10 5/5/2011 8:14
6801 7800 0 10 5/5/2011 10:31
6801 8632 0 10 5/5/2011 12:47
6801 9309 0 10 5/5/2011 15:04
6801 5136 1 10 5/5/2011 17:21
6801 8387 3 8 5/5/2011 19:37
6801 8387 3 9 5/5/2011 21:54
6801 7618 1 10 5/6/2011 0:10
6801 8444 1 10 5/6/2011 2:27
6801 9306 1 10 5/6/2011 4:43
6801 5160 2 10 5/6/2011 7:00
6801 6396 2 10 5/6/2011 10:39
6801 7168 2 10 5/6/2011 12:55
6801 8106 2 10 5/6/2011 15:12
6801 8898 2 10 5/6/2011 17:29
6801 9696 2 10 5/6/2011 19:45
6801 6023 0 9 5/6/2011 22:02
6801 6343 3 10 5/7/2011 0:18
6801 7036 3 10 5/7/2011 2:35
6801 7903 3 10 5/7/2011 4:51
6801 8664 3 10 5/7/2011 7:08
6801 9576 3 10 5/7/2011 9:25
6801 3669 4 10 5/7/2011 11:41
6801 5382 4 10 5/7/2011 13:58
6801 6240 4 10 5/7/2011 16:15
6801 7093 4 10 5/7/2011 18:31
6801 7961 4 10 5/7/2011 20:48
6801 8783 4 10 5/7/2011 23:04
6801 9642 4 10 5/8/2011 1:21
6801 5445 0 11 5/8/2011 3:38
6801 6228 0 11 5/8/2011 5:54
6801 7038 0 11 5/8/2011 8:11
6801 7654 2 9 5/8/2011 10:27
6801 7654 2 10 5/8/2011 12:44
6801 9534 0 11 5/8/2011 15:01
6801 5375 1 11 5/8/2011 17:17
6801 6201 1 11 5/8/2011 19:34
6801 7011 1 11 5/8/2011 21:51
6801 7847 1 11 5/9/2011 0:07
6801 8924 1 11 5/9/2011 3:35
6801 9742 1 11 5/9/2011 5:52
6801 5606 2 11 5/9/2011 8:09
6801 6421 2 11 5/9/2011 10:26
6801 8306 2 11 5/9/2011 16:17
6801 9108 2 11 5/9/2011 18:34
6801 9964 2 11 5/9/2011 20:51
6801 5693 3 11 5/9/2011 23:07
6801 6487 3 11 5/10/2011 1:24
6801 7263 3 11 5/10/2011 3:40
6801 8030 3 11 5/10/2011 5:57
6801 8793 3 11 5/10/2011 8:14
6801 5121 4 11 5/10/2011 15:03
6801 5953 4 11 5/10/2011 17:20
6801 6755 4 11 5/10/2011 19:37
6801 7522 4 11 5/10/2011 21:53
6801 8259 4 11 5/11/2011 0:10
6801 8987 4 11 5/11/2011 2:27
6801 9743 4 11 5/11/2011 4:43
6801 5534 0 12 5/11/2011 7:00
6801 6283 0 12 5/11/2011 9:16
6801 7049 0 12 5/11/2011 11:33
6801 7798 0 12 5/11/2011 13:50
6801 8578 0 12 5/11/2011 16:06
6801 9360 0 12 5/11/2011 18:23
6801 5144 1 12 5/11/2011 20:40
6801 5905 1 12 5/11/2011 22:56
6801 6647 1 12 5/12/2011 1:13
6801 7412 1 12 5/12/2011 3:29
6801 8149 1 12 5/12/2011 5:46
6801 8904 1 12 5/12/2011 8:03
6801 9723 1 12 5/12/2011 10:28
6801 5482 2 12 5/12/2011 12:45
6801 6246 2 12 5/12/2011 15:01
6801 7010 2 12 5/12/2011 17:18
6801 7773 2 12 5/12/2011 19:35
6801 8541 2 12 5/12/2011 21:51
6801 9291 2 12 5/13/2011 0:08
6801 333 3 12 5/13/2011 2:25
6801 5655 3 12 5/13/2011 4:41
6801 6410 3 12 5/13/2011 6:58
6801 7176 3 12 5/13/2011 9:15
6801 7958 3 12 5/13/2011 11:31
6801 8746 3 12 5/13/2011 13:48
6801 9491 3 12 5/13/2011 16:04
Re: Instructions for coding new clients?
Posted: Wed Jun 08, 2011 6:13 am
by 7im
For a quant, you forgot to allow for the human element. Your 4 day cycle only works for wheelguy to cache WUs when all the rest of us continue to NOT cache WUs. If you start promoting that idea again, it blows the speed of the project out of the water when more and more people try to cache WUs. Your analysis falls down at that point.
Re: Instructions for coding new clients?
Posted: Wed Jun 08, 2011 7:47 am
by GreyWhiskers
Thanks, 7im.
re: the topic of caching. I'm spinning possibilities from what I see, absent any definitive info from Stanford on how they REALLY design the projects or what their back end reprocessing of finished WUs into the next gen WUs looks like. I try to avoid the Inductive Fallacy, but I also want to see data to support our premises.
I think there are relatively few folders who want to do heavy work when connected to the net only a couple of hours a day. I wholeheartedly agree that if the whole population of Folders were caching their WUs, the results would be highly skewed. A piece of good news in v7 is the overlapped nature where the client immediately starts processing the next WU at the end of the prior without waiting for the upload will satisfy many who have been pushing for caching WUs.
At the end of the day, do some projects have the resiliency to support a
few "cachers"? I think the discussion 7im and others in this thread have made was helpful for a person whose special circumstances led to a caching solution for these very rapid GPU work units.
Inductive Fallacy
Premise 1: Having just arrived in Ohio, I saw a white squirrel.
Conclusion: All Ohio Squirrels are white.
(While there are many, many squirrels in Ohio, the white ones are very rare).