From:	"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de>
To:	linux-kernel@vger.rutgers.edu
Date:	Fri, 14 May 1999 08:22:57 +0200
Subject: for review: PPS API implementation (2.2.7)

Hello,

I have put PPSkit-0.7-pre3.diff.gz, a patch against Linux 2.2.7, on 
linux.kernel.org/pub/linux/daemons/ntp/PPS.

The patch implements (as most of you know already) nanosecond time 
resolution, updated NTP algorithms,AND an implementation of the  
Internet draft for a PPS API.

The PPS API is a portable interface to event timing. Specifically you 
can get rising and falling edges of some signal with high accuracy 
(getting a struct timespec). I have implemented it for the serial 
port's carrier detect input.

I have also implemented the time_pps_wait() function. As it is my 
first try to do scheduling, wait_queue and interrupt stuff, I'd 
kindly ask some guru to have a look at the code. For me it just seems 
to work.

In addition I have an other issue: The routines to fetch the 
timestamp disable interrupts to ensure that the timestamp is 
consistent. Now if you busily poll for events, interrupts are 
disabled frequently (for a short while). This will reduce the 
accuracy of the time stamps. Now I wonder if I can or should use 
spinlocks instead. IMHO they could smooth things a bit. But is it 
safe for an interrupt service routine?

For those who prefer had numbers:
My Pentium-100 can resolve time up to roughly 2us. With a GPS 
reference with a nominal accuracy of 250ns ntpd-4.0.92h says after 
some time "estimated error 0 us". If fact the peak estimate was 17ns, 
but more realistic is 800ns, and 5us is easy to get. (Now you can 
compare with your numbers)

In addition three new POSIX.4 functions (clock_gettime, 
clock_settime, clock_getres) are ready to be made available to 
applications. They are used already internally.

With version 0.7 of PPSkit I have fulfilled all the plans for this 
year.  A remaining issue is precision timing for SMP, but I don't 
have the hardware nor experience.

Those maintainers of non-i386 architectures are kindly requested to 
try the patch and (preferredly) submit patches, fixes, contributions, 
...

I think the stuff is very close to be integrated into the mainstream 
kernel.

Regards,
Ulrich
P.S. Please CC: replies as I'm not subscribed to this list


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/