• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

I hate these P610_tetP30_build_ext

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

AmigoThree

Member
Joined
Aug 12, 2002
Location
Gettysburg, PA
It keeps giving them to my 1ghz athlon which is slow enough already but for some reason, the one it gave me recently said that it won't finish for like 2 weeks. Now that is BS. All the others of the same kind have folded fine.

So I wanna know if there is a way to get rid of this one and get a new one, or better yet, make sure I never get them. I think they are a waste of time becuase I fold the P20x's so much faster and I wish I could get all those....
 
I have three machines at home, all folding 610s for the past couple days. Same thing over and over, even the one running Gromacs. I realize there aren't any Gromacs projects at the moment, but this sure is a slow WU. As far as getting rid of one, I imagine you could reinstall. This would get you a fresh WU, but lose the frames from work in progress. I am going to focus on piecing together another machine out of unwanted parts, this time a K62-266. I'll take every point I can get. I can feel the living room getting cozier with every machine!
 
Yea nm I found the problem, my stupid brother left a UT2k3 game running all day and he wasnt even playing it. LOL
 
Is there a way to find out how close a project is to completion? After several days of chewing on the same WUs I'd like to see something different. On my main box (xp@1563) it takes about 16hrs/Wu. Not a lot of points for so many cpu cycles :confused:

I'm just folding for the cause, but I have to wonder about the point system when 610's are 7pts@16hrs and pAla7-2's are 10@4hrs (P4 box).
 
Hmm, are you using windows or linux?

Of course, people like EMIII. I personally like

tail FAHlog.txt

It outputs the last five lines in the FAHlog.txt file, which is the log file for folding. (in C:\program files\folding@home\)

An example:


c:\Program Files\Folding@Home>tail FAHlog.txt
[04:34:47] portions Copyright (c) Michael Shirts 2001
[04:34:47] portions Copyright (c) Vijay S Pande 2001
[04:43:39] Finished a frame (24)
[04:52:40] Finished a frame (25)
[05:01:55] Finished a frame (26)

c:\Program Files\Folding@Home>grep -i protein FAHlog.txt
Searching for protein in FAHlog.txt (case-insensitive) ...
[03:26:49] Protein: p206
[15:21:25] Protein: p206
[22:45:25] Protein: p610_tetP30_build_ext
[04:34:46] Protein: p610_tetP30_build_ext
 
Tinker32 said:
. On my main box (xp@1563) it takes about 16hrs/Wu. Not a lot of points for so many cpu cycles :confused:


Lucky You!! ;) On my p3 600 at work, it takes about 67 hrs/wu.
:confused:
 
First off you really cant compare the pala7-2 to any other protein at all. It just way more productive on a SSE enabled rig.
Second, if you been folding for awhile you realize that 16 hrs for 7 points really isnt that bad and about typical for an XP @ 1563 mhz. So even if you got them for a straight week 24hr x 7 days/16 hrs x 7 points you'll still be making 73.5 points per week which is great. Now in my case my XP @ 1750 mhz finished the last one in 12hr and 16 mins. Almost 14 points a day, times 7 and you get 91 points per week. Now by my book that's great numbers for a tinker core protein.
There are far more worst proteins than the p610, in terms of productivety, so dont let the 200 frame get to you. I remember keeping a P2 400 mhz rig up, and alot of people still have rigs around this speed, and it'll take 4 to 5 days just to fold a protein A series (several month ago). So 16 hours aint a real biggy
 
Ray44420 said:
I have three machines at home, all folding 610s for the past couple days. Same thing over and over, even the one running Gromacs. I realize there aren't any Gromacs projects at the moment, but this sure is a slow WU. As far as getting rid of one, I imagine you could reinstall. This would get you a fresh WU, but lose the frames from work in progress. I am going to focus on piecing together another machine out of unwanted parts, this time a K62-266. I'll take every point I can get. I can feel the living room getting cozier with every machine!

Two things I would like to point out.

1) You can dump your protein to get a different one. It is the luck of the draw afterward. You may spend 5 or 6 hours and always get the same protein.

This is not an efficient use of your cycles. Dumping proteins causes that protein to remain on a wait list for the deadline. Then it must be sent out again to be completed. This wastes bandwidth for Stanford and you.

Generally speaking, it is less of a headache to just let your rigs fold.

2) The K6 series of cpus is notoriously SLOW at folding. It is quite possible that your 266 will not complete the work before the deadlines. Look around for some more info a lot of people here have that machine, so I could be wrong.

Glad to see you have the Folding bug. It beats the Flu bug.:p

Great to have you folding !!! It means all the sooner we can eradicate the scourge of humanity. Disease.

Fold long and Fold hard.
 
I would highly discourage anyone from dumping wu's!!! The information stanford collects are processed in a certain order. So if you dump the WU. Than stanford will wait until the deadline is over and send it out to another person. Now since they needs certain proteins in a particular order that means they wont be able to process the information without that protein! So what your doing by dumping that one particular protein you dont like is delaying the project/progress of the cause.
 
