Open Letter

[Mikus]

To the Distributed Folding administrators:


I do __not__ understand why updates are under "time pressure". Let us say that the purpose of the project is to find out how (well/poorly) certain software runs. You can determine this from the filesets that the software reports back to you. For the purpose of accumulating / analyzing these reports, does it REALLY matter whether a participant's reports started coming back on Thursday, or on the following Monday ?

My conjecture is that the reason for "time pressure" is a high-minded attempt to be "fair" to all the project participants -- it appears you want to minimize that time interval during which different participants are running different software versions (particularly if the different versions award "points" differently).

It seemed to me the way the betas were introduced -- you announced the availability of the new software, and left it up to each individual to decide WHEN to download that new software -- worked quite well.

--------


I propose formally putting the following question to a VOTE of *all* the DF participants :


Are you in favor of "spreading out" the occurrence of an update, rather than "bunching together" when everybody's downloads occur ? (A "yes" vote would mean that some participants would still be running the old software, while others would already have downloaded and started running the new software.)


--------

If the consensus of the DF community were that "spreading out" would be acceptable, I suggest the principal software change would be to have the server(s) limit the number of "simultaneous" downloads -- as long as that threshold (which could be quite low) was exceeded, the server(s) would respond negatively to an incoming "Checking for new versions" handshake.

What I have in mind is that the "full credit" overlap period between the old and the new software ought to be much more than 24 hours. That would reduce the "time pressure" I've felt with recent updates.


mikus

[Galuvian]

I don't post on this board very often, but I have to say that there is more whining here on a patch day than the whining when they patch Everquest.

[DocWardo]

Mikus
you have to remember that once the protien/executable is changed the server (IIRC) can no longer record the work units uploaded by previous version of the client. most likely this is to avoid contamination between different runs. So the moment the flip the switch they no longer collect usefull science. they allow 48 hours for people to get credit for work they are doing, although that work doens't do anythign for the project. so in essence they are being more than fair by just allowing you to do anything past the time of the change over!

Besides we didnt' even have a switchover today. and for most of hte switchovers we have had I have had no problem with autoupdating and the like. I just leave my computers (winxp, win2k, linux) with the client running the way it wants and was designed to be (connected to the net 24/7).

[Anteraan]

Doc,

Does this mean that generations run under the first beta client could not be uploaded after the update occurs? Well, I mean they can be uploaded, but if doing so provides no help (from a scientific standpoint) to the project, it sounds as if we should make every effort to upload prior to the changeover, correct? Or, are the first and second beta similar enough that this isn't an issue in this case?

[Mikus]

Originally posted by DocWardo
Mikus
you have to remember that once the protien/executable is changed the server (IIRC) can no longer record the work units uploaded by previous version of the client. most likely this is to avoid contamination between different runs. So the moment the flip the switch they no longer collect usefull science. they allow 48 hours for people to get credit for work they are doing, although that work doens't do anythign for the project. so in essence they are being more than fair by just allowing you to do anything past the time of the change over!

I mentioned the recent betas. As far as I can tell, the server *was* able to record both the work units uploaded by the normal client *and* the work units uploaded by the beta client.

I don't know, but it is possible that the servers *can* "record the work units uploaded by previous version of the client". How else is the credit calculated for 'previous' work that is submitted in the 48 hours after "flip the switch" -- surely not by hand?

I agree "the moment they flip the switch they no longer collect useful science" from the old work. What I'm arguing for is that "reducing time pressure" for participants to complete the changeover is *equally* worthy a goal. There are participants who have to dial-in to perform an update. There are participants who have a deadline to leave the premises (sometimes for days).

mikus

[pointwood]

This has been discussed before. Previously you couldn't upload your structures after a changeover at all.

There are good reasons for this and a search in this forum will probably give you the answer

[tpdooley]

I once gave the suggestion that the updates be rolled out over the course of several days to small numbers of people at a time - and remain password protected until The Changeover. But even that approach probably wouldn't help - even if there was a passworded compression option on all the different platforms. How long does it take to crack a compressed file's password?