Folding Forum

Posted: **Wed Mar 10, 2021 4:18 pm**

One think about the timeout: there's an active development project to see how it can be optimized.

You want your work to be valuable to science. That's a good goal. You want your system to produce as much science as it can. That's also a good goal. You want to minimize your costs. Obviously that's also a good goal.

Everybody who tries to accomplish those goals simultaneously is at risk of achieving them at a cost to the projects. The (mostly unwritten) goal of FAH is to get things done as fast as possible. Your goals tend to thwart FAH's goal. For FAH to accomplish it's goal, it's going to be working against your third goal. FAH is better off if you spend more money.

Now back to your individual case and how the deadline works. When you receive a WU that exceeds the deadline, FAH assumes the WU is lost and reasigns it to someone else. You'll get points, but your work will be "wasted" because two people will end up having to do the work. You won't have any indication when that starts happening unless you really look but by running 4 threads on your CPU, you did figure it out.

FACTS: Slow hardware does, in fact, slow down projects by increasing the average completion rate. The next GEN of any trajectory is issued but only after the first person to complete that WU returns it. FAH does award generous bonuses for rapid completion of WUs. By shortening the timeout, they intentionally waste a certain amount of duplicated work by short circuiting the slowest hardware that's slowing down active projects. It's an active tradeoff that's theirs to manage.

What can FAH do to encourage you to finish fewer WUs more rapidly... to do your share to DECREASE the average turn-around-time? That's not one of your goals, but they'd like to add it to your list.

Posted: **Wed Mar 10, 2021 4:21 pm**

In this case the OP has a couple of GPUs that are borderline capable of completing within expiration in their current setup ... It may be that this can be improved by working on the setup and pcie configuration (and other options) and that is where I think it is at at the moment ... Currently the AS logic makes it hard to truely support cards that are effectively near end of usefullness from a FaH perspective - but I am sure someone will be looking into this ... it might be that the mobo will actually support one board much better faster than two - one faster gpu better than two borderline? ... just don't like the idea of blacklisting servers at any time unless asked to by the fah team/researcher - and not sure it is really appropriate even in this case - but hey that is just my view

Posted: **Wed Mar 10, 2021 4:40 pm**

Neil-B wrote:Please note blacklisting of servers shouldn't be the "go to" solution for resolving assignment issues ...

Indeed. The solution should be to catch this before the project goes out of beta status so that underpowered cards don't get these work units, but I understand that it's not always possible to catch these problems with the rapid turn-around and vast variance of GPUs out there. When WUs don't make expiry and timeout, I'm more concerned about the wasted energy and CO2 for zero benefit to humanity than about the folder's points (which are essentially worthless except as an indirect representation of the contribution to science).

Neil-B wrote:It may be that this can be improved by working on the setup and pcie configuration (and other options) and that is where I think it is at at the moment ...

It would be great if we could figure out a way for the folding rig to work better, but unfortunately there might be other less sophisticated users out there using the same cards, so the real solution here lies in project set-up and assigment I believe. If that means completely blacklisting the cards, then that's better than assigning work that never gets returned (expiriy) or is always duplicated (timeout).

Posted: **Wed Mar 10, 2021 4:52 pm**

.. and I'd agree - blacklisting the cards if necessary may well be the way forward ... lars gpu stats show that some are completing within expiration (but doesn't as far as I am aware show how many arent't) ... and without checking the project timeouts/expirations it does feel as if none will be being completed within timeout (I will check properly in a bit) ... Under old regime (limited compute resources with too much work to process) then not completing within timeout was less of an issue (tbh timeouts were set far less aggresively) but in the here and now this is a judgement call for the FaH consortium - whilst two deadlines still exist then the implicit understanding has to be that any wu returned before the second expiration deadline is still welcome and is still adding to the overall progress of science - and so if the OP can get the gpus returning most/all wus even just a smidge inside that expiration deadline then by the way FaH has set the rules/process the OP is assisting FaH deliver its aims.

Just checked the lars listing ... only one shows on current list and that is the 13440 ... the average wu time being so far past the expiration I am going to say the data appears to be tainted

... whilst these gpus do have the same number of shading units as some gpus I know sneak in there is something about their speed that means they dont seem to be getting even close?

Posted: **Wed Mar 10, 2021 5:13 pm**

