Subject: Re: [ledbat] Confusion about clock terminology

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 7 Aug 2009 12:12:39 -0700

On Wed, Jul 29, 2009 at 5:18 AM, Stuart Cheshire<[email-masked]> wrote:
> Stanislav,
>
> In previous LEDBAT meetings I've been confused by your use of the term
> "skew". I mention it because others may be confused too.
>
> NTP uses the terms "offset" (the difference between the instantaneous
> absolute values of the clocks), "skew" (the difference between the *rates*
> the clocks run, the rate of change of the offset) and "drift" (the rate of
> change of the skew value).

Stuart,

Thank you for pointing it out.

The draft uses NTP terminology throughout and I'll clarify that.

The new text of the relevant paragraph:

    One-way delay measurement needs to deal with timestamp errors.
We'll use the same locally linear clock model and the same terminology
as Network Time Protocol (NTP). This model is valid for any
differentiable clocks.  NTP uses the term "offset" to refer to
difference from true time and "skew" to refer to difference of clock
rate from the true rate.  The clock will thus have a fixed offset from
the true time and a skew.  We'll consider what we need to do about the
offset and the skew separately.

> To me this is odd. In normal conversation I think most people understand
> "clock skew" to mean the absolute difference in current time, e.g. "Your
> clock is three minutes ahead of mine," and "clock drift" to mean that this
> difference changes over time, e.g. "Our clocks are drifting. Yesterday our
> clocks were in sync but today your clock is three minutes ahead of mine."

I always understood skew by mentally plotting the one-way delays
measured in both directions.  Without a clock skew, the lines are
parallel.  With it, they are not, and thus "skewed."

Obviously, I'd be equally happy with any consistent terminology and
went with NTP because there's an RFC for that.  NTP's use of "drift"
always sounded odd to me.

Thanks for catching the ambiguity,

-- Stas

> There seems to be evidence of this common understanding:
>
> The "make" command's "clock skew detected" error refers to an absolute
> offset in current clock value, not a difference in rates.
>
> In Kerberos, the term skew is used to refer to an absolute offset:
>
>> Hosts are configured to reject responses from any KDC whose clock is not
>> within the specified maximum clock skew, as specified in the krb5.conf file.
>> The default value for the maximum clock skew is five minutes (300 seconds).
>
>
> The Wikipedia page also describes skew as the difference in time, not
> difference in rate.
>
> <http://en.wikipedia.org/wiki/Clock_skew>
>
>> On a network such as the internet, clock skew describes the difference in
>> time shown by the clocks at the different nodes on the network. It is
>> usually an unavoidable phenomenon (at least if one looks at milli-second
>> resolutions), but clock skew of tens of minutes or more is also quite
>> common.
>
>
> I'm not saying the NTP terminology is wrong, but used without clarification
> it definitely invites misunderstanding.
>
> Stuart Cheshire <[email-masked]>
> * Wizard Without Portfolio, Apple Inc.
> * Internet Architecture Board
> * www.stuartcheshire.org
>
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com