What the heck is a gromacs33 ?

R

RPhArrow

Gawd
Joined
Jul 19, 2005
Messages
939
I recently got a WU #1486 that is described on the project page as a gromacs33 using FahCore_a0.exe. It is giving EMIII a bad time, all I know is that is worth 300 pts.

Anybody have any other insight ?

RPhArrow --\\\-------------------->
 
Thats a new one on me, haven't seen it before. If you don't mind, let me know what hardware thats running on and how long it takes to crunch!

 
Sounds like its time to go give LPerry a visit and grab that new protein file. Hopefully it'll set things straight.

I did some searching on www.folding-community.org and it seems that this is new enough that it doesn't even show up at all. Hopefully its a good folder. :D

 
Can you post the log file for that unit?


Keep on Folding!!

 
That protein uses a new core and is supposed to be available only to those that run Linux boxes right now.

As soon as I get more info I'll post an update to EM. ;)

No warning about the new core from Stanford... :(
 
LPerry to the rescue!!!

Nothing on Google either..... I haven't been able to get to the folding forum to check yet....

Anyone have info on this new core?

There are 2 entries on the comprehensive summary page ,looking at the Beta page, their both beta proteins..... Is this a faster gromac core? linux-optimized? make coffee?


Keep on Folding!! For the [H]orde!!

 
Here's snippet from logfile . It's a 300 pointer apparently . It's running under u_m's foldix on a P4 640 (at stock speed of 3.2GHZ , 2MB cache), hyperthreading disabled, so single instance of FAH running.

[01:19:44]
[01:19:44] Trying to unzip core FahCore_a0.exe
[01:19:45] Decompressed FahCore_a0.exe (3166376 bytes) successfully
[01:19:45] + Core successfully engaged
[01:19:50]
[01:19:50] + Processing work unit
[01:19:50] Core required: FahCore_a0.exe
[01:19:50] Core found.
[01:19:50] Working on Unit 00 [March 14 01:19:50]
[01:19:50] + Working ...
[01:19:50]
[01:19:50] *------------------------------*
[01:19:50] Folding@Home Gromacs 3.3 Core
[01:19:50] Version 1.70 (February 3, 2006)
[01:19:50]
[01:19:50] Preparing to commence simulation
[01:19:50] - Assembly optimizations manually forced on.
[01:19:50] - Not checking prior termination.
[01:19:51] - Expanded 1415265 -> 7290049 (decompressed 515.1 percent)
[01:19:51] - Starting from initial work packet
[01:19:51]
[01:19:51] Project: 1486 (Run 0, Clone 87, Gen 0)
[01:19:51]
[01:19:51] Assembly optimizations on if available.
[01:19:51] Entering M.D.
[01:19:57] Protein: p1486_hafp_fus
[01:19:57] Writing local files
[01:19:58] Extra SSE boost OK.
[01:19:58] Writing local files
[01:19:58] Completed 0 out of 1000000 steps (0%)
[01:55:44] Writing local files
[01:55:44] Completed 10000 out of 1000000 steps (1%)
[02:31:40] Writing local files
[02:31:40] Completed 20000 out of 1000000 steps (2%)
[03:07:41] Writing local files
[03:07:41] Completed 30000 out of 1000000 steps (3%)
[03:43:48] Writing local files
[03:43:48] Completed 40000 out of 1000000 steps (4%)
[04:20:02] Writing local files
[04:20:02] Completed 50000 out of 1000000 steps (5%)
[04:56:20] Writing local files
[04:56:20] Completed 60000 out of 1000000 steps (6%)
[05:32:40] Writing local files
[05:32:40] Completed 70000 out of 1000000 steps (7%)
[06:09:04] Writing local files
[06:09:04] Completed 80000 out of 1000000 steps (8%)
[06:45:30] Writing local files
[06:45:31] Completed 90000 out of 1000000 steps (9%)
[07:22:02] Writing local files
[07:22:02] Completed 100000 out of 1000000 steps (10%)

 
RPhArrow said:
Here's snippet from logfile . It's a 300 pointer apparently . It's running under u_m's foldix on a P4 640 (at stock speed of 3.2GHZ , 2MB cache).
<snip>
Click to expand...
Let's see...that's 6 hours for 10%. That's a whopping 120 ppd. :rolleyes: I sure hope they adjust the points on it if that's how slow it runs.

 
Hmmm. I'll have to watch my linux boxen and see if they grab one. Mine are either P3s or Athlon XPs, so I wonder if it might be limited to P4s.
 
Mohonri said:
Let's see...that's 6 hours for 10%. That's a whopping 120 ppd. :rolleyes: I sure hope they adjust the points on it if that's how slow it runs.

Click to expand...

I'd be happy right now if I could keep something on my P4 2.8 that would actually get PPD that high. For a while I was stuck with WU's that were only doing about 50-60 PPD tops. I was not too happy with those WU's at all. At least now it's working on a 404 pointer getting 90 PPD. That's still way lower than it would normally do on Gromacs in the past. I'm not talking about bigpackets gromacs either, just the normal ones.

 
How much ram is it taking right now? Probly not too much since it doesn't look like a bonus WU. Also I'd assume that its going to be able to run on any cpu that has SSE, so it wouldn't be limited to P4's like the QMD's were. We'll see tho, anyone pulled one down on a P3 or AMD cpu?

 
Just remember you are all still helping out science whether your ppd is "high" or not. You're still completing wus and that is what is important.

 
MN Scout said:
Just remember you are all still helping out science whether your ppd is "high" or not. You're still completing wus and that is what is important.

Click to expand...

Actually, I just did some messing around with some stuff. I have a second instance on the machine that runs timeless and is normally set to 15% CPU. That usually allows the main instance to run 100% while the second just makes use of the hyperthreading. Normally, this does not affect frame times on the main unit. However, just for the hell of it I stopped the main one and put the second client at 100%. It started doing 120PPD after several steps were completed. For a little more hell I started up the main instance again. The main instance is now doing a hell of a lot more while the Tinker has dropped to about 75 or so PPD. This is just some messed up stuff. It has gone through a few frames on the big Gromac this way so it should be stable times. As I'm getting ready to leave work, I'll have to check back on it tomorrow. Sadly enough, it seems to be running faster with two instances running at the moment.

 
Imitation said:
How much ram is it taking right now? Probly not too much since it doesn't look like a bonus WU. Also I'd assume that its going to be able to run on any cpu that has SSE, so it wouldn't be limited to P4's like the QMD's were. We'll see tho, anyone pulled one down on a P3 or AMD cpu?

Click to expand...
Only using 118MB of ram --- makes me wonder why I'm putting a GB in all my folders :rolleyes: Some boxen definitely use it... but most don't.

 
SmokeRngs said:
Actually, I just did some messing around with some stuff. ...<snip>
Click to expand...
What happens if you set the priority (via -configonly) for the main instance to "low" and the timeless instance to "idle"? It seems to me that hyperthreading would then make the second instance only run when the first instance is stalled, and return immediately to the main instance when it's ready. If that works, you wouldn't have to worry about percentages or anything--let the Windows scheduler (not task scheduler, the OS scheduler) worry about it.

Has anybody tried this--setting one instance to low priority and the other to idle?


 
Mohonri said:
What happens if you set the priority (via -configonly) for the main instance to "low" and the timeless instance to "idle"? It seems to me that hyperthreading would then make the second instance only run when the first instance is stalled, and return immediately to the main instance when it's ready. If that works, you wouldn't have to worry about percentages or anything--let the Windows scheduler (not task scheduler, the OS scheduler) worry about it.

Has anybody tried this--setting one instance to low priority and the other to idle?


Click to expand...

This is exactly how I have it setup. It doesn't work the way you descrbe for a hyperthreaded processor, though, since Windows acts as if it's two physical processors. I run like that on my XP-m due to my sometimes flaky wireless connection. That way, if I can't send back the WU on the main client the second one with timeless picks up. It also doesn't allow for any idle time when uploading and downloading new WU's.

 
My fileserver has 2 of them. :)