Neil-B wrote:Please note blacklisting of servers shouldn't be the "go to" solution for resolving assignment issues ... ... People who use this approach to shape their points production are cheating the fah system and intent of the eula ... therefore recommending the same action (even if for good reason) before the powers that be have a chance to sort the assignment server is basically suggesting people do something that will mean they look like "cheats" ... The traces of this type of activity will no doubt be able to be spotted in server logs and if it becomes "popular" may well have to be addressed by some form of remedial action? ... if that happens and innocent users have been being advised to do this type of thing in the forums they may well feel somewhat hard done by !!

Agreed. In today's environment, those who use it have only their self-interest in mind, they're not interested in the overall scientific interests of FAH.

A better approach is to have the Servers do it intentionally and scientifically. The FAH servers have access to a wealth of data that you do not. They hope to be able to optimize all assignments. but it's a formidable challenge and it's taking longer that anybody expected to do take.

Fast hardware needs to be given work that challenges their capabilities and slower hardware needs to be given assignments that make good use of their contributions, too without wasting FAH's resources on unnecessary duplication.

Posted: **Wed Mar 10, 2021 5:21 pm**

LAR doesn't give a full image since it's opt-in only, but it should give a pretty good indication of performance for the common cards.

Neil-B wrote:.. and I'd agree - blacklisting the cards if necessary may well be the way forward ... lars gpu stats show that some are completing within expiration (but doesn't as far as I am aware show how many arent't) ... and without checking the project timeouts/expirations it does feel as if none will be being completed within timeout (I will check properly in a bit)

There's still active GPU projects studying Covid (non-Moonshot) and other proteins like myosins and cancer related proteins. They seem to have a 2 day timeout, and 3 or 5 day expiry. If the cards can make the timeouts on those, then it might still make sense to allow them to fold, but keep them out of projects where they'll consistently fail timeout (or even expiry). If they never make timeout on any project, then they shouldn't be in FAH.

Posted: **Wed Mar 10, 2021 5:27 pm**

gunnarre wrote:If they never make timeout on any project, then they shouldn't be in FAH.

This statement might apply if timeout was based on benchmarks for the device, but Development is experimenting with adjustable timeouts that are set by the server rather than by the project owner. Let's let Development continue to optimize what they can optimize. It's still up to the Donor to not over-commit the CPUs that are supporting the GPUs.

Posted: **Wed Mar 10, 2021 5:43 pm**

Neil-B wrote:Just checked the lars listing ... only one shows on current list and that is the 13440 ... the average wu time being so far past the expiration I am going to say the data appears to be tainted

According to the data on LAR, the FirePro W2100 has successfully returned WUs within timeout on projects 14904 and 14905 (Covid-19, timeout=2) and 17703 (Parkinsons), but fails to return on time for 13440. Why 13440 even shows up in the data on LAR seems strange, as you say, since it shows a completion time well after expiry when the WU should have been dumped as expired.

Screenshot: https://i.imgur.com/eLfhg0l.png (I'm not sure what the timeout for the Myosin project is, since I can't find the annoucement for it.)

Posted: **Wed Mar 10, 2021 5:50 pm**

Rofl ... I couldn't find either of those projects on the project summaries I was looking at or on the project links iin lar - my bad must be going mad

gunnarre wrote:If they never make timeout on any project, then they shouldn't be in FAH.

I wish it were that easy ... say we have someone who doesn't know anything about setting up kit, runs a card and says "this card cant make timeout" - OK blacklist it ... unfortunately someone else has tuned their system and actually always makes timeout with same card because it is setup correctly on kit that allows the gpu to work at its max ... it isn't just the gpu that limits whether the gpu can complete within timeout.

I get you view about timeout ... but that isn't what the fah process actually is set up to support/state ... the existence of an expiry deadline means timeout is simply like cause "a preference" ... if the fah consortia and researchers want to they can change the way it all works but for now any card/setup that can consistently meet the expiry deadline is welcome - sorry, but that is the way fah processing and rewards are setup.

My concern (if I actually have one) might be that If timeout becomes the new expiration then fine - ban people/kit on their track record of meeting timeout - watch a whole load of people with fast/wide cards fall of the resource list because they shut down fah in a hurry without finishing their wu and didn't restart their systems until after the weekend ... what percentage failure might be acceptable ... hard rules and tight deadlines are funny things and can have unintended consequences?

Or some researcher needs really quick responses and sets deliberately a timeout that can only be met by top 30 series cards - hey they can set the rules (at least at the moment) ... suddenly pretty much every card starts getting dumped for being to slow

