sys_fuzzMime-Version: 1.0

Wed Jan 25 03:21:19 UTC 2017

Yo Fred!

On Tue, 24 Jan 2017 18:48:43 -0800 (PST)
Fred Wright <fw at fwright.net> wrote:

> > > If one is dithering, the amount of dither should be based on the
> > > clock's actual resolution, *not* the time required to read it.
> > > In a sampled system, one would add dither equal to the
> > > quantization interval, in order to produce results statistically
> > > similar to sampling with infinite resolution.  For time values,
> > > one would add dither equal to the clock's counting period, to
> > > produce results statistically similar to a clock running at
> > > infinite frequency.  
> >
> > Possibly, but that is not how it works now.  And would it be an
> > improvement?  Bring on the experiments!  
> 
> I didn't say that it's worthwhile on modern systems; in fact I said
> exactly the opposite further down.  But if one *is* going to dither,
> then the clock period is the correct amount.  That's a peak-to-peak
> value, so if one is adding signed dither, then the magnitude should
> be half that.

Well, that is not what NTP does.  NTP dithers on the smallest time to
read the clock consecutively (sys_fuzz), then NTP ensures the time is
unique and increasing.  Given that the clock period is usually way
longer than the sys_fuzz, I think sys_fuzz is the thing to dither on.

> > > That's not uncommon, but it's a really bad idea.  Demanding that a
> > > clock always return unique values is an unwarranted extension of
> > > the job description of a clock.  
> >
> > Well then, you just said the current NTP implementation is a bad
> > idea.  
> 
> No, what I said is that it's a bad idea for an *OS time function* to
> corrupt the value in the name of uniqueness.  That's what Hal was
> talking about.

I don't agree, but getting off topic.

> > In practice, with nano Second resolution clocks doing
> > CLOCK_MONOTOMIC is not hard.  
> 
> Not necessarily (assuming you're actually talking about uniqueness
> rather than mere monotonicity), for a couple of reasons:

Getting lost in words that mean different things depending on the
context: POSIX, NTP, etc.

So, not gonna put a word on it, since the word is not important.  What
matters is that NTP always uses unique and increasing time.

> 1) Most clock counters don't really run at 1GHz, so they don't really
> have nanosecond resolution.  (in spite of what clock_getres() may
> say).

Ah, back to the dictionary! clock_gettime() does resolve to nano Second.
Just read the man page.

           struct timespec {
               time_t   tv_sec;        /* seconds */
               long     tv_nsec;       /* nanoseconds */
           };

Them things there are nano Seconds.

The reolution tells you nothing about how much it increments every time
that it increments.  Integer resolution, in this context, is just the
smallest increment of time that can be represented, it says nothing
about the precision, accuracy, increment or anthing else about the time
that is represented.

I can see this very easily on my RasPi's.  NTP reads the clock to
one nano Second, but it increments by much larger amounts.

This shows the effect:

    https://pi4.rellim.com/day/#local_clock_time_offset_histogram

> 2) Even if the clock really did run at 1GHz, if it could be read in
> under 1ns it would still be "coarse".  I'm not aware of any systems
> that can *currently* do that, but it's certainly not beyond the realm
> of possibility.  Assuming that machines will never be faster than X
> is one of those not-future-proof assumptions like Y2K.

Not gonna worry about things that don't happen yet or soon.

> Note that "monotonic" does not necessarily mean unique.

I'll try to bring this back on topic again: NTP cares nothing about
MONOTONIC.  The word in a NOP in NTP land.  No point bike shedding it.

> > > The proper way to derive unique values
> > > from a clock is to wrap it with something that fudges *its*
> > > values as needed, without inflicting lies on the clock itself.  
> >
> > Sorta circular since NTP reads the system clock, applies fudge, then
> > adjusts the sysclock t match.  
> 
> Umm, I think you're assuming that "fudges" above means some kind of
> NTP time adjustment.

Yup, that thing that NTP does, whether or not we understand it, it
clearly does it.

> I used it in the generic "fudge factor" sense,
> in this case meaning whatever adjustment is needed to ensure
> uniqueness.

Does not change my comment on your comment.

> Suppose one has:

You basically duplicated the Lamport rules, which is what NTP already
does, but w/o the sys_fuzz thing that NTP does.

> > > Also note that in some contexts it's reasonable to extend the
> > > resolution of a "coarse" clock (without breaking "fine" clocks) by
> > > reading the clock in a loop until the value changes.  This
> > > approach is completely neutered by a uniqueness kludge.  
> >
> > I do not see how that helps NTP, just adds latency.  
> 
> Of course.  But in *some contexts* it's useful, and it's broken if
> the OS insists on corrupting the time in the name of uniqueness.

Since NTP does not use CLOCK_MONOTONIC this a supposition on a fact that
does not apply to NTP.  Off topic.

> > > The clock_getres() function is supposed to report the actual clock
> > > resolution, which is what should determine the amount of dither,
> > > but in practice it's rarely correctly implemented.  E.g., in the
> > > Linux cases I've tested, it ignores the hardware properties and
> > > just retuns 1ns.  
> >
> > And it probably can not even determine the hardware properties.  
> 
> It knows perfectly well what the actual (or at least nominal)
> oscillator frequency is, since otherwise it wouldn't be able to
> convert the counter values to standard time units.  It just can't be
> bothered to use it for clock_getres().

Way more unknowns than clock frequency.  But not relevant, clock_getres()
says not to trust it, so why do we even talk about it? 

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170124/a64eaba9/attachment.bin>