Macklin01: "Hmm, are you using windows or linux?"
Windows Xp Pro. Using EMIII. Although I'm sure I'd stick to the f@h client itself if it gets more tracking detail added.
Gtsimmo: "I would highly discourage anyone from dumping wu's!!! "
Since there are legitimate reasons to dump WUs.. such as WU corruption or client config issues, if the client had an option to dump current WU & notify Stanford before dl'ing new WU(s) - would that solve the assign&reassign WU problem? It seems on every folding forum I've visited, dumping WUs is commonplace (or atleast the default solution to any given issue). I recall reading in Pande Group's "to do" list the addition of issuing WUs based on folding pc's speed - which would solve AmigoThree's problem, however that may be a while coming.
 
Last edited:
Tinker32 said:


Windows Xp Pro. I've been folding for about 6mo, but still haven't gotten a handle on the point system. It seems rather arbitriary at times.


that's a good platform for folding. (I use it on my rig at home.) I'd have to agree wtih you with the points seeming a bit arbitrary at times. They're roughly indicative of folding time, but not precisely.

Since there are legitimate reasons to dump WUs.. such as WU corruption or client config issues, if the client had an option to dump current WU & notify Stanford before dl'ing new WU(s) - would that solve the assign&reassign WU problem?

Sometimes, a unit gets corrupted. Actually, dumping a unit is pretty easy. (at least on the console version, if you don't care about EMIII, etc.) Just delete the "work" folder and the queue.dat file.

Funny thing is, I can't quite remember what the original problem was. :) Oh, I guess it was that a particular protein was very slow on a particular machine. I suppose a few fixes are in order:

1) turn on -forceasm flag -- I believe it will force any CPU-specific optimizations which will speed up the process. If your rig isn't stable with those settings, then your overclock is too fast, anyway, and you probably haven't done sufficient memory and CPU stability testing.

2) turn off the -advmethods flag -- This flag is often used in giving preference to some of the harder proteins. So, turning it off might help avoid those particularly big ones.

3) If a protein is really slow, try to finish it anyway if you can. It's not too fun to throw away 18 hours of folding ....

4) If a protein is slow to the point of stalling, or you can definitely tell you'll never get it done in the quota period, then delete the work folder and the queue.dat file. (Just deleting one or the other will generally result in it trying over or downloading the same WU.) It's better to throw away a WU early in its cycle than later, as you hate to throw away a lot of computational time.

-- Paul
 
When a proteins gets corrupt and the Console it self dumps the WU it reports that to Stanford, which in turn can reissue it to another users. Now if you dump it cause you think it's not productive enough that's another issue. If you just delete the work folder, Stanford will have to wait till the deadline is due, reissue the WU and wait for that to be returned before continuing to analysis that particular project.
 
hmm, interesting. didn't know that ....

Are you sure it really works that way? If so, that means that the Stanford programmer have assumed that every machine that they assign a work unit to will finish its unit on time. (Since they only assign as many units as they need, no more no less, under that set of assumptions.) Which means that they assume that all computers they assign WU's to won't:

1) break down (hardware or software)
2) be used heavily for other tasks and therefore won't finish in time
3) have users who lose interest in folding midway and stop (it happens)
4) have users who shouldn't be folding and are caught
5) have corrupted data
6) be sold to someone else who chooses to not continue folding
7) be turned off for an extended period (e.g., holiday, vacation)
8) lose their internet access and be unable to transmit results within the time limit (e.g., ISP problems, lightning strike to phone system)
9) have any other occurence that affects folding.

This would be a poor set of assumptions for a post-doc/Ph.D/graduate student programming team, and I highly, highly doubt it. It would be more likely that they over-assign data for each project and stop assigning data (but continue to accept it) for each project when they receive enough results. After all, they have 70,000 active machines now. Extra completed WU's received can always be used for greater statistical analysis.

-- Paul
 
Last edited:
Just thought of something ...

I noticed that this 610 WU requires a certain minimum benchmark for it to be assigned to you. This means that if you don't make the proper benchmark speed (it's unknown just how that works at the moment), you won't get the WU. Notice how the console client says "benchmarking" every time you open it? Well, close your client, start something that makes heavy use of the CPU, and reopen the client. Once the bench is done, go ahead and kill those CPU-intensive tasks. But since that'll be the only time the client benchmarks before the next upload/download, I think it will do the trick.

-- Paul
 
gtsimmo said:
When a proteins gets corrupt and the Console it self dumps the WU it reports that to Stanford, which in turn can reissue it to another users. Now if you dump it cause you think it's not productive enough that's another issue. If you just delete the work folder, Stanford will have to wait till the deadline is due, reissue the WU and wait for that to be returned before continuing to analysis that particular project.

Hey, check this out - this is my theory, based on what I've seen by trying this a long time ago.

If you delete the work folder, without getting a new user ID, Stanford sends you the same work unit again. They know your user id, they know they sent you a wu that you have not sent back yet, so they give you the same one again. It makes sense.

Just a theory. Haven't cared enough to try to prove it.
 
I've also found that just deleting the work folder gets you back the same WU. I think the queue.dat file is the culprit there. If I remember correctly, you need to also delete the queue.dat file to get a new and different WU.

But what you raise is a good point -- if your WU is for some reason corrupted, you can delete JUST the work folder to start the same protein over again. ;)

-- Paul
 
Back