Re: [boost] Re: xtime and GetSystemTimeAsFileTime

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-02 05:32:04

From: "Johan Nilsson" <johan.nilsson_at_[hidden]>
>
> "Pete Becker" <petebecker_at_[hidden]> wrote in message
> news:5.1.0.14.2.20020701095017.00bcefd0_at_pop.rcn.com...
> > At 06:55 AM 7/1/2002 -0500, William Kempf wrote:
> > >>From: "Simon J. Julier" <sjulier_at_[hidden]>
> > >>
> > >>1. The Windows system timer runs between 10ms and 55ms, depending on
the
> > >>version of Windows used
> >
>
>>(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/
> ti
> > >>me_5h2d.asp). Reinhold tells me that the value returned by
> > >>GetSystemTimeAsFileTime seems to update at the same rate.
> > >
> > >This one I consider a non-issue.  The xtime stuff does not promise any
> > >kind of granularity, so a 10-55ms variation on different Windows
> platforms
> > >is not a "violation" of the implied contract here.
> >
>
> [snip]
>
> > an exact multiple of the xtime clock tick rate. Ideally, thread::sleep
> > would the number of milliseconds up to the next higher tick boundary,
but
> > that boundary isn't generally known.
>
> Under NT, you can use GetSystemTimeAdjustment(..,lpTimeIncrement,..) to
find
> out how often the system time is updated and by what amount. The Win9x
> family of "operating systems" will hopefully quickly become an extinct
> species.

The entire Windows family has... pretty inadequate timing support, but I've
found timeGetTime (in conjunction with timeBeginPeriod/timeEndPeriod on NT)
to be the least broken approach (1 ms resolution.)

QueryPerformanceCounter has better resolution, but is much less reliable.