|
Boost : |
From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2002-07-02 06:19:29
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:006301c221b3$b651c530$1d00a8c0_at_pdimov2...
> 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.)
>
Yes, but I don't think this affects the system time updates, but to be
honest I've never tested it ... wait ... ok, just did it. System time is
still only updated every 15ms (I'm running a SMP system).
Anyway, as long as correlation between absolute system time (xtime is time
elapsed since midnight, 1st of Jan 1970, or?) and sleep goodnight/wakeup
times are a concern, you'd have to use the time increment acquired from GSTA
as timeGetTime() and QueryPerformanceCounter() et al simply returns a
counter.
> QueryPerformanceCounter has better resolution, but is much less reliable.
Could you expand on the reliability stuff? I've been using QPC quite a lot,
and have seen no problems other than having a "lowly" 1.19MHz frequnecy on
uniprocessor systems (where rdtsc isn't used for it's implementation).
Regards // Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk