[time-nuts] GPSDO for my rubber duckie

Michael Sokolov msokolov at ivan.Harhan.ORG
Tue Aug 2 01:18:54 UTC 2011


Chris Albertson <albertson.chris at gmail.com> wrote:

> In engineering something like this it is very impotent NOT to mix up
> "primary requirements", "derived requirements", "implementation
> details".
> "primary requirements" describe the thing you want, NOT how it works.
> Derived ones are the logical fallout from the first ones.

Fair enough.  My most basic primary requirement is to live my life on a
timescale that is anchored to mean solar time, just like timekeeping
used to be for hundreds if not thousands of years before atomic clocks.

At the present moment I can satisfy my requirement simply by looking at
a WWVB-synced wristwatch: WWVB transmits UTC, and UTC *as presently
implemented* with leap seconds passes as an acceptable realisation of
GMT.  However, certain forces have been pursuing a relentless push to
abolish the leap seconds, and there is a strong chance that these people
may finally have their way at the ITU vote in 2012-01.

If/when the PHKs of this world (the folks who want the leap seconds
gone) get their way, UTC as transmitted by WWVx etc, displayed on radio-
synced clocks and maintained on mainstream computer systems via NTP will
no longer be an acceptable realisation of GMT *in my eyes*, i.e., it
will no longer satisfy the requirements of my personal philosophy.
Therefore, I will need to build my own timescale to replace UTC for the
purposes of my personal life.

I have heard that if the PHKs have their way at the ITU in January 2012,
the leap seconds will continue for 5 more years and go away in 2017.
Therefore, I have to have my replacement timescale working no later than
2017.  But I don't like waiting till the last minute, I prefer to be
prepared and ahead of the game, hence I'm starting the work NOW.

> I don't 100% understand your time keeping system.  You say it's based
> on Earth rotation.  Is it like this
> http://en.wikipedia.org/wiki/Sidereal_time

Nope.  I want *mean solar* time, not sidereal.

A secondary requirement for me (if you want to call it that) is my
preference for rubber seconds over leap seconds.  I want my timescale to
pass as a realisation/approximation of GMT, but I also want it to read
as a real number at all times, i.e., no 23:59:60.  Therefore, I am
implementing a timescale which I've called UTR (UT Rubber), and it will
kill two birds with one stone:

1. For as long as UTC remains status quo, with leap seconds, my UTR will
   exactly equal UTC at all times except around a leap second.  At leap
   second time I will replace leaps with rubberization: instead of doing
   23:59:60, there will be 10 seconds on the UTR timescale (labelled
   23:59:50 through 23:59:59, inclusive) which will be 1.1 SI s long
   each, such that the UTR timescale will advance by 10 s over the
   course of 11 s of atomic time.  The whole thing will be called a
   rubberization instance.

2. When/if the muggle/mainstream UTC stops being acceptable as a form
   of mean solar time (i.e., when DUT1 passes the 1.0 s mark and no leap
   second is inserted to correct for it), I will take the matters into
   my own hands and start issuing rubberization instances on the UTR
   timescale (previously matching IERS leap seconds) by my own authority
   as the Republic of Terra Calendar Keeper.

> You left out the most important requirements.
> 1) How acurate does this all need to be?  Is 1/10 of a second good
> enough or is this all to run at the "handful of nano seconds" level?

I am most definitely not looking for nanoseconds, but I'm hoping for
something a little better than 100 ms.  1 ms is my rough accuracy
target.

> 2) How is the time to be output or displayed?  Are we driving an
> analog clock with sweep second hand or a time code generator?

Two outputs:

1. The primary output of most direct usefulness will be Ethernet.  I
   want my rubber duckie to run 4.3BSD-Quasijarus because that's my
   very own OS in which I have the greatest trust.  The way I envision
   it, the "golden" UTR timescale will be maintained by one of the
   clocks in the specially modified 4.3BSD-Quasijarus kernel, and
   various user mode processes on the rubber duckie will export this
   timescale in various ways.  I'll have a process that will accept
   time queries over Ethernet (both NTP and the older/simpler time
   protocol) and answer them with UTR time.

   This output is going to be the one of most direct usefulness: it will
   allow anyone of like mind to run his/her life on UTR instead of UTC
   by simply reconfiguring their ntpd to poll my rubber duckie (or their
   own copy thereof) instead of an official UTC NTP server.

However, the NTP output is not expected to be the most accurate one.
Around leap second time (be it an official IERS leap second or my own
substitute after the former cease) the UTR timescale will suddenly
speed up or slow down by 10%, then go back to SI second rate 10 s later:
I don't expect any NTP client to be able to follow that except by
getting out of sync and catching up afterward.

The latter blemish is not a real problem for my usage model.  Right now
I have my main servers (like the one I'm using to compose and send this
mailing list post) poll a UTC reference once an hour.  When they do the
poll and get back an answer in UTC, a delta is computed between the
server's local clock and the official time from the UTC source, and that
delta is fed to the adjtime system call which slews the system clock,
PLL-style.  My VAX UNIX servers do this once an hour, and any leap
second gets lost in the noise / added to the adjtime slewing that
happens the following hour.  It will work the same way when these same
servers start querying my rubber duckie for UTR instead of UTC.

2. Just for fun, I want to be able to actually observe my UTR timescale
   do its thing of speeding up / slowing down, ticking out 10 s of UTR
   in 9 or 11 SI seconds, and then going back to the normal SI rate.
   Because I don't expect to be able to observe that over NTP, I plan on
   adding a secondary output from the rubber duckie.  This secondary
   output will be a serial port which will drive LED/LCD displays located
   physically at the facility, or at least within EIA-485 reach.

That should give you the general idea of what I'm after.  I'm now
looking at the other responses in this thread and evaluating their
merits.

MS



More information about the time-nuts mailing list