View Full Version : Losing work. .dyn file missing
NedClocker@Home
02-03-02, 05:59 PM
The times I have lost work by stoping F@H or re-booting, the log has said that the wudata_??.dyn files is missing. F@H writes this file to the work folder at the end of each frame, I think. Yesterday, only 2/5 boxes had this file. Today, all of them do. Or did. The one that just started a wu doesn't have one yet. Will probably get one when the first frame finishes.
If you want to, y'all check your work folders and see if you have this file and let me know.
If you don't have it, don't stop F@H, or you'll lose your work.
I'm not sure exactly what's happening yet.
Just an observation that I thought I would pass on.
It might help keep you, and therefore, the team, from losing some work.
Oh, yeah. The ?? is the protein number you're working on. Either 00,01,02,03,04,05,06,07,08, or 09.
It is fine unless you are in the middle of a WU. Whenever it atarts a new WU it will say that in the log. It is normal.
NedClocker@Home
02-03-02, 11:41 PM
Exactly. If you're in the middle of a work unit and it can't find that file, you lose all of your work.
Or it could get corupted on shutdown and it wont match up. So having it is not a guarantee that it wont happen. Have you lost any work units lately? I haven't lost one since ver. 2.15 I now run 2.15 on two machines and 2.17 on another.
NedClocker@Home
02-03-02, 11:54 PM
I have 3 on v.2.15 and 2 on v.2.12. It hasn't happened to me since I started looking to see if that file is there before I shut down. If it isn't there, I don't shut it down. It has been a while since it happened.
Have you found it missing on the comps running 2.15? Or just on 2.12? If it is on 2.12 then I would say upgrade to 2.17 and then you don't have to worry about it anymore.
JetMech
02-04-02, 12:54 AM
If I remember correctly people running 2.12 were having problems losing work if they had to shut down for whatever reason. Version 2.15 supposedly corrected this problem. Is it possible that the addition of the .dyn file was the improvement that was added to 2.15 to clear the shutdown problem?
I believe the problem was a coruption of the .dyn that caused the problem and this was fixed in 2.15. I suggested upgrading his 2.12's because of this.
I was not affended I was just clarifying. I am sorry if it was taken that way.
Edit: I was just trying to get the point out that the .dyn file was there the whole time. I just think that something in versions before 2.15 allowed the file to get corrupted when it shut down.
JetMech
02-04-02, 03:02 AM
Originally posted by kendan
I was not affended I was just clarifying. I am sorry if it was taken that way.
Edit: I was just trying to get the point out that the .dyn file was there the whole time. I just think that something in versions before 2.15 allowed the file to get corrupted when it shut down. I'm sorry too. I was just trying to make the point that 2.15 was created to fix the problem.
You are right 2.15 fixed several problems. Hopefully the next ver. will fix the problem many people are having with dialup.
JetMech
02-04-02, 03:20 AM
Originally posted by kendan
You are right 2.15 fixed several problems. Hopefully the next ver. will fix the problem many people are having with dialup. That's another bucket of worms. I'm in the process of putting a Duron 1.2 Folding box together and will set it up for dialup instead of connecting it to the network. I want to see first hand what everyone else is seeing. Eventually I'll network it though.
That sounds good. I believe Vijay stated that they are working on the problem. I have all my computers networked and am not going back to modem if I can help it:D
JetMech
02-04-02, 03:28 AM
It will be a pain here mainly because people want to use the phone so much. I'd have to do things manually. It won't be for long. Maybe a week. Just enough to get an idea of what people are experiencing. It's hard to advise about something we haven't experienced.
Very true. I try to keep up to date by getting the email list and reporting anything interesting I read in it. It is hard to help someone with a problem if you don't have the problem. Vijay has the same problem. He gets all these pointed reports of problems and some he can not duplicate which makes it hard to fix and when it takes a lomg time to fix it they get angry.
JetMech
02-04-02, 03:56 AM
s
I used to be a mechanic and nothing is more frustrating than to recieve a complaint and not be able to duplicate it. In my case I was workin on life support systems on aircraft and you don't send a bird back up saying could not duplicate. You also don't ground an expensive aircraft because you can't find the prob. In my case it was safer and cheaper to replace the reported hardware and let the depot figure it out. In Vijay's case he has to worry about guys quitting the Fold (pun pun).
Yes that is one of his worries. But if you read the posts on the Yahoo group they can get rather nasty and if it was me I would not worry about losing them. The problem lies in the the atmosphere that they create. That to me is his hardest problem to deal with. All the bugs and connection problems will get fixed it just takes a little time. And time to fix it right is not something that some people in our quick fix society just do not want to give. Patience is something that can do everybody some good.
JetMech
02-04-02, 04:43 AM
Exactly. We Folders need to realize that this work that we are doing is cutting edge. The software that we use is being invented on the fly and the best thing that we can do is pay close attention to what we see as bugs and use good troubleshooting logic to give Vijay and his peeps the cleanest most accurate information we can concerning what we are seeing. Yes it gets frustrating when things don't go right, but we are a unigue group. Our machines are running on the edge most of the time because we are trying to squeeze all the WU out that we can. In that effort it is possible that we are part of the problem. If we see a problem there may be things that we can do from our end that might fix it. Maybe a tweak we made is not good for the present form of the software. Maybe we are running too hot (producing beyond stability). We must take note of all these things first so that when we do inform Stanford we do so in a scientific and professional manner. We don't want to be a part of the problem; however helping to find a solution comes with the territory. If we're going to fold we need to understand that there will be problems.
NedClocker
02-05-02, 12:47 AM
Damn, I'm proud to be a part of this group. Well put, JetMech.
Thanks kendan and JetMech for respoding to my post. I'm glad at least 2 people had some interest.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.