144

Unix/Linux 网络时间协议版本3 Network Time Protocol Version 3 (NTP) distribution for Unix systems

Return-Path: [e-mail] 
Return-Path: <[e-mail]>
Received: from mailgate.exnet.com (gate3.exnet.com [204.137.193.226])
	by whimsy.udel.edu (8.8.5/8.8.5) with SMTP id XAA24565
	for <[e-mail]>; Tue, 20 May 1997 23:27:53 GMT
Received: from exnet.com (assam.exnet.com) by mailgate.exnet.com with SMTP id AA18595
	(5.67a/IDA-1.4.4 for [e-mail]); Wed, 21 May 1997 00:27:27 +0100
Received: from maildrop.exnet.com (camomile.exnet.com) by exnet.com with SMTP id AA25203
	(5.67a/IDA-1.4.4); Wed, 21 May 1997 00:25:35 +0100
From: Damon at work <[e-mail]>
Received: by maildrop.exnet.com (SMI-8.6/client-1.4DHD)
	id AAA14789; Wed, 21 May 1997 00:25:30 +0100
Date: Wed, 21 May 1997 00:25:30 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: New code and doc.
Cc: [e-mail], [e-mail]
Content-Type: X-sun-attachment

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 21


> From [e-mail] Mon May 19 23:34:38 1997
> To: "Damon at work" <[e-mail]>
> Subject: Re: The context diffs 
> Date: Mon, 19 May 1997 18:29:26 -0400
> From: [e-mail]
> Source-Info:  From (or Sender) name not authenticated.
> 
> Damon,
> 
> It's your driver.  Send me whatever copy you want me to include.
> 
> I want to release 5.90.1 within the next few days, and depending on the
> feedback, there will either be a 5.90.2 testing release or a 5.91
> release candidate thereafter.

New code and doc included.

Code in use at ntp.exnet.com (though not at this very moment).

Damon 
----------
X-Sun-Data-Type: c-file
X-Sun-Data-Description: c-file
X-Sun-Data-Name: refclock_arc.c
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 1388

/*
 * refclock_arc - clock driver for ARCRON MSF receivers
 */

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#if defined(REFCLOCK) && defined(ARCRON_MSF)

    static const char arc_version[] = { "V1.0 1997/05/21" };

#ifndef ARCRON_NOT_KEEN
#define ARCRON_KEEN 1 /* Be keen, and trusting of the clock, if defined. */
#endif

#ifndef ARCRON_NOT_OWN_FILTER
#define ARCRON_OWN_FILTER 1 /* Use own median filter to get round 3-5.90 bug. */
#endif

#ifndef ARCRON_NOT_MULTIPLE_SAMPLES
#define ARCRON_MULTIPLE_SAMPLES 1 /* Use all timestamp bytes as samples. */
#endif