... OK so ludicrous example I know but there is a reason why (at least in the past) there were two deadlines not one.

Posted: **Wed Mar 10, 2021 6:26 pm**

Let's treat this as a problem specifically for project 13440. As was already stated, any assignment that can meet the expiration is considered valid. Some are costly to FAH for as long as a slow GPU hogs the initial WU because FAH's original goals were to maximize the overall efficiency by avoiding duplication whenever possible. i.e.- only assign one copy until the timeout. The timeout shouid be based on a reasonable expectation of average return cycle time.

FAH has moved further an further toward fixed kfactor/timeout/expiration/etc. and avoiding benchmarking. Server-adjustable timeouts are being evaluated. This has a cost in WU duplication. None of this can be managed by individual donors EXCEPT if they've misconfigured their kit. (see above)

The owner of project 13440 can see what's happening and can manage it himself. He can use whatever happens as input for his project as well as data for future AI of project management software.

Posted: **Wed Mar 10, 2021 6:59 pm**

Neil-B wrote:Rofl ... I couldn't find either of those projects on the project summaries I was looking at or on the project links iin lar - my bad must be going mad

gunnarre wrote:If they never make timeout on any project, then they shouldn't be in FAH.
Or some researcher needs really quick responses and sets deliberately a timeout that can only be met by top 30 series cards - hey they can set the rules (at least at the moment) ... suddenly pretty much every card starts getting dumped for being to slow ... OK so ludicrous example I know but there is a reason why (at least in the past) there were two deadlines not one.

Another way of say that is the timeouts and expiration times should be reasonable for the range of hardware that a project gets assigned to.

I don't see any active blacklisting of GPUs going on. If you're intent is to spread FUD, please don't do it here. FAH's goal is to use all hardware efficiently.

Any researcher can restrict the assignments of his own project(s) in a variety of ways. Reasonable configurations are going to be more successful than unreasonable server configurations. For GPUs, this is generally managed by GPU-Species and there are planned enhancements to that setup. They just haven't been seen in the public domain. For CPUs, assignments can require specific ranges of thread counts or specific amounts of RAM. Most project owners choose reasonable defaults and make corrections if necessary. Most of those corrections happen before a project reaches beta so you don't see them.

Posted: **Wed Mar 10, 2021 7:53 pm**

bruce wrote:I don't see any active blacklisting of GPUs going on. If you're intent is to spread FUD, please don't do it here. FAH's goal is to use all hardware efficiently.

I don't think that's what Neil-B tried to say. He's describing what what would happen if the researcher sets a very low timeout and expiration (like hours instead of days).

Anyway, it seems that the GPU species system that's in place now only lets AMD GPUs be either on or off, and the researcher or assignment server can't differentiate between them. That is, until the new ways of doing assignment are introduced at some time in the future.

Posted: **Wed Mar 10, 2021 8:04 pm**

gunnarre wrote:Anyway, it seems that the GPU species system that's in place now only lets AMD GPUs be either on or off, and the researcher or assignment server can't differentiate between them. That is, until the new ways of doing assignment are introduced at some time in the future.

I see 'species' numbers in the white/black list. I know for instance that AMD 'Navi' GPUs only get Core_22 WUs, not Core_21 WUs due to compatibility issues. The 'problem' with the current species categorization is that it is by function, not performance. It knows what features a GPU has but not how fast it performs them, so a Nvidia GT 1030 is the same species as a GTX 1080ti as they both are the same generation, just not the same performance.

bruce is hoping for a species categorization that takes performance into account. This would better let F@H cope with older GPUs, and help big powerful GPUs not get dinky proteins to model.

I hope they can figure out a way to gracefully add that without breaking current code.

Posted: **Wed Mar 10, 2021 9:18 pm**

bruce wrote:
Neil-B wrote:Rofl ... I couldn't find either of those projects on the project summaries I was looking at or on the project links iin lar - my bad must be going mad

gunnarre wrote:If they never make timeout on any project, then they shouldn't be in FAH.
Or some researcher needs really quick responses and sets deliberately a timeout that can only be met by top 30 series cards - hey they can set the rules (at least at the moment) ... suddenly pretty much every card starts getting dumped for being to slow ... OK so ludicrous example I know but there is a reason why (at least in the past) there were two deadlines not one.
Another way of say that is the timeouts and expiration times should be reasonable for the range of hardware that a project gets assigned to.

I don't see any active blacklisting of GPUs going on. If you're intent is to spread FUD, please don't do it here. FAH's goal is to use all hardware efficiently.

Any researcher can restrict the assignments of his own project(s) in a variety of ways. Reasonable configurations are going to be more successful than unreasonable server configurations. For GPUs, this is generally managed by GPU-Species and there are planned enhancements to that setup. They just haven't been seen in the public domain. For CPUs, assignments can require specific ranges of thread counts or specific amounts of RAM. Most project owners choose reasonable defaults and make corrections if necessary. Most of those corrections happen before a project reaches beta so you don't see them.

Sorry bruce but you got the wrong end of the stick ... So I'll make it clear ... I was making a point that FaH accepts all contributions within the deadline and values those !!

There was no FUD - I wasn't saying that is what happens - I was making the point that implementing a view that if kit cant make timeout then it shouldn't be allowed to fold just won't work and isn't what FaH is about - or at least that is what the process and rules indicate.

But hey if you want to miss interpret the point I was making absolutely fine ... I'll save you the effort of banning me from the forums - which I have tried very hard to support ... I'll let someone else challenge the view that only the fastest is best ... Bye.

Posted: **Thu Mar 11, 2021 1:32 am**

All, it looks like I've kicked off some good discussion. Thanks for all the replies. I'll post some thoughts below:

1. I am not in any way trying to cheat - I've already stated I don't care about points, just want to be doing useful work for science. Continuously producing expired WUs isn't doing useful work, it's just using electricity.
2. There was some discussion about slow GPUs hogging WUs and delaying projects getting done. I haven't messed with overclocking these cards yet, but if I could get these cards to reliably turn in projects, but say I snuck in just under the deadline every time, are you saying that this would be a net negative for F@H? I would think this would be the case if there is a huge shortage of WUs, but if there are enough WUs to go around, I would think even slow (but unexpired) returns would be valuable. Are you saying that people with slower hardware should not contribute even if they can turn in useful work? I would be surprised if this was the position of F@H, but if it is, I guess let me know.
3. I agree that the best course of action would be to have the servers/projects more intelligently assign WUs so that hardware has a good chance at completing it. If that's not the case yet (which is fine), then the blacklisting seems like it may be a good option for my specific situation. I do see how it could be used to cheat the system if you blacklist all but the highest awarding servers. I would hope people would not be looking to do that. As I said, my goal is just to use my hardware to do useful work.

That being said, here is the list of servers....

Code: Select all

