Previous part

From: Dave Pickles <davep@nugate.demon.co.uk> [-/+]
Date: Sun, 09 Feb 1997 20:30:21 +0000
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: low-cost clocks
[-/+]
X-Keywords: dialup
[-/+] NIST [-/+]

In article: <5dgnai$bi@hpindda.cup.hp.com>  dalton@cup.hp.com (David Dalton)
writes:
>
> What would you recommend for a low-cost clock for use with NTP in the USA?
> In Europe?  Elsewhere?
>
> I know about the dialup time service provided by NIST in Colorado.  Are
> there others like this, particularly in other countries?
>
> I have heard about radio clocks that listen to an AM radio signal,
> obviously short-range, but have no information about who makes the hardware
> or who transmits the signal or where.  Do these really exist?
>
> -> My $.02 only.  Not an official statement from HP.
> --
>      As far as we know, our computer has never had an undetected error.
> ---------------------------------------------------------------------------
> David Dalton                 dalton@cup.hp.com                 408/447-3016

We use a low-cost radio clock which picks up the 60kHz signal from radio
station MSF in the UK. The clock is intended for PC-type applications and
comes with driver software for NT. Running xntpd on the same NT box gives us a
time standard for the rest of the site accurate to a fraction of a second.

There are two problems at present. MSF is off the air for two hours each week
for maintenance. And 60kHz is a noisy part of the radio spectrum in a machine
room environment; the radio had to be very carefully sited before it would
work. However the total cost of the setup is less than 200 UK pounds.
--
Dave Pickles


From: Jim Reid <jim@pc37.mpn.cp.philips.com> [-/+]
Date: 10 Feb 1997 18:00:25 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP through FireWall
[-/+]
X-Keywords: firewall
[-/+] TCP [-/+] UDP [-/+]

WhiskerP@logica.com (Peter Whisker) writes:

> In article <32fe1b2c.0@news.getonthe.net>, Joe Smith <joey@cooldude.com> wrote:
> >We are behind a firewall located at corporate.  Is there any product that
> >will do NTP through a firewall?  We have http, ftp, and telnet available.
>
> What our Corporate firewall people did was to put xntpd on the Firewall
> server and then everyone who wants to inside the company can synchronise to
> the Firewall.
>
> The Firewall syncs to a few Stratum-1 sources outside and thus provides
> Stratum-2 to users inside which is reasonable.

This is OK, but it makes your systems and network even more dependent
on the firewall. If ntp goes berserk on the firewall, or its clock
misbehaves, time on the internal net will keep in sync with the
firewall. This is not good. Don't forget that firewalls are designed
to keep out undesirable traffic, not to be a good time source.

You can also use udprelay. It's like SOCKS, but for UDP traffic
instead of TCP traffic. Thus, there is controlled forwarding of UDP
traffic such as NTP or DNS data.

> The alternative which is much less attractive is to put a hole in your
> firewall for UDP port 123 to some named IP addresses.

There's nothing unattractive about it. NTP is a safe protocol. You
might as well allow the traffic through the firewall between your main
internal servers and the external ones. If you're paranoid about bogus
NTP timestamps, use one of xntpd's encryption modes. [Remember the
attacker would have to forge timestamps from all the servers you used.
If they just impersonated one and sent packets to advance/retard the
clock, NTP would treat that as a less good time source.] If that's not
enough, buy your own radio clocks. If you're so paranoid that you
think that the time signals could be compromised, buy an atomic clock.


From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 12 Feb 1997 17:04:20 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP and SGI -- HELP!!

Have a look in /var/sysgen/mtune/kernel for the variable "timetrim".
Also make sure you have disabled timed and/or timeslave.

That should fix you up just fine.

Enjoy!

Rick


From: gdonl@tsc.tdk.com (Don Lewis)
Date: 11 Feb 1997 07:57:09 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd ntp_io.c input_handler reentered unsafely
X-Keywords: release
[-/+]

In article <32FFD68B.329B@carbon.chem.nyu.edu>,
Edward J. Huff <huffe@carbon.chem.nyu.edu> wrote:
>I believe that this happened because a sig_io signal came
>through after the test for free_recvbufs not zero and
>before the buffer was taken off the list.
>
>That reentrant call decremented free_recvbufs, took
>a buffer off the list, and returned, leaving free_recvbufs
>zero.  I can't prove that because the traces are mostly
>gone, but it's the only thing that makes sense.
>
>The traceback shows that input_handler was on the
>stack three times here, which is rather suspicious.

