Hi Ross,
Sorry for all the doubts I have. I think I did not frame my previous
question in the right manner. This is what I wanted to ask, how do you
explain this output from mdinfo:
| Current Timing Info
| -------------------
| Total steps : 100000 | Completed : 1000 | Remaining : 99000
|
| Average timings for last 1000 steps:
| Elapsed(s) = 2.2 Per Step(ms) = 2.2
| ns/day = 79.3 seconds/ns = 1090.1
|
| Average timings for all steps:
| Elapsed(s) = 2.2 Per Step(ms) = 2.2
| ns/day = 79.3 seconds/ns = 1090.1
|
|
| Estimated time remaining: 3.6 minutes.
------------------------------------------------------------------------------
Does this mean that the simulation was < 60 secs. If yes, why does it have
steps remaining. Sorry if I am missing something obvious.
But if I increase the number of steps to 1000000 and hence, simulation time,
I get ns/day in compliance with the results on website.
~mayank
On Tue, Aug 17, 2010 at 1:39 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> 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
>
--
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 - 12:00:03 PDT