Current Work Unit
-----------------
Name: p1486_hafp_fus
Download time: March 14 09:37:54
Due time: September 30 09:37:54
Progress: 58% [|||||_____]


Current Work Unit
-----------------
Name: p1485_rxnsemi300
Download time: March 15 02:02:27
Due time: May 1 02:02:27
Progress: 76% [|||||||___]

Seem pretty efficient...

[02:02:44] Completed 0 out of 1000000 steps (0%)
[02:32:08] Writing local files
[02:32:08] Completed 10000 out of 1000000 steps (1%)
[03:01:35] Writing local files
[03:01:35] Completed 20000 out of 1000000 steps (2%)

*snip*

[14:24:39] Completed 740000 out of 1000000 steps (74%)
[14:54:14] Writing local files
[14:54:14] Completed 750000 out of 1000000 steps (75%)
[15:23:55] Writing local files
[15:23:55] Completed 760000 out of 1000000 steps (76%)

That's the 2nd unit, and after 37 hours on a 2200+ AthlonMP with fileserving and some other stuff like updating portage last night. Note the ETA of the 1st unit! :eek:
 
tsuehpsyde said:
Note the ETA of the 1st unit! :eek:
Click to expand...
That's just when Stanford really wants the results back by. It's (probably) the "final deadline". Of course, the faster it gets back to them, the happier VJ is.

 
Mohonri said:
That's just when Stanford really wants the results back by. It's (probably) the "final deadline". Of course, the faster it gets back to them, the happier VJ is.

Click to expand...

The due date is based on a formula, though. I think that's what he's getting at.

 
I just got a 1485 on my linux A64 1.8 box, doing frames in 44 minutes. However, since it's only 166 points, it's ~ 40PPD.

 
You must log in or register to reply here.
Back
Top