📄 144
字号:
pp->filter[i] = pp->filter[0]; pp->coderecv++; /* * Copy the raw offsets and sort into ascending order */ for (i = 0; (u_int) i < pp->nstages; i++) off[i] = pp->filter[i]; qsort((char *)off, pp->nstages, sizeof(l_fp), arc_refclock_cmpl_fp); /* * Reject the furthest from the median of nstages samples until * nskeep samples remain. */ i = 0; n = pp->nstages; while ((n - i) > nskeep) { lftmp = off[n - 1]; median = off[(n + i) / 2]; L_SUB(&lftmp, &median); L_SUB(&median, &off[i]); if (L_ISHIS(&median, &lftmp)) { /* reject low end */ i++; } else { /* reject high end */ n--; } } /* * Compute the dispersion based on the difference between the * extremes of the remaining offsets. Add to this the time since * the last clock update, which represents the dispersion * increase with time. We know that NTP_MAXSKEW is 16. If the * sum is greater than the allowed sample dispersion, bail out. * If the loop is unlocked, return the most recent offset; * otherwise, return the median offset. */ lftmp = off[n - 1]; L_SUB(&lftmp, &off[i]); disp = LFPTOFP(&lftmp) + current_time - pp->lasttime; if (disp > REFCLOCKMAXDISPERSE) return (0); pp->offset = off[(n + i) / 2]; /* Originally: pp->offset = offset; */ pp->dispersion = disp; return (1);}#endif /* ARCRON_OWN_FILTER */#endif----------X-Sun-Data-Type: defaultX-Sun-Data-Description: defaultX-Sun-Data-Name: driver27.htmlX-Sun-Charset: us-asciiX-Sun-Content-Lines: 412<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN"><html><head><title>Arcron MSF Receiver</title></head><body><h3>Arcron MSF Receiver</h3><hr><p><h4>Synopsis</h4><p>Address: 127.127.27.<var>u</var><br>Reference ID: MSF<br>Driver ID: ARCRON_MSF<br>Serial Port: <code>/dev/arc<var>u</var></code>; 300 baud, 8-bits, 2-stop,no parity<br>Features: <code>tty_clk</code><p><h4>Description</h4><p>This driver supports the Arcron MSF receiver, and would probablyalso support the DCF77 variant of the same clock. The clock reportsits ID as ``<code>MSFa</code>'' to indicate MSF as a source and the useof the ARCRON driver.<p>This documentation describes version V1.0 (1997/05/21) of the sourceand has been tested against xntpd3-5.90 on Solaris-1 (SunOS 4.1.3_U1 onan SS1 serving as a router and firewall) and against xntpd3-5.90 onSolaris-2.5 (on a SS1+ and TurboSPARC 170MHz). This code will probablywork, and show increased stability, reduced jitter and more efficiency(fewer context switches) with the <code>tty_clk</code>discipline/STREAMS module installed, but this has not been tested. Fora to-do list see the comments at the start of the code.<p>This driver is designed to allow the unit to run from batteries asdesigned, for something approaching the 2.5 years expected in the usualstand-alone mode, but no battery-life measurements have been taken.<p>Much of this code is originally from the other refclock driver fileswith thanks. The code was originally made to work with the clockby <a href="mailto:derek@toybox.demon.co.uk">Derek Mulcahy</a>, withmodifications by <a href="mailto:d@hd.org">Damon Hart-Davis</a>.Thanks also to <a href="mailto:lyndond@sentinet.co.uk">Lyndon David</a>for some of the specifications of the clock.<p>There is support for a Tcl/Tk monitor written by Derek Mulcahythat examines the output stats; see the<a href="http://www2.exnet.com/NTP/ARC/ARC.html">ARC Rugby MSF Receiver</a>page for more details and the code.<p>Look at the notes at the start of the code for further information;some of the more important details follow.<p>The driver interrogates the clock at each poll (ie every 64s bydefault) for a timestamp. The clock responds at the start of the nextsecond (with the start bit of the first byte being on-time). The timeis in `local' format, including the daylight savings adjustment when itis in effect. The driver code converts the time back to UTC.<p>The clock claims to be accurate to within about 20ms of theMSF-broadcast time, and given the low data transmission speed fromclock to host, and the fact that the clock is not in continuous syncwith MSF, it seems sensible to set the `precision' of this clock to -5or -4, -4 being used in this code, which builds in a reporteddispersion of over 63ms (ie says ``This clock is not very good.'').You can improve the reported precision to -4 (and thus reduce the basedispersion to about 31ms) by setting the fudge <code>flag3</code> to<code>1</code>.<p>Even a busy and slow IP link can yield lower dispersions than thisfrom polls of primary time servers on the Internet, which reinforcesthe idea that this clock should be used as a backup in case of problemswith such an IP link, or in the unfortunate event of failure of moreaccurate sources such as GPS.<p>By default this clock reports itself to be at stratum 2 rather thanthe usual stratum 0 for a refclock, because it is not really suited tobe used as other than a backup source. The stratum reported can bechanged with the <code>fudge</code> directive to be whatever you like.After careful monitoring of your clock, and appropriate choice of the<code>time1</code> fudge factor to remove systematic errors in theclock's reported time, you might fudge the clock to stratum 1 to allowa stratum-2 secondary server to sync to it.<p>The driver code arranges to resync the clock to MSF at intervals ofa little less than an hour (deliberately avoiding the same time eachhour to avoid any systematic problems with the signal or host). Whilstresyncing, the driver supplements the normal polls for time from theclock with polls for the reception signal quality reported by theclock. If the signal quality is too low (0--2 out of a range of 0--5),we chose not to trust the clock until the next resync (which we bringforward by about half an hour). If we don't catch the resync, and sodon't know the signal quality, we do trust the clock (because thiswould generally be when the signal is very good and a resync happensquickly), but we still bring the next resync forward and reduce thereported precision (and thus increase reported dispersion).<p>If we force resyncs to MSF too often we will needlessly exhaust thebatteries the unit runs from. During clock resync this driver tries totake enough time samples to avoid <code>xntpd</code> losing sync incase this clock is the current peer. By default the clock would onlyresync to MSF about once per day, which would almost certainly not beacceptable for NTP purposes.<p>The driver does not force an immediate resync of the clock to MSFwhen it starts up to avoid excessive battery drain in case<code>xntpd</code> is going to be repeatedly restarted for any reason,and also to allow enough samples of the clock to be taken for<code>xntpd</code> to sync immediately to this clock (and not remainunsynchronised or to sync briefly to another configured peer, only tohop back in a few poll times, causing unnecessary disturbance). Thisbehaviour should not cause problems because the driver will not acceptthe timestamps from the clock if the status flag delivered with thetime code indicates that the last resync attempt was unsuccessful, sothe initial timestamps will be close to reality, even if with up to aday's clock drift in the worst case (the clock by default resyncs toMSF once per day).<p>The clock has a peculiar RS232 arrangement where the transmit linesare powered from the receive lines, presumably to minimise batterydrain. This arrangement has two consequences:<ul><li>Your RS232 interface must drive both +ve and -ve<li>You must (in theory) wait for an echo and a further 10ms between characters</ul>This driver, running on standard Sun hardware, seems to work fine; notethe use of the <code>send_slow()</code> routine to queue up commandcharacters to be sent once every two seconds.<p>Three commands are sent to the clock by this driver. Each commandconsists of a single letter (of which only the bottom four bits aresignificant), followed by a CR (ASCII 13). Each character sent to theclock should be followed by a delay to allow the unit to echo thecharacter, and then by a further 10ms. Following the echo of thecommand string, there may be a response (ie in the cae of the<code>g</code> and <code>o</code> commands below), which in the case ofthe <code>o</code> command may be delayed by up to 1 second so as thestart bit of the first byte of the response can arrive on time.The commands and their responses are:<dl><dt><code>g</code> CR<dd>Request for signal quality. Answer only valid during (late partof) resync to MSF signal. The response consists of two characters asfollows: <ol> <li><dl compact> <dt>bit 7</dt> <dd> parity <dt>bit 6</dt> <dd> always 0 <dt>bit 5</dt> <dd> always 1 <dt>bit 4</dt> <dd> always 1 <dt>bit 3</dt> <dd> always 0 <dt>bit 2</dt> <dd> always 0 <dt>bit 1</dt> <dd> always 1 <dt>bit 0</dt> <dd> = 0 if no reception attempt at the moment, = 1 if reception attempt (ie resync) in progress </dl> <li><dl compact> <dt>bit 7</dt> <dd> parity <dt>bit 6</dt> <dd> always 0 <dt>bit 5</dt> <dd> always 1 <dt>bit 4</dt> <dd> always 1 <dt>bit 3</dt> <dd> always 0 <dt>bit 2--0</dt> <dd> reception signal quality in the range 0--5 (very poor to very good); if in the range 0--2 no successful reception is to be expected. The reported value drops to zero when not resyncing, ie when first returned byte is not `3'. </dl> </ol><dt><code>h</code> CR<dd>Request to resync to MSF. Can take up from about 30s to 360s.Drains batteries so should not be used excessively. After this theclock time and date should be correct and the phase within 20ms of timeas transmitted from Rugby MSF (remember to allow for propagationtime). By default the clock resyncs once per day shortly after 2am(presumably to catch transitions to/from daylight saving timequickly). With this driver code we resync at least once per hour tominimise clock wander.<dt><code>o</code> CR<dd>Request timestamp. Start bit of first byte of response is on-time,so may be delayed up to 1 second. Note that when the BST mode is ineffect the time is GMT/UTC +0100, ie an hour ahead of UTC to reflectlocal time in the UK. The response data is as follows: <ol> <li>hours tens (hours range from 00 to 23) <li>hours units <li>minutes tens (minutes range from 00 to 59) <li>minutes units <li>seconds tens (seconds presumed to range from 00 to 60 to allow for leap second) <li>seconds units <li>day of week 1 (Monday) to 7 (Sunday) <li>day of month tens (day ranges from 01 to 31) <li>day of month units <li>month tens (months range from 01 to 12) <li>month units <li>year tens (years range from 00 to 99) <li>year units <li>BST/UTC status <dl compact> <dt>bit 7</dt> <dd> parity <dt>bit 6</dt> <dd> always 0 <dt>bit 5</dt> <dd> always 1 <dt>bit 4</dt> <dd> always 1 <dt>bit 3</dt> <dd> always 0 <dt>bit 2</dt> <dd> = 1 if UTC is in effect (reverse of bit 1) <dt>bit 1</dt> <dd> = 1 if BST is in effect (reverse of bit 2) <dt>bit 0</dt> <dd> = 1 if BST/UTC change pending </dl> <li>clock status<dl compact> <dt>bit 7</dt> <dd> parity <dt>bit 6</dt> <dd> always 0 <dt>bit 5</dt> <dd> always 1 <dt>bit 4</dt> <dd> always 1 <dt>bit 3</dt> <dd> = 1 if low battery is detected <dt>bit 2</dt> <dd> = 1 if last resync failed (though officially undefined for the MSF clock) <dt>bit 1</dt> <dd> = 1 if at least one reception attempt since 0230 for the MSF clock was successful (0300 for the DCF77 clock) <dt>bit 0</dt> <dd> = 1 if the clock has valid time---reset to zero when clock is reset (eg at power-up), and set to 1 after first successful resync attempt. </dl> </ol>The driver only accepts time from the clock if the bottom three bits ofthe status byte are <code>011</code>. The leap-year logic forcomputing day-in-year is only valid until 2099, and the clock willignore stamps from the clock that claim BST is in effect in the firsthour of each year. If the UK parliament decides to move us to+0100/+0200 time as opposed to the current +0000/+0100 time, it is notclear what effect that will have on the time broadcast by MSF, andtherefore on this driver's usefulness.</dl>A typical <code>ntp.conf</code> configuration file for this drivermight be:<pre># hostname(n) means we expect (n) to be the stratum at which hostname runs.#------------------------------------------------------------------------------# SYNCHRONISATION PARTNERS# ========================# Our betters...server 127.127.27.0 # ARCRON MSF radio clock(1).# Fudge stratum and other features as required.# ADJUST time1 VALUE FOR YOUR HOST, CLOCK AND LOCATION!fudge 127.127.27.0 stratum 1 time1 0.016 flag3 1 flag4 1peer 11.22.33.9 # tick(1--2).peer 11.22.33.4 # tock(3), boot/NFS server.# This shouldn't get swept away unless left untouched for a long time.driftfile /var/tmp/ntp.drift#------------------------------------------------------------------------------# RESTRICTIONS# ============# By default, don't trust and don't allow modifications. Ignore in fact.restrict default ignore notrust nomodify# Allow others in our subnet to check us out...restrict 11.22.33.0 mask 255.255.255.0 nomodify notrust# Trust our peers for time. Don't trust others in case they are insane.restrict 127.127.27.0 nomodifyrestrict 11.22.33.4 nomodifyrestrict 11.22.33.9 nomodify# Allow anything from the local host.restrict 127.0.0.1</pre>There are a few <code>#define</code>s in the code that you might wishto play with:<dl><dt><code>ARCRON_KEEN</code></dt><dd>With this defined, the code is relatively trust⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -