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...
-- [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/