I believe the short answer is that this is due to the bogus call
to segset() in sigio_handler().  Configure finds both sigaction()
and sigset() when run on Solaris 2.x and #define's both HAVE_SIGACTION
and HAVE_SIGSET.  I suspect that the call to sigset() inside the signal
handler unblocks this signal before the handler has returned.  The quick
fix is to just nuke this section of code.

The long answer is a bit more involved.  I did some archeological digging
on Unix signals for an upcoming sendmail release.  Here's a summary:

**      Note:   OLD_SIGNALS    - The original unreliable UNIX signals.  The
**                               signal handler has to be re-armed each time.
**              SVR3_SIGNALS   - sigset()/sighold()/sigrelse().  As specified
**                               by SVID2.  Signal handler doesn't need to be
**                               re-armed.
**              BSD4_1_SIGNALS - Similar to SVR3_SIGNALS, except that syscalls
**                               are restarted.  Probably requires linking
**                               with -ljobs.  Some implementations may be
**                               incompatible with vfork().
**              BSD4_2_SIGNALS - sigvec()/sigblock()/sigsetmask().  Signal
**                               handler doesn't need to be re-armed.  Slow
**                               syscalls are restarted.
**              BSD4_3_SIGNALS - Like BSD4_2SIGNALS, but syscall restart is
**                               optional.
**              POSIX_SIGNALS -  sigaction()/sigprocmask().  By default the
**                               signal handler does not need to be re-armed.
**                               Syscall restart available, but defaults off

All of these implementations except OLD_SIGNALS have a syscall for waiting
for signals, but the SVR3/BSD4_1 flavor of sigpause() only allows one
signal to be unblocked, so machines with these signal implementations probably
aren't suitable for doing signalled I/O.  Systems that have the BSD4_2,
BSD4_3, or POSIX signal implementations can use signalled I/O, and they
don't need any magic in their signal handlers to either re-arm the handler
or to block the signal while the handler is executing.  Configure should
probably look for either sigvec() or sigaction() and use their presence
to determine the default value of HAVE_SIGNALED_IO.  I think this change
and the removal of the call to sigset() in sigio_handler() should reduce
the number of special cases in configure.

I'm unclear on what the semantics of signal_no_reset() are supposed to be.
Is the signal handler supposed to be set back to SIG_DFL when the handler
is invoked (like the ancient signal() does), or is the handler supposed to
be preserved?  If the latter, then sigaction() should be used if available,
otherwise sigvec() if it is available, otherwise sigset() (sigvec() is
preferred since we might be running on a BSD system with the 4.2 sigvec()
and the 4.1 sigset()), and hopefully we don't need to run on any ancient
flavors of Unix.  If the former behavior is desired, then we're in luck
if we have sigaction() and the SA_RESETHAND flag is defined, otherwise
we're out of luck unless we're running on a SYSV'ish system where signal()
still has it's old semantics.  Whatever sematics are appropriate for
signal_no_reset(), if we don't have sigaction(), then set_signal() should
use sigvec() instead of signal() on BSD flavored systems.
--
Don "Truck" Lewis                                       TDK Semiconductor
Internet: Don.Lewis@tsc.tdk.com                         138 New Mohawk Road
Phone: +1 916 478-8284       FAX: +1 916 478-8251       Nevada City, CA  95959


From: j@ida.interface-business.de (J Wunsch)
Date: 11 Feb 1997 15:09:42 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: low-cost clocks
[-/+]
X-Keywords: DCF77
[-/+]

Dave Pickles <davep@nugate.demon.co.uk> writes:

>We use a low-cost radio clock which picks up the 60kHz signal from radio
>station MSF in the UK.

The situation is similar in Germany.  The official authority for
measures maintains a radio clock operating at 77.5 kHz (DCF77).  There
are a lot of cheap receivers available, including small PCB sets for
DM 25 (~ US$ 18).  They yield a simple 100ms/200ms pulse at the output
(open-collector) which can be fed directly via a level-converter into
an RS-232 interface running at 50 Bd.  There are refclock
implementations available in xtnpd for this.

> And 60kHz is a noisy part of the radio spectrum in a machine
>room environment; the radio had to be very carefully sited before it would
>work.

