Folding Forum

GreyWhiskers wrote: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).

How would you enforce a limit to allow 'a few cachers'? How to determine who is eligible and who is not?

In short: I don't think this will work.

On another note, I am working on an alternative for FAHControl, just got sidetracked the last two weeks waiting for my test results for my autism diagnosis. Guess what, came back positive who would have guessed Getting back on track, which is why I came to browse the forums and catch up again, depending on what I aim for I can release an alternative relatively quick, but reading about coming changes in FAHClient ( log splitting ) makes me hesitant as my tracking is/will be ( not finished ) based on log parsing and not only the output from the remote interface ( as per remote interface, I don't get all info I would like ( last frame completion time ).

I love reading so much great detailed info as 7, GW, and Bruce have provided. Gives some insight into how things work.

From an end user's perspective, though, so long as I see that the project deadline is on the order of 3 days, and I know that I will connect each day at a minimum, I am going to believe that I am doing no harm by queuing work. May be an over simplified way to think about it, but I think it is also accurate, and allows FAH to specify what each projects requirements are (by following the project deadline # of days count).

I still think that the above mechanism for handling partly connected clients could be refined and automated within the FAH client code. Adding such a feature should include a high visibility note to the user such as : "You have 31,322 points waiting. Please connect to the Internet to upload results and claim your points."

But, there is your flaw.

Points are awarded when you turn them in, your counter would display a countdown not a fixed value ( the amount of points you will be assigned is based on when you return the completed work unit ).

Look, I understand your reasoning, but the QRB has been conceived to make clear once and for all the serial nature of work units and the scientific value Quick Return's have, which is why there is a Bonus attached to doing such as quick as possible. The project made a turn towards this, what you're proposing is to focus attention not on the quick return but to increase the possible user base by allowing partially connected people to contribute ( with a change in schematics, not just with pointing them to the very long deadline work unit's which are passed to the classic client ). Don't you see you're asking them to work against their other initiative?

That's not to say your idea has no merit, allot of people will want to contribute with hardware which isn't always connected. And, pointing people to the classic clients isn't entirely 100% the right thing either, yes the deadline is longer but you're still introducing delays when you say it's ok to upload a completed wu a considerable time after it's been completed. Extrapolating that to gpu clients, it would be the same as saying you can download a work unit and return it just before the deadline... and guess what, other then that you will get no bonus, you can.

What you can not do is queue unit's, as explained before the project is very serial in nature and it doesn't fit within the way the projects work.

Isn't asking to allow queuing actually the same as asking to return deadline-less work units

As you point out, the client only has an estimate of points that will be awarded prior to download, so including the phrase "estimated points" in the UI makes sense.

I don't know about all of the different type of work units, but as 7 pointed out, I am using the GPU client which finishes work in an hour or two and does not participate in the bonus point system. I'm assuming that work which is assigned to the GPUs mean what they say in terms of # of days needed to return results - which seems to always be 3 or more days.

This is why I think it would benefit the Folding project to include queuing logic inside of the V7 client : So that the client can determine what type of work units should be requested, and how many - so that it can maximize the amount of science that is done in the correct time frame. In addition to knowing what work units are available and what their requirements are, the V7 client also knows when the machine is connected, how often it is running, and how fast it is folding. So, for example, it would not request QRB work units if it is using a GPU or if it is only Internet connected every other day. In addition, a user setting could be added to the UI so that the user can turn off queuing - when they go on vacation, for example.

wheelguy12 wrote:...So, for example, it would not request QRB work units if it is using a GPU or if it is only Internet connected every other day....

This is unrealistic. You're assiming the present state of affairs is static and tha the V7 client somehow knows which WUs have a QRB.

The QRB is a temporary test of a bonus plan. It's not a static thing. It was added for two reasons, to provide an extra award for those who turn in WUs promptly and to provide a disinentive to those who find ways to cache WUs contrary to Dr. Pande's explicit recommendations NOT to cache WUs because of the damage it does to the science.

The QRB started with the SMP WUs and is gradually being extended to the Uniprocessor WUs. It has not yet been applied to GPU WUs, but I suspect that it will be someday. At the present time there's a lot of discussion going on about the limitations of the points and bonus systems. Nobody can really predict what will happen.

What kind of incentive would work for people like yourself if the goal is to have you keep your system connected to the internet whenever a WU might finish and NOT to cache WUs? Obviously saying "...in the interests of science..." isn't working.

wheelguy12 wrote:As you point out, the client only has an estimate of points that will be awarded prior to download, so including the phrase "estimated points" in the UI makes sense.

Huh? There is a fixed value, base points, there is no estimate as FAH doesn't track statistics tied to hardware, so it can't predict the run time of the work unit assigned to you.

wheelguy12 wrote:I don't know about all of the different type of work units, but as 7 pointed out, I am using the GPU client which finishes work in an hour or two and does not participate in the bonus point system. I'm assuming that work which is assigned to the GPUs mean what they say in terms of # of days needed to return results - which seems to always be 3 or more days.

This is why I think it would benefit the Folding project to include queuing logic inside of the V7 client : So that the client can determine what type of work units should be requested, and how many - so that it can maximize the amount of science that is done in the correct time frame. In addition to knowing what work units are available and what their requirements are, the V7 client also knows when the machine is connected, how often it is running, and how fast it is folding. So, for example, it would not request QRB work units if it is using a GPU or if it is only Internet connected every other day. In addition, a user setting could be added to the UI so that the user can turn off queuing - when they go on vacation, for example.

You're attributing allot of logic to the FAHClient executable there, logic it might have in the sense that a> not connected, can't download a new wu... b>connected so I download a new wu, but what you're describing is a layer on top which stores that information and make deductive assessments based on it.

The client does not know what units are available, it just connects to an assignment server which does have the knowledge but doesn't share it with the client, it just assigns it a work unit.

Allowing end users to decide on when to queue or not is asking for troubles, if there is a current mix of wu's which yield higher then average points people would abuse the queue system to hog as many as possible.

If PandeGroup ever decides to bring back deadline-less work unit's, then and only then will a a system where queuing is allowed be beneficial. As long as there are no deadline-less work unit's, we should assume the scientific value of all unit's are focused on their quick return to Stanford and this can not be mixed with queuing work unit's. I don't know what else to say to explain it, but it just doesn't make sense to allow it in any other scenario unless PG decides there are projects which are less reliant on speedy returns.

<philosophy alert>
If a work unit has a deadline of 3 days, then returning the results within that deadline is in the interest of the science, is it not? If it takes 1 hour because I am connected, or if it takes 18 hours because I'm not connected is exactly equivalent to it taking 1 hour because I have a fast machine, or taking 18 hours because I'm using my slow laptop, correct?

So - what is the proper thing to do? Tell everyone who has a slow machine, or intermittent internet, to not take a work unit because it slows down the work units behind it? I think PG has exactly the opposite intention - allow everyone to contribute as much as they want to. Yes? If so, then queuing work is what fits for my situation, and that of others in the past as well.
</philosophy alert>

Your not the first person to try to justify their actions which are contradictory to Pande Groups desires. The fact remains Pande Group has stated they prefer fast WU returns over more WUs returned. Nothing you say is going to change that.

Please read the PM I sent you the other day.

We can just agree to disagree as to what the desires of PG are. For me - it'll remain "fold as much as you want within the given timelines" unless somebody says something that makes better sense of this.

There is a difference between what is recommended, and what is permissable. Between was it optimal for the science (fast WUs), and what is optimal for wheelguy's points (many WUs).

Currently, wheelguy can cache WUs because there is nothing that specifically prevents him from doing so, and there is no incentive to do otherwise. But we all know that when the QRB is soon brought to the GPU client like all the other clients, the incentive will change for the better. Hopefully the GPU WUs will also grow in size so that wheelguy's points are not impacted that much when QRB for GPU is rolled out.

wheelguy12 wrote:<philosophy alert>
If a work unit has a deadline of 3 days, then returning the results within that deadline is in the interest of the science, is it not? If it takes 1 hour because I am connected, or if it takes 18 hours because I'm not connected is exactly equivalent to it taking 1 hour because I have a fast machine, or taking 18 hours because I'm using my slow laptop, correct?

So - what is the proper thing to do? Tell everyone who has a slow machine, or intermittent internet, to not take a work unit because it slows down the work units behind it? I think PG has exactly the opposite intention - allow everyone to contribute as much as they want to. Yes? If so, then queuing work is what fits for my situation, and that of others in the past as well.
</philosophy alert>

The flaw in that logic is that even if one slow machine does slow down folding compared to if there had been a fast machine available, but it doesn't hog 18 WUs while it's doing it.

You don't have a slow machine, so pretending that you have 18 slow machines is much worse than either having a fast machine or having a slow machine. Maybe an overnight delay of the one WU assigned to you cannot be avoided, but each one of the other 17 WUs might have been finished much more rapidly if they had remained on the server for somebody else to fold,

One more thing to consider, the fast machine has a choice to run fast or not. The slow machine does not. As Mr. Anderson would say, the problem is choice.

So - what is the proper thing to do? Tell everyone who has a slow machine, or intermittent internet, to not take a work unit because it slows down the work units behind it? I think PG has exactly the opposite intention - allow everyone to contribute as much as they want to. Yes? If so, then queuing work is what fits for my situation, and that of others in the past as well.

The second concept is NOT the exact opposite of the first concept.

As for what PG tells people, they offer recommendations, and then they let the donor decide how to contribute. They put soft limits on some things, and hard limits on others. And where possible, the offer incentives to help the project move in the right direction. They set points values and bonus point values to aid with those incentives. For example, the faster you return an SMP work unit, the more points you get. This is a clear indication that returning a work unit quickly is a big concern, so they reward you for faster returns. Of course, the slower the return the few points the WU is worth.

This time-sensitive reward system has not come to the GPU client yet, and hopefully soon it will. But again, the intention is clear. Faster is better.

I am not trying to talk you out of caching work units. I want to make clear the impact that caching of work units has on the project. After that, the decision is yours. As they say, All donations are welcomed.

I'm trying to turn this into a constructive discussion, but you didn't answer my question.

bruce wrote:What kind of incentive would work for people like yourself if the goal is to have you keep your system connected to the internet whenever a WU might finish and NOT to cache WUs? Obviously saying "...in the interests of science..." isn't working.

Thank you for the explanation guys. Ya'll have gone above and beyond the call of duty in explaining the current system, the needs of the project, and future direction and reasons for it. Above all, thanks for keeping the conversation constructive!

Bruce - no incentive to stay connected will work for me, because I am partly connected, and will stay only partly connected because doing otherwise costs me over $20 per month; which is a significant expense from my standpoint. Given that I have a fast machine and once daily 6 hour connectivity, I'm trying to figure out how best to serve PG projects. Leaving my machine turned off for 18 hours each day doesn't make sense when I look at the required time frames that I have seen - so... we've been through all that.

Thanks again, and I'll continue reading the forum and trying to figure out how to do things better within my constraints. I'm sure many things will change slowly over time, so it is best to keep current when changes happen.

You could try to figure out which client would be most likely to take X hours to complete a WU- X being some multiple of 24. That way the WU would download while you're connected, run while disconnected, and be ready to ul/dl while again connected.

I'd suggest looking into the bigger CPU WUs. Some of the old ones would take a week to run, even on fairly new hardware. I'm not sure what's out there now.