Hi Ross,
Thank you very much for such an extensive explanation. I clearly understand
now what does mdinfo do. One thing I want to verify is that if the
simulation finishes before the flush interval of mdinfo (60 secs) then the
way to calculate performance is by looking at mdout?
Here is the sample out from one mdout file which I have:
Here is the input file:
Minimize
&cntrl
imin=0,irest=1,ntx=5,
nstlim=100000,dt=0.002,ntb=0,
ntf=2,ntc=2,tol=0.000001,
ntpr=1000, ntwx=1000, ntwr=50000,
cut=9999.0, rgbmax=15.0,
igb=1,ntt=0,nscm=0,
/
|------------------- GPU DEVICE INFO --------------------
|
| CUDA Capable Devices Detected: 1
| CUDA Device ID in use: 0
| CUDA Device Name: Tesla C2050
| CUDA Device Global Mem Size: 3071 MB
| CUDA Device Num Multiprocessors: 14
| CUDA Device Core Freq: 1.15 GHz
|
|--------------------------------------------------------
--------------------------------------------------------------------------------
5. TIMINGS
--------------------------------------------------------------------------------
| Setup CPU time: 1.68 seconds
| NonSetup CPU time: 48.40 seconds
| Total CPU time: 50.08 seconds 0.01 hours
| Setup wall time: 2 seconds
| NonSetup wall time: 48 seconds
| Total wall time: 50 seconds 0.01 hours
Here the Total Wall Time and Total CPU Time are similar but if I use this 50
seconds to calculate ns/day, I get a very high number. Incidentally this is
one of the benchmarks on the AMBER Website. I have made sure that ECC is
switched off.
~mayank
On Tue, Aug 17, 2010 at 1:04 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi Mayank,
>
> The only metric you should worry about here is the wallclock time. This
> tells you the time to run the actual calculation. Division between time
> spent on cpu vs gpu is not meaningful since the cpu blocks while the gpu is
> running and vice versa. Some OS's actually accrue cputime incorrectly
> depending on how it blocks, a similar thing happens with MPI installations
> that don't use interrupts when sitting at a barrier - e.g. Microsoft MPI.
> This will accrue minimal cpu time in the counters. E.g. with some MPI
> installations you can keep increasing the number of cpus in use and the cpu
> time keeps going down and down making the performance look better and
> better
> when really what is happening is lots of time is being accumulated in
> barriers but these don't show up in the cpu time counters. So the cpu time
> shows the performance getting better and better but really your calculation
> is taking longer and longer. This is mostly a recent occurrence in the last
> year or so as some MPI implementations have changed the way they sit at
> barriers. I can envision a similar thing with GPU runs.
>
> However, the wallclock time is always correct - since it is real world time
> so this is what you should look at to see your performance. The mdinfo file
> uses wallclock time in its calculations of performance.
>
> All the best
> Ross
>
> > -----Original Message-----
> > From: Mayank Daga [mailto:mdaga.vt.edu]
> > Sent: Tuesday, August 17, 2010 9:42 AM
> > To: AMBER Mailing List
> > Subject: Re: [AMBER] Question about mdinfo file.
> >
> > Thanks for the replies.
> >
> > I tried looking at the Timing values in mdout.
> >
> > It contains the Total CPU Time as well as Total Wall Time. For my
> > simulation, both are 50 secs. I wanted to know do these times include
> > the
> > time spent on the GPU? If not, where do I find the Total GPU Time? If I
> > use
> > 50secs to calculate ns/day, I am getting amazingly high numbers.
> >
> > Thanks again,
> >
> > ~mayank
> >
> > On Tue, Aug 17, 2010 at 12:00 PM, Jason Swails
> > <jason.swails.gmail.com>wrote:
> >
> > > It's certainly possible that the simulation becomes more efficient in
> > later
> > > steps, especially since the first steps have the setup and such.
> > However,
> > > it's trivial to calculate the ns/day that you achieve by looking at
> > the
> > > mdout file. Simply look at how long it took to complete your 10000
> > steps
> > > and convert that into ns/day. (Simple dimensional analysis that we
> > do in
> > > our 1st chemistry class). In fact, that's how it's done for the
> > mdinfo.
> > >
> > > On Tue, Aug 17, 2010 at 11:55 AM, Mayank Daga <mdaga.vt.edu> wrote:
> > >
> > > > What I am concerned is how would the ns/day be affected if and if
> > not the
> > > > simulations run to the entirety. The mdinfo file states ns/day
> > obtained
> > > due
> > > > to last 'x' steps, hence if the 'x' = 10000 and not 1000, is there
> > a
> > > chance
> > > > the average would be better for 10000 steps??
> > > > ~mayank
> > > >
> > > > On Tue, Aug 17, 2010 at 11:31 AM, Jason Swails
> > <jason.swails.gmail.com
> > > > >wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I believe that pmemd does not update the mdinfo file as often as
> > it
> > > > updates
> > > > > the mdout file due to performance implications. You can figure
> > out the
> > > > > source of this discrepancy by digging through the pmemd code, but
> > this
> > > > has
> > > > > no effect on your results.
> > > > >
> > > > > Hope this helps,
> > > > > Jason
> > > > >
> > > > > On Tue, Aug 17, 2010 at 11:10 AM, Mayank Daga <mdaga.vt.edu>
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am a newbie using AMBER on the GPUs.
> > > > > > When I run my simulations, I see two output files, mdout and
> > mdinfo.
> > > In
> > > > > the
> > > > > > mdinfo file, I see the timing details as to how many ns/day I
> > get.
> > > The
> > > > > > issue
> > > > > > is some steps are always uncompleted according to this file
> > while
> > > mdout
> > > > > > lists that all the steps have been completed. Why is this
> > > discrepancy?
> > > > > > For example, if I run a simulation for 10000 steps, mdinfo
> > shows 9000
> > > > > steps
> > > > > > remaining while mdout list energy values for all 10000 steps.
> > > > > >
> > > > > > I am using the input files as downloaded from the AMBER website
> > and
> > > to
> > > > > run
> > > > > > the simulation:
> > > > > > ~/amber11/bin/pmemd.cuda -O -i mdin -o mdout -p prmtop -c
> > inpcrd -r
> > > > > restrt
> > > > > > -x mdcrd -gpu 0
> > > > > >
> > > > > > Please explain this behaviour.
> > > > > >
> > > > > > Thanks,
> > > > > > ~mayank
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mayank Daga | SyNeRGy Laboratory | Dept. of Computer Science
> > > > > > Virginia Tech | http://synergy.cs.vt.edu | http://www.cs.vt.edu
> > > > > > _______________________________________________
> > > > > > AMBER mailing list
> > > > > > AMBER.ambermd.org
> > > > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jason M. Swails
> > > > > Quantum Theory Project,
> > > > > University of Florida
> > > > > Ph.D. Graduate Student
> > > > > 352-392-4032
> > > > > _______________________________________________
> > > > > AMBER mailing list
> > > > > AMBER.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Mayank Daga | SyNeRGy Laboratory | Dept. of Computer Science
> > > > Virginia Tech | http://synergy.cs.vt.edu | http://www.cs.vt.edu
> > > > _______________________________________________
> > > > AMBER mailing list
> > > > AMBER.ambermd.org
> > > > http://lists.ambermd.org/mailman/listinfo/amber
> > > >
> > >
> > >
> > >
> > > --
> > > Jason M. Swails
> > > Quantum Theory Project,
> > > University of Florida
> > > Ph.D. Graduate Student
> > > 352-392-4032
> > > _______________________________________________
> > > AMBER mailing list
> > > AMBER.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber
> > >
> >
> >
> >
> > --
> > Mayank Daga | SyNeRGy Laboratory | Dept. of Computer Science
> > Virginia Tech | http://synergy.cs.vt.edu | http://www.cs.vt.edu
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Mayank Daga | SyNeRGy Laboratory | Dept. of Computer Science
Virginia Tech | http://synergy.cs.vt.edu | http://www.cs.vt.edu
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Aug 17 2010 - 10:30:22 PDT