Project      Server IP                  Atoms  Timeout(d) Deadline(d)   Base Credit Core               Contact
13438 	18.188.125.154 	89,709 	1.00 	2.00 	54,400 	OPENMM_22 	john.chodera
13439 	18.188.125.154 	4,082 	1.00 	2.00 	2,100 	OPENMM_22 	john.chodera
13440 	18.188.125.154 	89,709 	1.00 	2.00 	54,400 	OPENMM_22 	john.chodera
13444 	18.188.125.154 	89,709 	1.00 	2.00 	54,400 	OPENMM_22 	john.chodera
13445 	18.188.125.154 	4,082 	1.00 	2.00 	2,100 	OPENMM_22 	john.chodera
13821 	128.252.203.9 	        194,401 	5.00 	7.00 	1,000 	GRO_A7 	        jrporter
13822 	128.252.203.9 	        194,401 	5.00 	7.00 	900 	        GRO_A7 	        jrporter
13823 	128.252.203.9 	        194,401 	5.00 	7.00 	900 	        GRO_A7 	        jrporter
13831 	128.252.203.9 	        194,420 	5.00 	7.00 	900 	        GRO_A7 	        jrporter
14188 	155.247.166.219 	127,200 	15.00 	20.00 	5,500 	GRO_A7 	        shahlo.solieva
14821 	155.247.164.214 	55,560 	2.30 	4.90 	740 	        GRO_A7 	        voelz
14822 	155.247.164.214 	55,625 	2.30 	4.90 	780 	        GRO_A7 	        voelz
14825 	155.247.164.214 	55,625 	2.30 	4.90 	725 	        GRO_A7 	        voelz
14827 	155.247.164.214 	55,625 	2.30 	4.90 	725 	        GRO_A7 	        voelz
14828 	155.247.164.214 	55,625 	2.30 	4.90 	725 	        GRO_A7 	        voelz
14852 	155.247.164.214 	55,560 	2.30 	4.90 	747 	        GRO_A7 	        voelz
16451 	66.170.111.50 	        29,571 	1.50 	7.00 	450 	        GRO_A7 	        sukrit.singh
16519 	143.89.243.111 	208,512 	2.00 	4.00 	5,220 	GRO_A8 	        khyik
16520 	143.89.243.111 	208,201 	2.00 	4.00 	5,220 	GRO_A8 	        khyik
16812 	178.174.196.138 	63,000 	1.22 	4.20 	2,660 	GRO_A8 	        sergiopc
16814 	130.237.11.145 	64,366 	2.40 	4.20 	3,010 	GRO_A8 	        sergiopc
16815 	178.174.196.138 	63,000 	0.15 	4.20 	2,660 	GRO_A8 	        sergiopc
16927 	129.32.209.201 	127,200 	1.36 	20.00 	1,360 	GRO_A7 	        shahlo.solieva
16935 	129.32.209.204 	17,368 	3.00 	5.00 	3,600 	GRO_A8 	        tim.marshall
16943 	129.32.209.203 	23,400 	4.20 	4.20 	19,225 	GRO_A8 	        sizhang
16944 	129.32.209.203 	23,400 	3.71 	4.20 	19,275 	GRO_A8 	        sizhang
16945 	129.32.209.203 	23,400 	3.99 	4.20 	19,913 	GRO_A8 	        sizhang
16946 	129.32.209.203 	23,400 	4.20 	4.20 	19,313 	GRO_A8 	        sizhang
16947 	129.32.209.203 	23,400 	4.20 	4.20 	19,763 	GRO_A8 	        sizhang
16948 	129.32.209.203 	23,400 	3.40 	4.20 	19,613 	GRO_A8 	        sizhang
16949 	129.32.209.203 	23,400 	4.20 	4.20 	19,713 	GRO_A8 	        sizhang
16950 	129.32.209.203 	23,400 	3.83 	4.20 	19,983 	GRO_A8 	        sizhang
16951 	129.32.209.203 	23,400 	3.00 	4.20 	20,023 	GRO_A8 	        sizhang
16952 	129.32.209.203 	23,400 	3.19 	4.20 	19,713 	GRO_A8 	        sizhang
16953 	129.32.209.203 	23,400 	3.34 	4.20 	19,525 	GRO_A8 	        sizhang
16954 	129.32.209.203 	23,400 	3.19 	4.20 	19,475 	GRO_A8 	        sizhang
16956 	129.32.209.200 	12,100 	2.00 	4.80 	43 	        GRO_A8 	        voelz
16959 	129.32.209.205 	56,064 	3.00 	5.00 	3,000 	GRO_A8 	        voelz
17220 	206.223.170.146 	707,654 	2.00 	7.00 	4,410 	GRO_A7 	        vithanin
17221 	128.252.203.11 	142,184 	1.00 	3.00 	3,600 	GRO_A7 	        vithanin
17222 	128.252.203.11 	142,277 	1.20 	3.00 	3,600 	GRO_A7 	        vithanin
17223 	128.252.203.11 	142,238 	1.20 	3.00 	3,670 	GRO_A7 	        vithanin
17225 	128.252.203.2 	        116,317 	1.50 	3.00 	693 	        GRO_A7 	        vithanin
17231 	206.223.170.146 	707,654 	2.00 	7.00 	3,310 	GRO_A7 	        vithanin
17329 	140.163.4.200 	        312,033 	2.00 	3.00 	56,395 	OPENMM_22 	ivy.zhang
17330 	140.163.4.200 	        257,386 	2.00 	3.00 	34,828 	OPENMM_22 	ivy.zhang
17331 	140.163.4.200 	        244,411 	2.00 	3.00 	31,560 	OPENMM_22 	ivy.zhang
17332 	140.163.4.200 	        257,388 	2.00 	3.00 	34,168 	OPENMM_22 	ivy.zhang
17333 	140.163.4.200 	        257,382 	2.00 	3.00 	34,611 	OPENMM_22 	ivy.zhang
17334 	140.163.4.200 	        257,392 	2.00 	3.00 	34,695 	OPENMM_22 	ivy.zhang
17335 	140.163.4.200 	        257,383 	2.00 	3.00 	34,879 	OPENMM_22 	ivy.zhang
17407 	66.170.111.50 	        165,477 	1.00 	2.00 	1,230 	GRO_A7 	ameller
17408 	66.170.111.50 	        165,452 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17409 	66.170.111.50 	        149,426 	1.00 	2.00 	1,075 	GRO_A7 	ameller
17410 	66.170.111.50 	        165,416 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17411 	66.170.111.50 	        165,406 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17412 	66.170.111.50 	        165,402 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17413 	66.170.111.50 	        165,385 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17414 	66.170.111.50 	        165,406 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17415 	66.170.111.50 	        165,402 	1.00 	2.00 	1,250 	GRO_A7 	ameller
17422 	128.252.203.9 	        168,886 	1.00 	3.00 	1,100 	GRO_A7 	ameller
17423 	128.252.203.9 	        171,962 	1.00 	3.00 	1,250 	GRO_A7 	ameller
17428 	128.252.203.9 	        168,729 	2.00 	5.00 	866 	        GRO_A7 	ameller
17430 	128.252.203.9 	        171,971 	1.00 	5.00 	970 	        GRO_A7 	ameller
17433 	206.223.170.146 	272,122 	2.00 	5.00 	47,000 	OPENMM_22 	ameller
17434 	206.223.170.146 	196,647 	2.00 	5.00 	25,000 	OPENMM_22 	ameller
17435 	206.223.170.146 	288,449 	2.00 	5.00 	56,000 	OPENMM_22 	ameller
17725 	128.174.73.74 	        85,162 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17726 	128.174.73.74 	        84,262 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17727 	128.174.73.74 	        81,196 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17728 	128.174.73.74 	        76,376 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17729 	128.174.73.74 	        121,449 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17730 	128.174.73.74 	        118,949 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17731 	128.174.73.74 	        81,327 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17732 	128.174.73.74 	        79,607 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17733 	128.174.73.74 	        105,835 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17734 	128.174.73.74 	        104,275 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17735 	128.174.73.74 	        107,863 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17736 	128.174.73.74 	        106,183 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17737  	128.174.73.74 	        51,029 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17738 	128.174.73.74 	        49,809 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17739 	128.174.73.74 	        47,577 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17741 	128.174.73.74 	        116,298 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17742 	128.174.73.74 	        115,098 	1.50 	3.00 	11,000 	OPENMM_22 	mc26
17800 	140.163.4.210 	        22,500 	1.85 	2.00 	12,940 	OPENMM_22 	rafal.wiewiora
17801 	140.163.4.210 	        22,500 	0.86 	2.00 	23,310 	OPENMM_22 	rafal.wiewiora
17802 	140.163.4.210 	        22,500 	0.54 	2.00 	23,310 	OPENMM_22 	rafal.wiewiora
17900 	128.174.73.74 	        19,732 	2.40 	4.20 	825 	        GRO_A8 	        pdb3

