On Tue, 2012-02-07 at 20:21 -0500, Andrew Richardson wrote:
> On Feb 7, 2012, at 7:30 PM, John Stultz wrote:
> > On Wed, 2012-02-08 at 00:16 +0100, Zygmunt Krynicki wrote:
> > Hrm. No, that shouldn't be the case. CLOCK_MONOTONIC and
> > CLOCK_REALTIME
> > are driven by the same accumulation, and are only different by an
> > offset.
> > 
> > That said, in the test case you're using CLOCK_MONOTONIC_RAW, which
> > I
> > don't think you really want, as its not NTP freq corrected. In
> > addition
> > it is driven by some slightly different accumulation logic.  But you
> > said CLOCK_REALTIME showed the same issue, so its probably not some
> > CLOCK_MONOTONIC_RAW specific bug.
> > 
> 
> 
> In general, I don't want the time value moving around on me (in case
> something weird is going on and it's changing too much). This seems to
> be what most people advise when it comes to profiling something with
> sub-second execution, but I might be misunderstanding you slightly.

The difference is "hardware constant" vs "software controlled time
constant". And with all things time, its all relative. :)

CLOCK_MONOTONIC_RAW is uncorrected, so a second may not really be a
second and things like thermal changes can cause fluctuations in your
timing intervals. CLOCK_MONOTONIC is NTP corrected, so a second should
be a second and thermal drift should be corrected for, but that depends
on how much you trust ntpd.

That said, CLOCK_MONOTONIC can really only be corrected to 500ppm of
CLOCK_MONOTONIC_RAW, so I suspect the difference won't really matter
that much unless your measuring longer intervals. Its not like
CLOCK_REALTIME, which is more problematic as it may be set back and
forth any amount of time.


> Seems a bit too high, right? I did get some low values, such as a
> 500nanoseconds difference, once. I was expected a harsh lower bound
> (e.g. a few ms), but a measurement of 500ns elapsed makes that theory
> unlikely.

Yea. I suspect something else is at play here.

thanks
-john




_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to