Readme

[Brian the Fist]

Well as usual, when something decides to break, everything goes at once. While the new ticketing system is working fine (we think) it was overshadowed by a bigger problem yesterday - namely one of the partitions on all the web nodes got full. As a result, it was still accepting old proteins (the 58 length) and sticking them happily into the database, and telling people with the new protein that it was the wrong one. This wreaks all sorts of havoc and so it was simplest to wipe the database of uploads which was only a day old now and start over fresh.

Needless to say we have cleared plenty of space on the web nodes and now they will be inserting proper protein versions only. Since we reset the protein we will reset the 24 hr full points credit period as well starting right about now. In most cases your work has been buffered and will be processed eventually and accepted.

It seems there is a lot of confusion about how the new ticketing system works, so we will try to post some more useful information in the FAQ on the website next week. Do NOT edit the receipt.txt (why are people trying to edit this already, you've barely had 24 hrs to tinker with it...). Editing it will accomplish absolutely nothing and likely result in you uploading duplicate work.

The program will presently upload one result at a time and not upload more until the first has been validated. This is v1.0 of the ticketing system. We will make changes to accomodate sneaker net, etc. as you give us constructive suggestions. We will not listen to any suggestions until you have used it for at LEAST one week though, so you have a real idea of how everything works and fits together.

We think everything should be working now (other than some unavoidable 910 errors). We'll keep an eye on things over the weekend too.

[guru]

Thanks for the update.

How's the load on the server with the new ticketing system in place?

guru

[erk]

Thanks for the heads up.
When will the servers start accepting uploads again?

[FoBoT]

[HaloJones]

I realise that I am going to sound hypocritical. I have been vocal about how the 24 hour grace period should never be extended and that the usefulness of the structures after a changeover is limited but...

24 hours isn't going to help all the buffered structures sitting on shut down PCs at my office given that it is now 2140 here.

Oh well, think of the science not the stats.

[Fozzie]

Halo my old friend, it sucks when that happens does it not.

As you say think of the science.

[Anteraan]

Ok, so I muster up the courage to attempt an upload on one of my machines, get the new protein fine, but am having major problems uploading my buffered gens. I'm not getting any error codes (yay!), but on my first upload attempt, I got one gen through, and then the client backed out on the second one and restarted. I tried twice more to upload, and each time the client gave me the "verifying status of previous upload" message for about 10 seconds, then went right back to folding.

This is because the server is blitzed right now, I take it? Assuming the server stays blitzed for the next 24 hours due to backlogs all over the world, is there any chance I will get my gens uploaded before even the half credit deadline is reached?

[playbl162]

Let's discuss this like I only have a sixth grade education.
I haven't uploaded any data since yesterday. I am currently running the new download (131) though. My cache has a collection of both proteins.

Is there anything I can do to send up the data?

If it doesn't go up before what time(est) do I lose the data?

Is this wait and see and lots of us have this problem?

Any answers would be appreciated.
Many thanks.

[pfb]

Originally posted by playbl162
Let's discuss this like I only have a sixth grade education.
I haven't uploaded any data since yesterday. I am currently running the new download (131) though. My cache has a collection of both proteins.

Is there anything I can do to send up the data?

If it doesn't go up before what time(est) do I lose the data?

Is this wait and see and lots of us have this problem?

Any answers would be appreciated.
Many thanks.

Same here - I have a mixture of 58 and 131 to upload and no errors being logged...how can I upload and retain the points gained for the 58 protein from a day/2 days ago?

[bwkaz]

The 131AA protein should not be affected by the 24-hour upload period (since it's the new protein and all). The results you'll need to upload within the next 24 hours are the ones from the 58AA protein.

I think, anyway. I don't see how a grace period would apply to the 131AA protein, anyway. Actually it might make sense for those of us that are using the 131AA protein to run nonet for a day to allow the rest of you with backlogged 58AA results to get them in. I'm switching my two machines over to nonet now...

[Welnic]

As far as uploading the old files, I got that to work by putting all of the data in a separate folder with the old foldtrajlite, removing the autoupdate.cfg file, and then running ./foldtrajlite -n native -f protein -ut (\ for windows). You then get asked if you want to update, hit n, and even though on my linux box I couldn't see anything happen it started uploading. I have no idea if that worked or not, the data did leave my machine though. If you don't have a copy of the old client I think that you are out of luck.

To upload the new data you need to run with the -purgeuploadfilelist xxx switch, where xxx is the number of generations. You need to run that until all of the old files are gone, then start on the new ones.

Or you can just do a fresh install of the client and blow that data off. There are also other distributed computing projects.

[bluumi]

Sorry, but i don't see any need to upload my old data...
Hey folks... it's over ... now let us crunch on the 131 Protein...
Delete you 58aa data.. i did it... on 40 Pcs .. and i did'nt cry. :-)

It's all for scince ... NOT FOR STATS !!

[guru]

The work has already been done. Everyone should get credit for it.

Do you work for free?

guru

[willy1]

It's all for science ... NOT FOR STATS !!

:bs: :bs: :bs: :bs: :bs: :bs: :bs: :bs:

[bluumi]

Originally posted by guru
Do you work for free?

No, i don't work "for free" .. but i don't get Money for it. It's my hobby... and nobody should say that a hobby not cost some time and money...

Now the Problem is solved (i hope) ...

I don't need ANY credit for that work... i'm happy if i now get my credits. I make millions of work... what should i say, this was penuts :-)...

If they reset my stats from year's.. oki... but dont cry like babys if you lost work from 1-2 days

Never try to upload your buffers in the last day...

[Jeff]

Hate to say but I don't think your problems are gone. I've tried installing the new client in a new directory a few times today and the most I've gotten lucky to upload is 5 generations. Right now one of my machines is on it's 34th and it has 29 buffered.

[pfb]

Seeing something similar - it'll upload 1 or 2 gens then just buffer (due to previous uploads not being confirmed? who knows...) - maybe the ticket servers are slow and takes some time for them to confirm if an upload occurred correctly...

[mighty]

Originally posted by bluumi
Sorry, but i don't see any need to upload my old data...
Hey folks... it's over ... now let us crunch on the 131 Protein...
Delete you 58aa data.. i did it... on 40 Pcs .. and i did'nt cry. :-)

It's all for scince ... NOT FOR STATS !!

That's the spirit!

My first observation with the new ticketing system:
At present it seems like the backend-servers are not validating our work (at least not my work) - hence the receipt.txt. There are probably all kinds of reasons for this, but having watched my clients, it seems rather CPU-efficient: When a generation is done, it spends 2 or 3 seconds checking the status of the previous upload and then continues when that check fails.

To me this is much better than the situation around easter where you had timeouts galore in your error.log. In those days we weren't talking seconds of checking - rather minutes.

Obviously I'd like to see some of my new generations validated and accepted, but I'm confident this will happen eventually.

/Mighty

[guru]

If you can't upload work it's not for stats or for science. If I was just in it for stats then I'd still be doing RC5!

guru

[mighty]

Originally posted by guru
If you can't upload work it's not for stats or for science. If I was just in it for stats then I'd still be doing RC5!

guru

I'm doing valid science albeit locally for the moment. It will be uploaded and validated eventually.
That's exactly what this new ticketing system is promoting: Reduced local idle-times while waiting for server issues to be solved.

/Mighty

[guru]

That is if you don't get an error and have to wipe it out also.

My point is if you did the work you should be able to turn it in. :|punch|:

guru

[rstarr]

Scratches head and goes back to watching TV...

[Welnic]

Even if it is only for the science the data has to get uploaded for it to matter. There are about 25 computers in my company that I have folding running on. I usually don't muck around with them when people are actually using them, so I got to about half of them early this morning. I threw away all of the data and started over. Then the restart this afternoon means that I have to do that all over again.

As far as I can tell the new client would not under any circumstances upload data from the old client. In that case it should have just thrown that data away. Every client buffered some data while the server was down during the changeover, that happens every time. But in this case not a single client made it through the changeover without having to be dealt with. To me that sucks.

As I write this I have two proteins in the top ten. One made it through 4 generations, one through two before their careers were cut short. Looking at my personal farm stats (12 2000-2500XPs) I have run 244 generations since I reset them this afternoon. Of those I have 182 generations buffered.

It's just that this is the worst change over yet, I think that is a bad trend.

[FoBoT]

i have a crap load of points, so something must be working right

[Welnic]

On the other hand, there have been no complaints about how slow this protein is and how unfair the scoring is.

[FoBoT]

<shhhhh!>

it doesn't look that slow, it just seems to get stuck quite a bit
it will zip through many strucs. then get stuck on one for a while before moving on

maybe i have just been watching it too much

[Grumpy]

SO HOW THE HELL DO THOSE OF US WITH BOXEN BEHIND A NAT ROUTER DO ANYTHING



With the Beta I had no issues, now none of my Boxen can Upload, the DF Server cannot see them

Well, all Boxen are now DEAD..let me know when the wheel is invented

[bwkaz]

Originally posted by Grumpy
SO HOW THE HELL DO THOSE OF US WITH BOXEN BEHIND A NAT ROUTER DO ANYTHING

I'm doing nothing (except I cleared out all the old 58AA buffered gens), and it works.



Well, I should say, I'm buffering a few gens (9 on my 800MHz system, 20-some on my AXP 2500+), but they are getting uploaded. Nothing in error.log (no 910s, no 908s) anymore, either. Receipt.txt's timestamp is very close to the first <handle>* file's timestamp.

[FoBoT]

i am not seeing a difference between boxen behind NAT's and those directly connected

i am getting points on the new protein on each update from boxen at work, there are two groups

1 group is behind a commercial NAT router on cable
the other group is behind a Mandrake linux router box on DSL

Howard didn't comment on the NAT issue, so i assume he doesn't think it is a problem

i dunno man, lets sleep on it and check things in the morning

[tpdooley]

After the 3rd clean out of the directory in the last few days.. my home system which is behind a Router that uses NAT has no errors in the error.log and is working on gen 83 with 69 gens buffered. So they're getting through - when they can.

[Grumpy]

OK, will do the old delete and restart AGAIN for the 3rd time 2day

Thanks all

[Stardragon]

Grumpy:
Your NAT should not have any effect on being able to connect and upload. If you are still having an issue with it, and believe the NAT router is the cause, please e-mail us the details to trades@mshri.on.ca and we will gladly take a closer look.