/*
Code by Derek Mulcahy, <[e-mail]>, 1997.
Modifications by Damon Hart-Davis, <[e-mail]>, 1997.

THIS CODE IS SUPPLIED AS IS, WITH NO WARRANTY OF ANY KIND.  USE AT
YOUR OWN RISK.

Orginally developed and used with xntp3-5.85 by Derek Mulcahy.

Built against xntp3-5.90 on Solaris 2.5 using gcc 2.7.2.

This code may be freely copied and used and incorporated in other
systems providing the disclaimer and notice of authorship are
reproduced.

-------------------------------------------------------------------------------

Author's original note:

I enclose my xntp driver for the Galleon Systems Arc MSF receiver.

It works (after a fashion) on both Solaris-1 and Solaris-2.

I am currently using xntp3-5.85.  I have been running the code for
about 7 months without any problems.  Even coped with the change to BST!

I had to do some funky things to read from the clock because it uses the
power from the receive lines to drive the transmit lines.  This makes the
code look a bit stupid but it works.  I also had to put in some delays to
allow for the turnaround time from receive to transmit.  These delays
are between characters when requesting a time stamp so that shouldn't affect
the results too drastically.

...

The bottom line is that it works but could easily be improved.  You are
free to do what you will with the code.  I haven't been able to determine
how good the clock is.  I think that this requires a known good clock
to compare it against.

-------------------------------------------------------------------------------

Damon's notes for adjustments:


GENERAL
=======

 1) The C preprocessor symbol to have the clock built has been changed
    from ARC to ARCRON_MSF to minimise the possiblity of clashes with
    other symbols in the future.

 2) PRECISION should be -4/-5 (63ms/31ms) for the following reasons:

     a) The ARC documentation claims the internal clock is (only)
        accurate to about 20ms relative to Rugby (plus there must be
        noticable drift and delay in the ms range due to transmission
        delays and changing atmospheric effects).  This clock is not
        designed for ms accuracy as NTP has spoilt us all to expect.

     b) The clock oscillator looks like a simple uncompensated quartz
        crystal of the sort used in digital watches (ie 32768Hz) which
        can have large temperature coefficients and drifts; it is not
        clear if this oscillator is properly disciplined to the MSF
        transmission, but as the default is to resync only once per
        *day*, we can imagine that it is not, and is free-running.  We
        can minimise drift by resyncing more often (at the cost of
        reduced battery life), but drift/wander may still be
        significant.

     c) Note that the bit time of 3.3ms adds to the potential error in
        the the clock timestamp, since the bit clock of the serial link
        may effectively be free-running with respect to the host clock
        and the MSF clock.  Actually, the error is probably 1/16th of
        the above, since the input data is probably sampled at at least
        16x the bit rate.

    By keeping the clock marked as not very precise, it will have a
    fairly large dispersion, and thus will tend to be used as a
    `backup' time source and sanity checker, which this clock is
    probably ideal for.  For an isolated network without other time
    sources, this clock can probably be expected to provide *much*
    better than 1s accuracy, which will be fine.

    By default, PRECISION is set to -4, but experience, especially at a
    particular geographic location with a particular clock, may allow
    this to be altered to -5.  (Note that skews of +/- 10ms are to be
    expected from the clock from time-to-time.)  This improvement of
    reported precision can be instigated by setting flag3 to 1, though
    the PRECISION will revert to the normal value while the clock
    signal quality is unknown whatever the flag3 setting.

    IN ANY CASE, BE SURE TO SET AN APPROPRIATE FUDGE FACTOR TO REMOVE
    ANY RESIDUAL SKEW, eg:

        server 127.127.27.0 # ARCRON MSF radio clock unit 0.
        # Fudge timestamps by about 20ms.
        fudge 127.127.27.0 time1 0.020

    You will need to observe your system's behaviour, assuming you have
    some other NTP source to compare it with, to work out what the
    fudge factor should be.  For my Sun SS1 running SunOS 4.1.3_U1 with
    my MSF clock with my distance from the MSF transmitter, +20ms
    seemed about right, after some observation.

 3) REFID has been made "MSFa" to reflect the MSF time source and the
    ARCRON receiver.

 4) DEFAULT_RESYNC_TIME is the time in seconds (by default) before
    forcing a resync since the last attempt.  This is picked to give a
    little less than an hour between resyncs and to try to avoid
    clashing with any regular event at a regular time-past-the-hour
    which might cause systematic errors.

    The INITIAL_RESYNC_DELAY is to avoid bothering the clock and
    running down its batteries unnecesarily if xntpd is going to crash
    or be killed or reconfigured quickly.  If ARCRON_KEEN is defined
    then this period is long enough for (with normal polling rates)
    enough time samples to have been taken to allow xntpd to sync to
    the clock before the interruption for the clock to resync to MSF.
    This avoids xntpd syncing to another peer first and then
    almost immediately hopping to the MSF clock.

    The RETRY_RESYNC_TIME is used before rescheduling a resync after a
    resync failed to reveal a statisfatory signal quality (too low or
    unknown).

 5) The clock seems quite jittery, so I have increased the
    median-filter size from the typical (previous) value of 3.  I
    discard up to half the results in the filter.  It looks like maybe
    1 sample in 10 or so (maybe less) is a spike, so allow the median
    filter to discard at least 10% of its entries or 1 entry, whichever
    is greater.

 6) Sleeping *before* each character sent to the unit to allow required
    inter-character time but without introducting jitter and delay in
    handling the response if possible.

 7) If the flag ARCRON_KEEN is defined, take time samples whenever
    possible, even while resyncing, etc.  We rely, in this case, on the
    clock always giving us a reasonable time or else telling us in the
    status byte at the end of the timestamp that it failed to sync to
    MSF---thus we should never end up syncing to completely the wrong
    time.

 8) If the flag ARCRON_OWN_FILTER is defined, use own versions of
    refclock median-filter routines to get round small bug in 3-5.90
    code which does not return the median offset.

 9) We would appear to have a year-2000 problem with this clock since
    it returns only the two least-significant digits of the year.  But
    xntpd ignores the year and uses the local-system year instead, so
    this is in fact not a problem.  Nevertheless, we attempt to do a
    sensible thing with the dates, wrapping them into a 100-year
    window.

 10)Logs stats information that can be used by Derek's Tcl/Tk utility
    to show the status of the clock.

 11)The clock documentation insists that the number of bits per
    character to be sent to the clock, and sent by it, is 11, including
    one start bit and two stop bits.  The data format is either 7+even
    or 8+none.


TO-DO LIST
==========

  * Eliminate use of scanf(), and maybe sprintf().

  * Avoid /dev/arcX becoming our controlling terminal.  Do we really
    want a ^C or somesuch on the tty line aborting xntpd (would it)?

  * Allow user setting of resync interval to trade battery life for
    accuracy; maybe could be done via fudge factor or unit number.

  * Possibly note the time since the last resync of the MSF clock to
    MSF as the age of the last reference timestamp, ie trust the
    clock's oscillator not very much...

  * Add very slow auto-adjustment up to a value of +/- time2 to correct
    for long-term errors in the clock value (time2 defaults to 0 so the
    correction would be disabled by defaulr).

  * Consider trying to use the tty_clk/ppsclock support.

  * Possibly use average or maximum signal quality reported during
    resync, rather than just the last one, which may be atypical.

*/


/* Notes for HKW Elektronik GmBH Radio clock driver */
/* Author Lyndon David, Sentinet Ltd, Feb 1997      */
/* These notes seem also to apply usefully to the ARCRON clock. */

/* The HKW clock module is a radio receiver tuned into the Rugby */
/* MSF time signal tranmitted on 60 kHz. The clock module connects */
/* to the computer via a serial line and transmits the time encoded */
/* in 15 bytes at 300 baud 7 bits two stop bits even parity */

/* Clock communications, from the datasheet */
/* All characters sent to the clock are echoed back to the controlling */
/* device. */
/* Transmit time/date information */
/* syntax ASCII o<cr> */
/* Character o may be replaced if neccesary by a character whose code */
/* contains the lowest four bits f(hex) eg */
/* syntax binary: xxxx1111 00001101 */

/* DHD note:
You have to wait for character echo + 10ms before sending next character.
*/

/* The clock replies to this command with a sequence of 15 characters */
/* which contain the complete time and a final <cr> making 16 characters */
/* in total. */
/* The RC computer clock will not reply immediately to this command because */
/* the start bit edge of the first reply character marks the beginning of */
/* the second. So the RC Computer Clock will reply to this command at the */
/* start of the next second */
/* The characters have the following meaning */
/* 1. hours tens   */
/* 2. hours units  */
/* 3. minutes tens */
/* 4. minutes units */
/* 5. seconds tens  */
/* 6. seconds units */
/* 7. day of week 1-monday 7-sunday */
/* 8. day of month tens */
/* 9. day of month units */
/* 10. month tens */
/* 11. month units */
/* 12. year tens */
/* 13. year units */
/* 14. BST/UTC status */
/*      bit 7   parity */
/*      bit 6   always 0 */
/*      bit 5   always 1 */
/*      bit 4   always 1 */
/*      bit 3   always 0 */
/*      bit 2   =1 if UTC is in effect, complementary to the BST bit */
/*      bit 1   =1 if BST is in effect, according to the BST bit     */
/*      bit 0   BST/UTC change impending bit=1 in case of change impending */
/* 15. status */
/*      bit 7   parity */
/*      bit 6   always 0 */
/*      bit 5   always 1 */
/*      bit 4   always 1 */
/*      bit 3   =1 if low battery is detected */
/*      bit 2   =1 if the very last reception attempt failed and a valid */
/*              time information already exists (bit0=1) */
/*              =0 if the last reception attempt was successful */
/*      bit 1   =1 if at least one reception since 2:30 am was successful */
/*              =0 if no reception attempt since 2:30 am was successful */
/*      bit 0   =1 if the RC Computer Clock contains valid time information */
/*              This bit is zero after reset and one after the first */
/*              successful reception attempt */

/* DHD note:
Also note g<cr> command which confirms that a resync is in progress, and
if so what signal quality (0--5) is available.
Also note h<cr> command which starts a resync to MSF signal.
*/



#include <stdio.h>
#include <ctype.h>