[gmx-users] Gromacs performance on virtual servers

Szilárd Páll pall.szilard at gmail.com
Fri Jul 25 18:54:01 CEST 2014


On Fri, Jul 25, 2014 at 12:33 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> On Fri, Jul 25, 2014 at 1:51 AM, Szilárd Páll <pall.szilard at gmail.com>
> wrote:
>
>> Hi
>>
>> In general, virtualization will always have an overhead, but if done
>> well, the performance should be close to that of bare metal. However,
>> for GROMACS the ideal scenario is exclusive host access (including
>> hypervisor) and thread affinities which will both depend on the
>> hypervisor configuration. Hence, if you can, you should try to get
>> access to virtual hosts that fully utilize a compute node and do not
>> share it with others.
>
>
> Definitely.
>
>
>> On Fri, Jul 25, 2014 at 12:31 AM, Mark Abraham <mark.j.abraham at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Except for huge simulation systems, GROMACS performance past a single
>> node
>> > is dominated by network latency, so unless you can extract a promise that
>> > any multi-node runs will have Infiniband-quality latency (because the
>> nodes
>> > are physically in the same room, and on Infiniband) you can forget about
>> > doing multi-node MD on such a system.
>>
>> Two remarks:
>>
>> * With a slow network the only parallelization you can potentially
>> make use of is multi-sim, unless your environment is so could-y that
>> some nodes can have tens to hundreds of ms latency which can kill even
>> you multi-sim performance (depending on how fast each simulation is
>> and how often do they sync).
>>
>
> I would not encourage multi-sim on such a setup, unless you actually want
> replica exchange. The multi-sim implementation unnecessarily syncs
> simulations every min(nstlist,nstcalcenergy,nstreplex) step, so that might
> be ~tens of times per second. Unnecessary multi-sim is good for pretending
> you are doing a big parallel calculation to get access to a large chunk of
> a machine, but this is not really the case here.

Good point, I fully agree!

What I meant was that one can use quite efficiently even cheap
Ethernet networks for multi-sim type workloads where there is genuine
need for communication between simulations (but not too often). For
instance, replica exchange type runs work quite OK.

--
Szilárd

> * I've seen several claims that *good* 10/40G Ethernet can get close
>> to IB even in latency, even for MD, and even for GROMACS, e.g:
>> http://goo.gl/JrNxKf, http://goo.gl/t0z15f
>
>
> Interesting, thanks.
>
> Mark
>
>
>>
>>
>> Cheers,
>> --
>> Szilárd
>>
>> > Mark
>> >
>> >
>> > On Thu, Jul 24, 2014 at 10:54 PM, Elton Carvalho <eltonfc at if.usp.br>
>> wrote:
>> >
>> >> Dear Gromacs Users,
>> >>
>> >> My former university is focusing on cloud computing instead of
>> >> physical servers, so research groups are now expected to buy virtual
>> >> servers from the university coloud instead of buying their own
>> >> clusters.
>> >>
>> >> The current setup employs Xeon E7- 2870 servers and there is an
>> >> university-wide virtual cluster with 50 virtual servers each with 10
>> >> CPUs.
>> >>
>> >> Does anyone here have information on gromacs performance on this kind
>> >> of infrastructure? Should I expect big issues?
>> >>
>> >> One thing that comes to mind is that the CPUs may not necessarily be
>> >> in the same physical server, rack, or even datacenter (their plan is
>> >> to decentralize the colocation), so network latency may be higher than
>> >> the traditional setup, which may affect scaling. Does this argument
>> >> make sense or am I missing something on cloud management 101?
>> >>
>> >> Cheers.
>> >> --
>> >> Elton Carvalho
>> >> Departamento de Física
>> >> Universidade Federal do Paraná
>> >> --
>> >> Gromacs Users mailing list
>> >>
>> >> * Please search the archive at
>> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>> >> posting!
>> >>
>> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> >>
>> >> * For (un)subscribe requests visit
>> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> >> send a mail to gmx-users-request at gromacs.org.
>> >>
>> > --
>> > Gromacs Users mailing list
>> >
>> > * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>> posting!
>> >
>> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> >
>> > * For (un)subscribe requests visit
>> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-request at gromacs.org.
>> --
>> Gromacs Users mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-request at gromacs.org.
>>
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-request at gromacs.org.


More information about the gromacs.org_gmx-users mailing list