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
Received on Tue Aug 17 2010 - 10:30:20 PDT