Same here, albeit due to the low frequency, the station is receivable
even in Denmark.

--
J"org Wunsch                                           Unix support engineer
joerg_wunsch@interface-business.de       http://www.interface-business.de/~j


From: "Richard Mayston" <R.Mayston@comnet.co.nz> [-/+]
Date: Tue, 11 Feb 1997 04:22:24 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp server for NT server/workstations
[-/+]
X-Keywords: update
[-/+]

Frank Jendraszak <fjj@sashimi.wwa.com> wrote in article
<5dnthv$n1t@shoga.wwa.com>...
> What software can I use to sync my NT machines up with my Unix servers
> which run xntpd?
>
> I am looking for something that will run as a service and not need to be
> executed as a local user, since my local users can not update local time
> on their machines.

Greg Schueman has produced an excellent precompiled/Installshielded kit for
NT, it is available from Larry Kahn's FTP site as ntxntpbin-gui.zip
email access@drcoffsite.com for info on getting it.
regards, Richard Mayston.

--
Richard Mayston         Comnet Technologies Limited
R.Mayston@comnet.co.nz  http://www.comnet.co.nz/maystonr/


From: "schueman" <schueman@ix.netcom.com>
Date: 12 Feb 1997 16:19:11 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp server for NT server/workstations
[-/+]
X-Keywords: Mills
[-/+] Stenn [-/+] update [-/+]

Christopher A. Wichura <caw@cawtech.com> wrote in article
<5dp41p$5uf@selandria.cawtech.com>...
> In article <01bc17cb$432920a0$0501cb83@ns1>,
> Richard Mayston <R.Mayston@comnet.ci.nz> wrote:
> >Frank Jendraszak <fjj@sashimi.wwa.com> wrote in article
> ><5dnthv$n1t@shoga.wwa.com>...
> >> What software can I use to sync my NT machines up with my Unix servers
> >> which run xntpd?
> >Greg Schueman has produced an excellent precompiled/Installshielded kit
for
> >NT, it is available from Larry Kahn's FTP site as ntxntpbin-gui.zip
> >email access@drcoffsite.com for info on getting it.
>
> Um,
>
> I've never understood why this wasn't simply put on louie.udel.edu.
Thus,
> one wouldn't have to answer this same question over and over again, since
it
> would be where time administrators would expect it to be.  It also
wouldn't
> require e-mailing to get access to some machine, which is I think a turn
off
> for some people.
>
> -=> CAW

Simply put, David Mills doesn't want to get into the binary distribution
business,
and I don't blame him.  Larry Kahn has been good enough to host the
binaries,
and so we follow his rules about his site.  He has an ISDN link, which he
uses
for work purposes besides "freeware distribution".

I've just sent email to Harlan Stenn to update the NTP Web site to refer to

ftp.drcoffsite.com as the current place to get source.

BTW, I agree that emailing is a turn off for access, but if it was my ISDN
line
I'd do the same.

-Greg


From: neil@nharris.demon.co.uk (Neil Harris) [-/+]
Date: Fri, 14 Feb 1997 10:44:16 +0000
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: low-cost clocks
[-/+]
X-Keywords: PPS
[-/+] resolution [-/+]

In article <5dvr4c$620@hpindda.cup.hp.com>, dalton@cup.hp.com (David
Dalton) wrote:

>Jay R. Ashworth (jra@scfn.thpl.lib.fl.us) wrote:
>: David Dalton (dalton@cup.hp.com) wrote:
>: : What would you recommend for a low-cost clock for use with NTP in the USA?
>: : In Europe?  Elsewhere?
>
>: Is there something amusing about this inquiry coming from inside the
>: manufacturer of probably the larget number of time standards in the
>: world?  :-)
>
>Let me explain....  It is not for myself that I want this  ;-)
>
>We make the absolute "Cadillac" line of clocks, and even the national
>standards bureaus use them for maintaining references.  The cesium clocks
>cost tens of thousands of dollars (did you know that each GPS satellite has
>an HP cesium beam reference on board?), and the new HP GPS receivers are
>all above $5k.  I have my own HP58503A right here and it is truly
>outstanding.
>
>But many computer customers have accuracy needs that are quite modest,
>anything below 1 second will do fine, and they often balk at the idea of
>spending thousands of dollars more for a clock that delivers far more
>accuracy than they really need.  So I am researching the low-cost-clock
>market in order to have a ready recommendation for such customers.

[snip]

Here's my plan:

Take a Motorola Oncore GPS receiver.  Add RS-232 buffering, and a
'gadget' to output a single-character-length pulse at the leading
edge of the 1pps signal, and AND that into the serial output, with
some extra logic for turning the gadget on and off with the serial
handshake lines.  You now have a clock capable of resolving 25 us
with serial line support only (the limit is the UART clocking on
input). This will act as both a PPS clock and a timestamp clock.

In addition, with Option I installed, you have the ability to
resolve time to about 50 ns from the PPS edge: there is a
systematic sawtooth error of around 500 ns, but this is predictable,
and the expected error is available as a report from the RX.

However, the higher resolution time is only relevant if you want to
sync hardware devices (or if you have a stupendously fast computer).

Progress so far:

Got receivers, boxed, added buffering, made them work as timestamp
clocks, modified xntpd, now adding the 1pps pulse generator.

When I have finished, I intend to make the patches to xntpd public.

Project cost: about $750 per clock.

-- Neil


From: dalton@cup.hp.com (David Dalton) [-/+]
Date: 18 Feb 1997 19:23:09 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: low-cost clocks
[-/+]
X-Keywords: Datum
[-/+] monitor [-/+] rubidium [-/+] USNO [-/+]

Robin Kimberley (robk@oldtimer.win-uk.net) wrote:
:
: In article <5dvr4c$620@hpindda.cup.hp.com>, David Dalton (dalton@cup.hp.com) writes:
: >Jay R. Ashworth (jra@scfn.thpl.lib.fl.us) wrote:
: >: David Dalton (dalton@cup.hp.com) wrote:
: >
: >standards bureaus use them for maintaining references.  The cesium clocks
: >cost tens of thousands of dollars (did you know that each GPS satellite has
: >an HP cesium beam reference on board?), and the new HP GPS receivers are

: Sorry to correct you here my friend, but the GPS Satellites are
: exclusively equipped with Cesium standards manufactured by Datum's
: Frequency and Time Systems Division in Beverly, MA. And guess
: what?, Datum's Bancomm-Timing Division also make excellent Time
: Server products.

Rod is correct, and my faulty memory is showing.  Here is an excerpt from
the excellent article by John Kusters in the 12/96 issue of the HP Journal:

---------------------------
Each satellite carries multiple atomic clocks, either cesium or rubidium,
for redundancy and reliability.

All of the frequency standards at the individual ground reference sites ar
HP 5061A cesium beam frequency standards.  Most of the cesium standards at
the USNO are the newer HP 5071A primary frequency standard.  Many other
sites around the world also monitor GPS on a continuing basis.  Virtually
all of these also use one or both of the HP cesium standard models.
---------------------------

-> My $.02 only.  Not an official statement from HP.
--
    As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton                 dalton@cup.hp.com                 408/447-3016


From: fred@lightside.net (Fred Condo)
Date: Sun, 16 Feb 1997 12:50:29 -0800
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp for mac/w95?

In article <5e59ma$dtq@overload.lbl.gov>, helm@fionn.es.net wrote:

>This seems like something I should be able to answer locally ...
>but I have been unable to.
>
>Is there some kind of client service available for mac os/ windows 95
>personal computers?  Ideally, could handle authenticated time
>from an xntpd-running host.
>
>How do you provide a service like this?  Thanks for any advice, ==mwh
>
>PS "News" isn't perfect. Please
>mailto: helm@fionn.es.net
>any posted replies on this topic.  Thanks.

For Mac, there is a control panel called "Network Time" that works nicely.
--
http://www.lightside.net/~fred/ + net access + http://www.lightside.net/
"Attempts to control the use of encryption technology are wrong in
principle, unworkable in practice, and damaging to the long term economic
value of the information networks." - UK Labour Party


From: Judah Levine <judah.levine@colorado.edu> [-/+]
Date: 19 Feb 1997 17:50:38 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: New time servers and upgrade to existing ones
X-Keywords: ACTS
[-/+] nist [-/+] NIST [-/+]

The National Institute of Standards and Technology and the University of
Colorado announce several new primary time servers and an upgrade to our
existing machines.

  time-a.nist.gov  (129.6.16.35)  (new)
  time-b.nist.gov  (129.6.16.36)  (new)
  Location:  NIST Central Computer Facility, Gaithersburg, Maryland
  Synchronization:  ACTS dial-up using lockclock algorithm, DEC Alpha/UNIX
  Service Area:  NSFnet, SURAnet
  Access Policy:  Open to stratum-2 servers, others by arrangement; please
                  use one of the servers as primary with the other as
                  a backup.
  Contact:  Judah Levine (jlevine@boulder.nist.gov) 303 492 7785

  time-a.timefreq.bldrdoc.gov (132.163.135.130)  (upgrade)
  time-b.timefreq.bldrdoc.gov (132.163.135.131)  (new)
  Location: NIST Boulder Laboratories, Boulder, Colorado
  Synchronization:  Direct 1 pps from clock ensemble; lockclock algorithm
                    and ACTS dial-up as backup; DEC Alpha/UNIX
  Service Area:  NSFnet, WESTnet
  Access Policy:  Open to stratum-2 servers, others by arrangement; please
                  use only one of the servers as primary with the other
                  as a backup.
  Contact:  Judah Levine (jlevine@boulder.nist.gov) 303 492 7785

  utcnist.colorado.edu (128.138.140.44) (new)
  Location: JILA Laboratory, University of Colorado at Boulder
  Synchronization: ACTS dial-up using lockclock algorithm; DEC Alpha/UNIX
  Service Area: NSFnet, WESTnet
  Access Policy: Open to stratum-2 servers, others by arrangement
  Contact:  Judah Levine (jlevine@boulder.nist.gov) 303 492 7785

  time.nist.gov (192.43.244.18) (upgrade)
  Location: National Center for Atmospheric Research, Boulder, Colorado
  Geographic Coordinates: 39:58:43.44N 254:43:32.5E +1840m (WGS 84)
  Synchronization:  ACTS dial-up with NTP backup, DEC Alpha/UNIX
  Service Area: NSFnet, WESTnet
  Access Policy: open to stratum-2 servers and others by arrangement
  Contact:  Judah levine (jlevine@time.nist.gov), (303) 492-7785

  utcnist.microsoft.com (131.107.1.10) (alias name: time-nw.nist.gov) (upgrade)
  Location: Microsoft Corporation, Redmond, Washington
  Synchronization:  ACTS Dial-up and lockclock algorithm, DEC Unix
  Service Area: NorthWestNet, NSFnet
  Access policy:  open to stratum-2 servers and others by arrangement.
  Contact: Judah Levine (jlevine@time-a.timefreq.bldrdoc.gov) (303) 492-7785

  The lockclock algorithm that is used to synchronize the servers is
described in, "An algorithm to synchronize the time of a computer to
Universal Time," IEEE/ACM Transaction on Networking, Vol. 3, pp 42-50, 2/1995.
  In addition to providing NTP stratum-1 service, all of the servers
will respond to requests in a number of other formats.  Additional
information and client software for these other services is available from
any of them via anonymous ftp.
  These servers are supported with funds from NIST and from the National
Science Foundation through the University of Colorado.


From: Bob Winingham <kc5ejk@onramp.net>
Date: 22 Feb 1997 04:41:36 GMT
[-/+]
Newsgroups: rec.radio.amateur.homebrew,comp.protocols.time.ntp,alt.comp.hardware.pc-homebuilt
Subject: Re: Time machine?

>Does anyone know of a kit or schematics to build a radio time reciver?
>had a serial port for your PC ... Heath.....

A GPS unit from your friendly Marine boat store will work better
and cost less. ALSO The Tripmate unit comes with street Atlas and GPS
all for about $115-$130

73


From: Lyndon David <lyndond@sentinet.co.uk>
Date: Sat, 22 Feb 1997 17:35:01 +0000
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Cheap radio clock for UK MSF
[-/+]

Dear All in UK,

