Hi Maynak,
The mdinfo file is also flushed when the job runs so in this case if it
finished in under 60 seconds the data in the mdinfo file will be correct and
the ns/day will be fine as a reference. You should see here that the timing
for the last XXX steps should match the average timing for all steps since
they should represent the same number of steps.
The thing to remember though is that < 60 seconds is probably too short for
reliable performance numbers due to delays spinning up disks, starting the
job etc etc. I typically run a minimum of 5 mins or so and >10,000 steps
when looking for reliable performance numbers.
All the best
Ross
> -----Original Message-----
> From: Mayank Daga [mailto:mdaga.vt.edu]
> Sent: Tuesday, August 17, 2010 10:19 AM
> To: AMBER Mailing List
> Subject: Re: [AMBER] Question about mdinfo file.
>
> 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Aug 17 2010 - 11:00:05 PDT
