Mailing List Archive

On Mon, Apr 9, 2012 at 4:46 PM, Guido van Rossum <guido@python.org> wrote:

> Is it still? I thought they fixed that ages ago?
>

sadly, no. http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith <greg@krypto.org> wrote:
> >
> > On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz <glyph@twistedmatrix.com
> >
> > wrote:
> >>
> >> On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
> >>
> >> In any case, NTP is not the only thing that adjusts the clock, e.g. the
> >> operating system will adjust the time for daylight savings.
> >>
> >>
> >> Daylight savings time is not a clock adjustment, at least not in the
> sense
> >> this thread has mostly been talking about the word "clock". It doesn't
> >> affect the "seconds from epoch" measurement, it affects the way in
> which the
> >> clock is formatted to the user.
> >>
> >> -glyph
> >
> >
> > even on windows where the system hardware clock is maintained in local
> time?
> >
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>

>> In any case, NTP is not the only thing that adjusts the clock, e.g. the
>> operating system will adjust the time for daylight savings.
>
> Daylight savings time is not a clock adjustment, at least not in the sense
> this thread has mostly been talking about the word "clock".  It doesn't
> affect the "seconds from epoch" measurement, it affects the way in which the
> clock is formatted to the user.

Ah yes, you're right. The system clock uses the UTC time zone on Linux
and Windows, and it is not affected by DST.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

On 4/7/2012 5:49 AM, Victor Stinner wrote:
> 2012/4/7 Janzert<janzert@janzert.com>:
>> On 4/5/2012 6:32 AM, Victor Stinner wrote:
>>> I prefer to use CLOCK_MONOTONIC, not because it is also available for
>>> older Linux kernels, but because it is more reliable. Even if the
>>> underlying clock source is unstable (unstable frequency), a delta of
>>> two reads of the CLOCK_MONOTONIC clock is a result in *seconds*,
>>> whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or
>>> smaller than a second. time.monotonic() unit is the second, as written
>>> in its documentation.
>>
>> I believe the above is only true for sufficiently large time deltas. One of
>> the major purposes of NTP slewing is to give up some short term accuracy in
>> order to achieve long term accuracy (e.g. whenever the clock is found to be
>> ahead of real time it is purposefully ticked slower than real time).
>
> I don't think that NTP works like that. NTP only uses very smooth adjustements:
>
> ""slewing": change the clock frequency to be slightly faster or slower
> (which is done with adjtime()). Since the slew rate is limited to 0.5
> ms/s, each second of adjustment requires an amortization interval of
> 2000 s. Thus, an adjustment of many seconds can take hours or days to
> amortize."
> http://www.python.org/dev/peps/pep-0418/#ntp-adjustment
>

Right, the description in that paragraph is exactly what I was referring
to above. :) It is unfortunate that a clock with a resolution of 1ns may
be purposefully thrown off by 500,000ns per second in the short term.

In practice you are probably correct that it is better to take the
slewed clock even though it may have purposeful short term inaccuracy
thrown in than it is to use the completely unadjusted one.

>> So for benchmarking it would not be surprising to be better off with the
>> non-adjusted clock. Ideally there would be a clock that was slewed "just
>> enough" to try and achieve short term accuracy, but I don't know of anything
>> providing that.
>
> time.monotonic() is not written for benchmarks. It does not have the
> highest frequecency, it's primary property is that is monotonic. A
> side effect is that it is usually the steadiest clock.
>
> For example, on Windows time.monotonic() has only an accuracy of 15 ms
> (15 milliseconds not 15 microseconds).
>

Hmm, I just realized an unfortunate result of that. Since it means
time.monotonic() will be too coarse to be useful for frame rate level
timing on windows.

Janzert

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com