Slower client available

A new client featuring 200 structures per generation is available for download for all OS's - http://www.blueprint.org/proteinfold..._download.html It is still the same protein and the same algorithm, the only change is the number of generations. Note that this is NOT an auto-update - the client will not download anything automatically. You have to manually download the relevant package and install it, or use the new executable from it. The stats will not be reset or changed in any manner, since there is no change to the protein.

The increased generation size will allow us to get mush better RMSDs on this faster protein, and should also reduce the server load, as the speed will be cut in half. So please make sure to download it.

To ensure you have to right version, running the client with './foldtrajlite -' it should display Distributed Foldtraj v2004.03.24. The Windows client and screensaver should be dated March 25.
Note that if you downloaded the client yesterday (a non-Windows version), it was mistakenly linked to an older version, so please redownload again.

Thank you for your patience and consideration.

Erhm...huh?!

I downloaded it yesterday and I just downloaded it again and both clients say this:

Quote:

---

Distributed Foldtraj vMar 25 2004

---

This is the Windows console client.

I'm sorry, but I getting tired of this - it's really frustrating :(

There is nothing wrong with what you are getting. The Windows client and screensaver were already fine and are indeed dated March 25. The other packages however were linked to an older version, but they are fine now. All packages have 200 structures per generation.

Thank you for pointing this out.

Where to download from? Is this one also available for the beta testers?

I just downloaded the Tru64 version and ran it. Got this:

Distributed Foldtraj v2004.01.12

So it looks like it's the 100 structure version. Running it does only 100 structures per generation.

Shortfinal

The beta client is entirely separate, never had the protein update and has not been changed. If you are beta testing, just keep the beta executable you have.

ahh...the post on your news page doesn't say anything about the fact that the windows clients were fine :(

Chaser: the usual place :)

I'm getting an "object not found" 404 error on your link Stardragon. Do you mind posting the link again as a Hyperlink?

Thanks in advance. ;)

Quote:

---

Originally posted by shortfinal
I just downloaded the Tru64 version and ran it. Got this:

Distributed Foldtraj v2004.01.12

So it looks like it's the 100 structure version. Running it does only 100 structures per generation.

Shortfinal

---

Are you certain you replaced the file? Possibly your browser is caching the old link? This looks the yesterday's wrongly linked version. I just checked the executable and I am getting the new date stamp. foldtrajlite.exe for the Tru64 version should be 7626752 bytes. I had just verified this is the version on the download site.

rstarr:

I accidentally put an extra period at the end of the link. It's fine now. It's just the normal download page.

