Chris Albertson <albertson.ch...@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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.