David Schleef wrote:
>
> On Tue, Oct 10, 2000 at 11:44:21AM +1100, William J. Tango wrote:
> > Cort Dougan wrote:
> > >
> > > Where do you xntp from? Are you getting your NTP data from another machine
> > > on the same network or a device that does NTP? It might be worth adding
> > > your own RTLinux clock module that does the NTP itself and nudges its own
> > > clock that has an offset from CLOCK_REALTIME.
> >
> > Time will come from our observatory Master Clock (a Datum GPS clock).
> > Time
> > is distributed via a Datum TymServe dedicated NTP server.
>
> Your accuracy will never be better than 1/2 of the round trip
> time to the NTP server. You get a lot better accuracy from a
> pulse-per-second clock attached to the serial port, but even then
> you are limited by interrupt latency.
>
> Interrupt latency can, of course, be fixed by using real-time
> interrupts, but then you are still limited by the latency of the
> serial port and all the interesting things involved there. This
> should get you to about 10-50 usec resolution.
>
> Best is to have a PPS clock on the serial port that _also_ has a
> TTL pulse that can be connected to the parallel port or a digital
> input on a data acquisition card. In this case, you can set up
> a real-time task that is scheduled right before the turn of the
> second, and busy wait for the pulse to come in, and time-stamp
> it right away. This should get you to about 1-5 usec, slightly
> better for a good PCI DAQ card.
>
> If you need even better than that, you need to start thinking
> about better ways to do timestamping. One method is to use timed
> digital input on a _fast_ DAQ card -- this will give you an
> implicit timestamp with accurate 100 nsec-ish resolution, both
> for hardware and software, albeit with a *lot* of post-processing.
> Better would be to have a dedicated hardware timestamper. I
> *think* you could mangle/convince a NI PCI-DIO-32HS (a.k.a. PCI-6503)
> into doing this, but not as well as a dedicated ASIC. (Don't
> know of any.) Using this method, you don't get your timestamps
> immediately, but after a bit of post-processing. Usually this
> doesn't matter a great deal -- certainly not for NTP. (Note:
> there are many other problems getting sub-usec accuracy from
> a clock -- this paragraph was more about better precision.)
>
> The second issue is how to discipline the correct clock, so
> you can actually _use_ your timestamps. In any case, as it
> currently stands, the implementation of the system clock in Linux
> is accurate only within the worst-case interrupt latency. I've
> developed and am running a patch that fixes this, and disciplines
> directly to the Pentium TSC, which eliminates the interrupt
> latency issues, and also makes do_gettimeofday() real-time safe,
> so you can have access to decent timing from a real-time task.
> As for performance, I don't have access to a reference clock,
> so I've only performed tests disciplining the system clock
> to the RTC PPS. It seems as though this clears up one of
> the limitations to getting to the usec scale.
>
> Also, the patch makes Linux timekeeping very modular (at least,
> on i386), so it would be relatively easy to use a hardware
> timestamper as a system clock, or to discipline the timer on
> a data acquisition board. (I've used the timer on a National
> Instruments AT-MIO E Series board as a system clock, synchronized
> via NTP. =) )
>
> If I had the time to clean up the patch, I would release it,
> since it works fine on 2.2, 2.4, SMP, RTLinux, RTAI... etc.
>
> dave...
Dave,
Our master clock is located in our control room and propagation delays
are < 100 ns.
All tasks are interrupt driven, with the interrupt signals derived
directly
from the clock's master oscillator (which is a high stability quartz
oscillator directly disciplined by GPS). At the moment we use 20+
single-board 86k computers and the clock signals are connected directly
to the interrupt pins on the 68k boards. The computers are slow and
obsolete, hence the desire to replace them with RTL boxes.
Our control system has been deliberately designed to mimimize the
necessity
of knowing the true time (or "epoch" in astronomical jargon). For
example,
where possible we implement rate servos rather than position servos,
since
the rates change slowly with time.
We need to know the epoch (a) for time-stamping data and (b) one
critical
control system. I was planning to use NTP and the 1 PPS interrupt, and
would be very interested in your patches.
Bill
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