Stardragon. Download site not currently working. :(

As of 1255 hrs EST, 26 March.

Will the new client receive double points for doing twice as many structures per generation? Early indications are that it does not.

Quote:

---

Originally posted by Stardragon
Are you certain you replaced the file? Possibly your browser is caching the old link? This looks the yesterday's wrongly linked version. I just checked the executable and I am getting the new date stamp. foldtrajlite.exe for the Tru64 version should be 7626752 bytes. I had just verified this is the version on the download site.

---

Thanks, I downloaded it again this time following the link from your initial post and I got the right size and version (Distributed Foldtraj v2004.03.24). When I downloaded it earlier today I followed the link from the homepage.

Shortfinal

Quote:

---

Originally posted by HaloJones
Will the new client receive double points for doing twice as many structures per generation? Early indications are that it does not.

---

Let me get this straight: WITHOUT forcing a client update, you are making available a new client which takes twice as long to accumulate points.

There are participants who are points-happy. What is to prevent them from continuing to run the old client (and receive points twice as fast as with the new client), while those less points-happy run the new client (but receive points only half as fast) ?

mikus

Quote:

---

Originally posted by HaloJones
Will the new client receive double points for doing twice as many structures per generation? Early indications are that it does not.

---

I would like an answer to this as well.

Quote:

---

Originally posted by Anteraan
I would like an answer to this as well.

---

When there were 2 clients running in parallel late last year, the 50 and 100 structure clients, the points were the same for both.

From memory the points are set to the generation submitted, the backend server has no way of identifying whether you had 100 or 200 structures in the process of determining the final result for the generation.

So it will be the same as back then I'm assuming.

Quote:

---

Originally posted by deranged128[OCAU]
When there were 2 clients running in parallel late last year, the 50 and 100 structure clients, the points were the same for both.

From memory the points are set to the generation submitted, the backend server has no way of identifying whether you had 100 or 200 structures in the process of determining the final result for the generation.

So it will be the same as back then I'm assuming.

---

Which of course means there should be an auto update to get everbody on to an equal footing, else where is the incentive to update the client?

Quote:

---

where is the incentive to update the client?

---

1. To unload the servers, giving those people on slow connections a chance to participate.

2. To improve the science being done.

3. Because they (the project admins) asked us to do so.

I really don't see why some people seem to have a problem with this ..... :confused:

Quote:

---

Originally posted by rshepard
1. To unload the servers, giving those people on slow connections a chance to participate.

2. To improve the science being done.

3. Because they (the project admins) asked us to do so.

I really don't see why some people seem to have a problem with this ..... :confused:

---

I'd love to participate because of the science background, but I guess like most of the folders, eventually I'm in it for the stats... :bang:

I would love to improve the science being done, but when my work is rewarded less with the new, improved client, then why should I upgrade :rolleyes: ???

Quote:

---

Originally posted by rshepard
1. To unload the servers, giving those people on slow connections a chance to participate.

2. To improve the science being done.

3. Because they (the project admins) asked us to do so.

I really don't see why some people seem to have a problem with this ..... :confused:

---

Whilst some people are here purely for the science, for others it's an opportunity to amass points and see their chosen team do well in the standings. You can argue as much as you like and quote altruistic motives but these things won't change. The fact that the project benefits from these peoples contributions is a very nice side affect. :rolleyes:

I think if it came to the crunch a lot of the larger contributors are 'stats junkies' and a less points productive client will be unattractive to them.

Erk has it right, to really reduce the load on the servers these new clients need to be put out to everyone, for all OSs. That way you will 'really' halve the load on the database server and keep those who are in it for the stats happy too. The big plus is that Elena has said the 200 structure may give better results. This should be incentive for the DF admin staff to make sure everyone is using it to really get a benefit.

Why not just send out a new autoupdate to everyone then? That sure would settle the eveness about this subject.

The auto update would hammer the Server even more, is that a good thing to do..someone suggested it would be easier just to turn 50% of everones Clients off until a better fix. This would give the bonus of reducing power consumption by 50% also :rotfl:

Quote:

---

Originally posted by Grumpy
The auto update would hammer the Server even more, is that a good thing to do..someone suggested it would be easier just to turn 50% of everones Clients off until a better fix. This would give the bonus of reducing power consumption by 50% also :rotfl:

---

Just done that. The Active users (working on current protein): 2,252 is a fair bit lower than some previous proteins, so it must be the Mhz wars that are driving the load up.

Quote:

---

Originally posted by Grumpy
The auto update would hammer the Server even more, is that a good thing to do..someone suggested it would be easier just to turn 50% of everones Clients off until a better fix. This would give the bonus of reducing power consumption by 50% also :rotfl:

---

They are going to have to come to grips with that scenario whether it's an updated client that everyone gets now or the next protein update, presumably with client modifcations also.

When the medicine has to be taken, you may as well get it over and done with. They change everyone to the newer clients now, give the usual grace period for stuff uploaded using the old client, then despite the hurt that will occur during changeover, they can set a new target for this protein and keep everything at a reduced pace thereafter.

Why prolong the agony? :stretcher :whip: :bang: :spank: :bonk:

Give us double the points for the new client.. and then release it as a new client and give people 96 hours to switch to the new one and we should be able to force through uploading all the currently produced data..

Quote:

---

Give us double the points for the new client

---

You are assuming that there is some identifier in the result which indicates the difference between this new client and the original... Remember that the server is accepting data from either, so it may think they are one and the same.

Ned;)

Why not make it yourself (DF) simple? Just call out a clientupdate on friday 10 a.m.?
That way everyone has time to get the clientupdate and everyone is in the same page of credit for flushing work. Now most people won't update because while science is important so is their output, and the ones who won't update have an advantage. No sad fafes that way

Looking at my proposal i think 3 groups will like this.
1: DF because of the decrease of serverstress and the increase of good results
2 & 3 are Ars Technice and Free DC because that way we'll have to hunt you down for sometime longer

Quote:

---

Originally posted by Ned
You are assuming that there is some identifier in the result which indicates the difference between this new client and the original... Remember that the server is accepting data from either, so it may think they are one and the same.

Ned;)

---

You are right Ned. Look half way up page one and I posted on the topic and recollected what happened late last year.

The receving server has no way of identifying how many structures went into a piece of submitted work. It knows what generation number it is (to allocate points which are preset) and identify who it came from.

There weren't double points last time so I imagine there won't be this time until such time as the client is universal and the backend has been modified accordingly.

So people can ask away but most people should realise that nothing can be done while 2 clients are running at the same time.

I think they should give away free beer to those who update :cheers:

If this is not possible just enforce an autoupdate on Tuesday:spank:

As some of you have already figured out, there is not stats difference between the two clients. You will still get credited for generations made, and there is no way for the server to detect the difference between generation sizes.

The reason this was not an auto-update was to ensure that the servers didn't have to deal with ever a greater load with everyone uploading thousands of buffered results for numerous days. Keep in mind that the auto-update would also cause us to essentially "lose" the work done on this protein in the sense that it would have to be restarted from scratch.

There is equal incentive for everyone to download the new client - it will speed up your uploads (resulting in actual points, not just buffered structures), and will generate better results (you could be on the top 10 RMSD chart...).