In the Maplin Electronics catalogue are two MSF time decoders.
The cheaper one is called CH52 time-date ARC clock and is supplied
with some naff windows program to set the time on a PC. The good
point is that it is only 60 quid plus VAT. Although it is distributed
by Galleon in the UK (http://www.solnet.co.uk/galleon) the unit
when it arrived is actually make by NHK Elektronik.

A fax from Galleon gives the serial protocol for the thing. Basically
send it the character o plus a CR and at the start of the next
second it starts transmitting 15 characters at 300 baud with the
time, date and some status info, and so it does.

Does anyone know anything about this unit, especially, any C code
out there? Does anyone know if any of the drivers already in the
ntp distribution works with this clock? At 60 quid this must be
the cheapest serial MSF clock around other than build your own.

Any info much appreciated

Lyndon David


From: "John M. Franke" <j.m.franke@larc.nasa.gov>
Date: Fri, 21 Feb 1997 17:46:17 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: low-cost clocks
[-/+]
X-Keywords: Garmin
[-/+]

For a less expensive but similar project using either the Motorola
Oncore or the Garmin GPS-20 see:
http://www.tapr.org/tapr/html/tac2.html


From: Dave Pickles <davep@nugate.demon.co.uk> [-/+]
Date: Sun, 23 Feb 1997 20:41:44 +0000
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap radio clock for UK MSF
[-/+]

In article: <330F2E45.5650@sentinet.co.uk>  Lyndon David
<lyndond@sentinet.co.uk> writes:
>
> Dear All in UK,
>
> In the Maplin Electronics catalogue are two MSF time decoders.
> The cheaper one is called CH52 time-date ARC clock and is supplied
> with some naff windows program to set the time on a PC. The good
> point is that it is only 60 quid plus VAT. Although it is distributed
> by Galleon in the UK (http://www.solnet.co.uk/galleon) the unit
> when it arrived is actually make by NHK Elektronik.
>
> A fax from Galleon gives the serial protocol for the thing. Basically
> send it the character o plus a CR and at the start of the next
> second it starts transmitting 15 characters at 300 baud with the
> time, date and some status info, and so it does.
>
> Does anyone know anything about this unit, especially, any C code
> out there? Does anyone know if any of the drivers already in the
> ntp distribution works with this clock? At 60 quid this must be
> the cheapest serial MSF clock around other than build your own.
>
> Any info much appreciated
>
> Lyndon David

We're using that model with it's supplied NT driver software to synchronise an
NT box, then running xntpd on the same box to sync the unix kit. It's working
to a total accuracy of a fraction of a second which is good enough for us,
though of course an xntpd driver would be more elegant.

Be aware if you extend the serial lead you will need to cable up all nine
pins. We needed a _long_ extension to get the radio away from the interference
in our machine room.
--
Dave Pickles


From: Jim Reid <jim@pc37.mpn.cp.philips.com> [-/+]
Date: 24 Feb 1997 11:16:00 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap radio clock for UK MSF
[-/+]

Lyndon David <lyndond@sentinet.co.uk> writes:

> In the Maplin Electronics catalogue are two MSF time decoders.
> The cheaper one is called CH52 time-date ARC clock and is supplied
> with some naff windows program to set the time on a PC. The good
> point is that it is only 60 quid plus VAT.
>
> Does anyone know anything about this unit, especially, any C code
> out there? Does anyone know if any of the drivers already in the
> ntp distribution works with this clock? At 60 quid this must be
> the cheapest serial MSF clock around other than build your own.

Be very wary of cheap MSF clocks. My experience with them is that you
get what you pay for. Some years ago, I supervised a student project
which tried to interface a 50 quid or so MSF receiver to a Multibus
UNIX box. The receiver didn't work well. It picked up the signal OK
in the student's house - so he claimed - but had real problems in the
Computer Science Dept. The lab was noisy - lots of EMI - and if
someone or something crossed in front of the aerial, it would take
hours before it locked on to the signal again. If it ever did....

When I tried a professional quality clock costing ~ GBP3000 it worked
just fine. Receiving MSF reliably needs a decent aerial which is
immune to EMI from computer clocks and the like. This is where hobby
kits fall down: my electronics friends tell me that you can't buy the
bits for a specially tuned aerial for 60 quid.

A kit might be OK for hobby use, but if you need a dependable time
source, this approach is probably not a good idea.

Don't forget the frequent outages of the MSF signal either. They
switch off the transmitter one morning a month for maintenance and
also for a couple of weeks in the summer. Ho hum.


From: sam@cs.stir.ac.uk (Sam Nelson) [-/+]
Date: 25 Feb 1997 11:28:23 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap radio clock for UK MSF
[-/+]

In article <330F2E45.5650@sentinet.co.uk>, Lyndon David <lyndond@sentinet.co.uk> writes:
| point is that it is only 60 quid plus VAT. Although it is distributed
| by Galleon in the UK (http://www.solnet.co.uk/galleon) the unit
| when it arrived is actually make by NHK Elektronik.
|
Unfortunately it doesn't offer very good-quality time: +/-10ms or so for any
given timestamp.  NTP available over the net now is better than that, unless
your link is pretty poor.

| A fax from Galleon gives the serial protocol for the thing. Basically
| send it the character o plus a CR and at the start of the next
| second it starts transmitting 15 characters at 300 baud with the
| time, date and some status info, and so it does.
|
| Does anyone know anything about this unit, especially, any C code
| out there? Does anyone know if any of the drivers already in the
| ntp distribution works with this clock? At 60 quid this must be
| the cheapest serial MSF clock around other than build your own.
|
I wrote some stuff to exercise it a bit and I'm less than impressed.  It has
a habit of dropping the front end or the back end of the timestamp string, for
one thing, and once it loses radio contact with its source you tend to have to
play around with it for quite a while to get it back.  I phoned them up to ask
for NT drivers, and they wanted two or three times the price of the hardware
for it.  For the price of the clock+driver package, you could get the Oncore
GPS from Maplin, use XNTP drivers already in existence and get far better time
out of that.

The `desktop RAT' version is quite a pretty clock, but it's little more than a
desktop ornament for anyone with a decent net link and XNTP.

--
Sam.          Scunthorpe!          (Insert bandwidth-wasting disclaimer here)
          To call something blue when it's not we defile it,
          But oh what the heck, it's hard to rhyme 'violet'.


From: kaukasoi@elektroni.ee.tut.fi (Petri Kaukasoina)
Date: 24 Feb 1997 07:23:09 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp 3-5.89 broken with UnixWare 2.1.1
[-/+]

Joe Doupnik <jrd@cc.usu.edu> wrote:
>       When will people fix the Makefiles to not use -g for the CCFLAGS
>and instead use -O? I am not using gcc but rather the vendor's stock cc
>complier. I don't want -g (debug); I don't want any debugging code hogging
>memory. To fix this I hand edit config.h and at the top put in CCFLAGS=-O.

Or:

env CC=cc CFLAGS=-O LDFLAGS=-s ./configure --options-for-configure


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 24 Feb 1997 12:30:53 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp 3-5.89 broken with UnixWare 2.1.1
[-/+]
X-Keywords: auth
[-/+] configuration [-/+]

"enable auth" is now default. Maybe you have an illegal configuration?
Maybe you need a ntp.keys file and a few more parameters in ntp.conf...

--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 24 Feb 1997 12:34:46 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: maxslew & loopfilter behaviour
X-Keywords: adjustment
[-/+] loopfilter [-/+]

In article <E633Gz.7o7@echelon.nl> kees@echelon.nl (Kees Hendrikse) writes:

> Why does the value of tvu_maxslew (the maximum doable adjustment in one
> adjustment interval) change the behaviour of the loopfilter in xntpd?

Your statement is not very precise, but there is a maximum frequency
drift that can be compensated. This depends on the tickadj value. if
you are below +-50ppm of drift, the small default value (1) is fine,
but if you have a very bad PC board (with maybe 130ppm drift) you'll
have to increase tickadj, or modify tick in the kernel.

When I say "drift" I really mean "skew"...

Ulrich


From: "Edward J. Huff" <huffe@carbon.chem.nyu.edu> [-/+]
Date: Mon, 24 Feb 1997 16:18:44 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp 3-5.89.5

Sebastien Korner wrote:
>
> Hello all,
>
> Recently someone said they had compiled xntp version 3-5.89.5
> on their IRIX 6.1 machine, and it was working (except for too
> many SYSLOG messages).  Does anyone know where I can get this
> version?  The site I go to only has up to 3-5.89!

ftp://louie.udel.edu/pub/ntp/testing/

See also

http://www.eecis.udel.edu/~ntp/
http://www.yahoo.com/Computers_and_Internet/
Software/Protocols/NTP___Network_Time_Protocol/

--
huffe@carbon.chem.nyu.edu (Edward J. Huff) 212-998-8465


From: Herman Chien <herman.chien@attws.com>
Date: Mon, 24 Feb 1997 22:52:45 -0700
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS network time servers...
X-Keywords: antenna
[-/+] Datum [-/+] documentation [-/+] stability [-/+]

What a coincidence. It looks like others have virtually the same
question that I have...

I've been surveying rack-mounted time server units that feature a GPS
antenna, SNMP-manageability, "high" intrinsic oscillator stability (at
least substantially better than typical workstations) and NTP over a
10MB LAN interface.

I've looked at Datum (TymServe 2100) and Truetime (NTS-100 and XL-DC)
products that seem to fit. Depending on the oscillator quality and other
bells and whistles, they run anywhere from about $4K to $10K.

I'd appreciate hearing comments from others that may have used these
products on their reliability, NTP compatibility, documentation, and
tech support. Please advise if there are other brands I ought to be
considering.

Thanks.

==> I am using a borrowed account. Please make sure you are replying to
herman.chien@attws.com if I it turns out that I haven't adequately
tinkered with the borrowed account's settings.

==> I have recently received some comments about the models mentioned
above. Please email me directly and I will forward them to you (MIS
paranoia prevents me from speaking/posting freely).

--herman

=====================================================================Herman
Chien                     Voice: (206) 990-4628
AT&T Wireless Services           Fax:   (206) 990-4200
Messaging Division               email: herman.chien@attws.com
110 110th Ave. N.E., Suite 200
Bellevue, WA 98004
=====================================================================


From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 25 Feb 1997 12:12:07 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: MSNTP 1.3 (portable SNTP client/server, currently Unix)

Version 1.3 of MSNTP is available in dist/msntp-1.3.tar.gz (48K
bytes) on oozelum.csi.cam.ac.uk (log in as anonymous).  I have
improved the robustness over 1.2, and added an optional
restarting file for daemon mode.  It has been running for a
couple of weeks on a system with 57 ppm drift connected to a
stratum 3 server over a network with a dicky repeater, and kept
the error wrt UTC to under 0.2 seconds with 5 packets a day.

Thanks to everybody who has helped with comments and trying it
out on other systems.  This is probably the last version that I
shall produce, as it does everything that I need.  If anyone
produces a version for non-Unix systems, I MAY merge in the
changes, or I may just send them off to comp.sources.whatever.

Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 25 Feb 1997 17:49:03 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: leap second 1997 June 30 23:59:60
X-Keywords: IERS
[-/+] TAI [-/+]

Howdy,
  IERS has announced that there will be a leap second 1997 June 30 23:59:60.

  I first noticed the report on http://tycho.usno.navy.mil
and then checked ftp://hpvbli.obspm.fr/iers/bul/bulc/bulletinc.13.

  The detailed section is:

>    A positive leap second will be introduced at the end of June 1997.
>    The sequence of dates of the UTC second markers will be:
>
>                        1997 June       30,    23h 59mn 59s
>                        1997 June       30,    23h 59mn 60s
>                        1997 July        1,     0h  0mn  0s
>
>    The difference between UTC and the International Atomic Time TAI is:
>      from 1996 January 1, 0h UTC, until 1997 July 1, 0h UTC: UTC-TAI = - 30s
>      from 1997 July 1, 0h UTC, until further notice        : UTC-TAI = - 31s

(with a few blank lines removed)

Bruce Bartram       bbartram@etl.noaa.gov


From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 26 Feb 1997 15:08:48 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Does xntp3-5.89.8 work for you?

The problem with a greater than 300ppm drift can be solved by
adjusting the tick value if you have at least 50 interrupts per
second. (HZ * tick == 1s. If HZ is too high, use a smaller tick)

--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>


From: "Marcus N. Morgan" <nemnm@nersp.nerdc.ufl.edu>
Date: Thu, 27 Feb 1997 09:09:36 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: IRIG-B BSD Audio Driver

I asked this question a couple of months ago and got no response.
Probably the answer is "no".  I installed the irig_audio code
on a sparc station ipx running sunos 4.1.3u1b and am very happy
with it.  I can give you updated patches should you want them.
(note that this runs on sun4c kernel only).
-Marcus

Amy Drew wrote:
>
> Does anyone know if the BSD audio driver for SunOs 4.*
> has been modified for Solaris 2.5.*, and if one does
> exist where can it be found?
>
> Thanks,
> Amy Drew
> adrew@csc.com

--
Marcus N. Morgan
nemnm@nersp.nerdc.ufl.edu
(352) 392-2061  suncomm 622-2061


Next part