[gmx-developers] Re: flushing files

[Roland Schulz]

On Wed, Oct 13, 2010 at 2:05 AM, <hess at sbc.su.se> wrote:

> Hi,
>
> I think there is no fundamental reason why we can not flush
> only at checkpointing. I don't recall what the originial motivation
> was for flushing every frame. This was probably done before we use
> the whole output file list in the checkpointing code, so the only
> reason might have been because of checkpointing.
> I like that I always have every frame immediately, but having it
> up to at most 15 minutes ago is also fine.
> The question is if we should only flush at checkpointing by default
> or have a switch or some automated setting (we could even catch
> a signal to flush immediately).
>
What would you prefer?
I think we should try to keep it as simple as possible (I think we already
have to many features too seldom used with the potential to introduce bugs).
Thus I'm not sure whether automated setting or signal is the best way to go.
I don't see a good reason to flush thus I would go with a hidden option to
enforce flushing. But that's just my 2c.

Roland

>
> Berk
>
> > On Wed, Oct 13, 2010 at 1:02 AM, Erik Lindahl <lindahl at cbr.su.se> wrote:
> >
> >> Hi,
> >>
> >> File flushing has been a huge issue to get working properly on AFS and
> >> other systems that have an extra layer of network disk cache. We also
> >> want
> >> to make sure the files are available e.g. on the frontend node of a
> >> cluster
> >> while the simulation is still running.
> >>
> > Do we want to guarantee that it is available sooner than at each
> > checkpoint
> > (thus by default 15min)?
> >
> > I think the proper solution is rather to have a separate IO thread so the
> >> disk operation can take all the latency in the world without delaying
> >> the
> >> run.
> >>
> > This won't solve it for all cases. Depending on the write frequency (e.g.
> > every 10 frames) the flushing time can take longer than computing the
> > frames
> > while the actually writing time (measured as the writing time with only
> > infrequent flush) is fast enough to not cause significant overhead. In
> > those
> > situations the simulation would still wait on the IO thread.
> >
> > Also this adds additional complexity. Not all systems like
> oversubscribing
> > threads as far as I know. I know that older versions of Cray had problems
> > and I heard their are also problems with BlueGene. Thus we would need to
> > make the IO thread functionality optional which would add yet
> > another duplication of code (both with and without IO thread).
> >
> > You are more then welcome to play with it (but not in the release
> branch!)
> > -
> >>
> > No this is only going into the CollectiveIO branch and from their into
> the
> > master branch.
> >
> >
> >>  you might already have anaccount on the AFS-equipped clusters here, or
> >> we
> >> can arrange it!
> >>
> >> Alternatively, sync with Sander and he might be able to test new code on
> >> AFS.
> >>
> >
> > Yes if I could get an account or Sander could test the CollectiveIO
> branch
> > that would be great. I'll write Sander directly tomorrow.
> >
> > Roland
> >
> >
> >>
> >>
> >> On Oct 12, 2010, at 23:26, Roland Schulz <roland at utk.edu> wrote:
> >>
> >> Erik, Berk,
> >>
> >> you added flushing of trn, xtc and ern before the checkpointing
> >> functionality had been added. The additional flush can add quite a bit
> >> of unnecessary time especially with parallel file systems and/or MPI-IO.
> >> Am
> >> I right that with checkpointing it is not necessary anymore?  The
> >> checkpointing is flushing the file before writing the checkpoint.
> >> Also gmx_fio_check_file_position is flushing the file before checking
> >> whether the file is too large for gmx_off_t
> >> Roland
> >>
> >> --
> >> ORNL/UT Center for Molecular Biophysics
> >> <http://cmb.ornl.gov>cmb.ornl.gov
> >> 865-241-1537, ORNL PO BOX 2008 MS6309
> >>
> >>
> >
> >
> > --
> > ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> > 865-241-1537, ORNL PO BOX 2008 MS6309
> >
>
>


-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20101013/9509a06f/attachment.html>