And if I were to blacklist servers, I would choose those associated with the following projects: 13438, 13440, 13444, 17329-17335, 17433-17435, 17729, 177230, 17733-17736, 17741, and 17742. I purposefully left some with favorable atom#/deadline ratios in - for example, if my GPUs can ALMOST do an 89,709 WU from Project 13438 in 2 days, they should be able to do a Project 17725 85,162 atom WU in 3 days. I'm not sure if I'm thinking about this the right way - there is probably a lot more that goes into it than that. But this is my thinking at the moment. Once I get to overclocking a bit (this sounds like it'll be a pain with FirePro cards, but I'd like to see what I can do as the cards are not running hot), I'd remove the ban on several more reasonable WU servers. And I guess I'd need to keep an eye on the server list if new ones get added.

What do you guys think of the above plan? And another point on cheating - it looks like my above plan basically cuts out all of the high base point WUs, haha.

Thanks!

EDIT: And to any devs reading this (if that happens), I'm more than willing to help out with testing the capability of the W2100 GPUs.

EDIT2: Well, I'm a dummy. I can't really pick and choose projects like that using server blacklisting because a lot of them are coming from the same server. So, I guess I could blacklist 18.188.125.154, 140.163.4.200, and 206.223.170.146, and hope that 128.174.73.74 and 140.163.4.210 have some stuff for me. Even the 128.174.73.74 has some projects that would be cutting it close for me, but I'm not sure if I want to depend on always having work from only 140.163.4.210? Thanks.

Folding Forum

WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)

Re: WUs Expiring (Slow GPU)