[time-nuts] NTP to discipline Raspberry Pi

Tim Shoppa tshoppa at gmail.com
Fri Jul 26 13:26:24 EDT 2013


> There is another quirk with NTP.  It measures the tick rate and fills in
the
> bottom bits with random.  (I can't explain why.  If you are unlucky, you
can
> see time going backwards.)

I think this is equivalent to dithering which is useful when making
quantitized measurements of many physical processes. Other places in NTP
use the ntp_random routine to introduce dither where appropriate as well.
Upstream of the dithered values, NTP is tracking jitter which is actually
very important to be representative of the actual measurements for the peer
selection math to work right.

…[O]ne of the earliest [applications] of dither came in World War II.
Airplane bombers used mechanical computers to perform navigation and bomb
trajectory calculations. Curiously, these computers (boxes filled with
hundreds of gears and cogs) performed more accurately when flying on board
the aircraft, and less well on ground. Engineers realized that the
vibration from the aircraft reduced the error from sticky moving parts.
Instead of moving in short jerks, they moved more continuously. Small
vibrating motors were built into the computers, and their vibration was
called dither from the Middle English verb "didderen," meaning "to
tremble." Today, when you tap a mechanical meter to increase its accuracy,
you are applying dither, and modern dictionaries define dither as a highly
nervous, confused, or agitated state. In minute quantities, dither
successfully makes a digitization system a little more analog in the good
sense of the word.
—Ken Pohlmann, *Principles of Digital Audio*

Tim N3QE


On Fri, Jul 26, 2013 at 1:13 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

>
> mc235960 at gmail.com said:
> >   Most interesting.  I do however have an issue with your wording.
> > "Already, this tells us that the smallest meaningful timestamp
> resolution on
> > the Pi is 1 microsecond."
>
> >   Timer resolution may be limited ( I haven't trawled the code), but
> > timestamps are supported to nanosecond resolution as timespec{} is 64
> bits.
> > and clock_gettime() returns that.
>
> Right.  But if you read the clock many times in a row, you will get several
> copies of the same value followed by several copies of the next value...
>
> There are two different ideas here.  One is do you see low bits (below
> microsecond) when you read the clock.  The other is what size are the steps
> between values that you see.
>
> Suppose the clock on your system is nominally 1 microsecond.  In reality,
> it
> will be slightly off.  If you are running ntpd, it will tell the kernel how
> far off.  The kernel will then adjust the clock by 1.000037492 microseconds
> per tick rather than 1.0, so you will see low bits.
>
>
> >   That said NTP limits itself to timeval{} stamps, ie usecs.
>
> Huh?  NTP has been doing sub-microsecond for years.
>
> There is another quirk with NTP.  It measures the tick rate and fills in
> the
> bottom bits with random.  (I can't explain why.  If you are unlucky, you
> can
> see time going backwards.)
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list