I appreaciate all the suggestions, but in the meantime encourage everyone to download the slower version of the client.

:bang:

I generally try to stay supportive of the project and it's leaders, but that seems like a really shortsighted architecture design. Come on guys, wtf?

Because I'm in this for the stats I am very tempted to reinstall the previos version. 50% less points for the same amount of work is not attractive.

I would not have this issue if everyone had to upgrade. It would also have made the situation better - allthough we would have had a temporary worsening of the situation. That would have been acceptable.

heretic

Quote:

---

Originally posted by Stardragon
You will still get credited for generations made, and there is no way for the server to detect the difference between generation sizes.

[..]

I appreaciate all the suggestions, but in the meantime encourage everyone to download the slower version of the client.

---

The DF client uploads 2 files and some hash for each gen. The first file (fileup2 in the http-request) is the logfile. The amount of generated structures is noted in this file:

Foldtraj vJan 12 2004 log report
Trajectory File: .\protein_68.....# Generated: 100 ...etc

It seems to me that this information can be extracted very fast, although it is compressed with bz2.

Quote:

---

Originally posted by Stardragon
<snip>

The reason this was not an auto-update was to ensure that the servers didn't have to deal with ever a greater load with everyone uploading thousands of buffered results for numerous days. Keep in mind that the auto-update would also cause us to essentially "lose" the work done on this protein in the sense that it would have to be restarted from scratch.

There is equal incentive for everyone to download the new client - it will speed up your uploads (resulting in actual points, not just buffered structures), and will generate better results (you could be on the top 10 RMSD chart...).

I appreaciate all the suggestions, but in the meantime encourage everyone to download the slower version of the client.

---

I'd probably argue here that the scenario of people uploading thousands of generations from buffered work is something you are going to have to tackle sooner or later. At some stage you are going to want to change to the next protein and the same scenario you've described above will need to be negotiated.

I'd also argue that 'better uploads' will only be possible if everyone is using the newer client. By my guesstimate, you'd get less than 10% of all users changing over to the newer client. This is for a number of reasons:

1. People with large farms rely on the autoupdate process to update their machines. They either don't want to or perhaps don't have immediate access to a number of machines where they will need to stop the client, change the client and then start it up again.

2. Those people who set it and forget. They don't read these forums nor do they regularly visit the news page on the main site. They may or may not get emails when the protein is about to update.

3. Those who are in it for the points/competition. They want the best possible yield for the machines they have available and no amount of appealing to them will change that.

Back onto the subject of uploads being made easier. While so many are still using the older client, the problem will remain. The only difference for those with the newer client is that it will be even slower than expected as the database server will still need to cope with the production from the older client.

In summary I'd say Grumpy's call to do an auto update is probably spot on. Get the hard part over and done with, reset the target to 10 thousand million for a slower client and yield possibly better results from the greater number of structures completed per generation.

My $0.22 (incl GST) worth. :idea:

Quote:

---

Originally posted by Stardragon
There is equal incentive for everyone to download the new client - it will speed up your uploads (resulting in actual points, not just buffered structures), and will generate better results (you could be on the top 10 RMSD chart...).

---

I believe by now all the power users have shifted over to running TWO threads - one *runs* (using -i f) while the other *uploads* (using -u t). That way, the running thread is *not* impacted by the horrible waits for uploads.

Quote:

---

Originally posted by Stardragon
I appreaciate all the suggestions, but in the meantime encourage everyone to download the slower version of the client.

---

Judging by the amount of connect time (I'm a dial-up user) it takes to upload my filesets, even if some participants are now using the slower client, my experience of uploading CONTINUES TO BE intolerably slow.

The new client has not solved the slow upload problem for me. All it is doing is giving me HALF the points I could otherwise be getting. Frankly, I'm feeling that I'm a "sucker" for having switched to the slower client.
.

My .02 cents here is that it's time to just force the client change. I Have 17 boxes at home I *was* running on DF. However the uploading just has reached the intolerable state for me. If it takes 3 days to get all new clients downloaded, then get over it and just do it. Otherwise, daily, you are losing more crunchers, and worse yet, some of them won't return because they are getting quite fed up with the lack of consideration for their time, effort, and money (electric bills) they are ****donating**** to this project. Level the playing field and get everyone back on an even keel and get some common sense back into this project.

Hmm, according to our logs about 1600 people downloaded the Mar. 26 client so I guess some people care about things other than stats. Further, the server load problem seems to have resolved itself - mostly likely thanks to the 1600 people who went ahead and sacrificed a few points to ensure everything would work smoothly again, and those people have our thanks.

I don't dispute that our database is likely poorly configured - it should indeed be able to handle thousands of transactions per second with no trouble. Unfortunately we are lacking any real database optimization knowledge and do not have access to a DBA of any sort, so we have to make do with what little we know for now..