I think several people seem to have lost track of what's discussed
here.  So time for some background:

The basic issue is providing good MI support for precision NTP
timekeeping with radio clocks.  The common case is GPS clocks with a
pulse-per-second (PPS) signal.

The goal is to keep good time. Most GPS devices emit an rs-232 serial
stream with some kind of tiemstamp format.  Many GPS devices are small
realtime systems with the satellite tracking done at high priority,
positioning done at medium priority, and time output done at low
priority.  The timestamps often have +- 200 ms of jitter (variance in
delay), and output a Pulse-Per-Second (pps) signal on thee exact
second.  To use these devices for NTP, getting the PPS signal into the
kernel is of high importance.  That was the key point to solve.

There are two standard ways to do this. The first is to use a PC-style
parallel port and feed the PPS signal in, triggering an interrupt.

The second is to hook the PPS signal up to the modem lead of an
orndinary serial port. The modem change triggers an interrupt, and its
very simple and straighforward (and clean and maintainable &c) to take
a timestamp when the carrier-detect signal cahnges.  This is
well-established technology; it must be going on a decade old
now. FreeBSD has had it for ages.  the xntpd softare good support for
PPS. Even teh netbsd kernel has support for PPS, which is still
waiting on getting PPS hooks into a suitable driver.

This thread started when I posted a patch which should add PPS
functionality to NetBSD, with a sample implementation for the com
driver, and asked for feedback on it.  I'm still waiting for
constructive feedback on that patch. There hasn't been any.  I wish I
knew why.  It seems like a good solution, and I would genuinely
appreciate feedback on it.  I doubt my implementation even works
properly and I'm sure Charles Hannum could fix it in a moment: it
should be pretty simple since com drivers already handle carrier
detection.  I said as much earlier this week, and asked someone to
send it to Charles.

Instead, discussion has focused on a different, separate, but still
NTP-related issue: how to get better timestamping for older radio
clocks, like the CHU `gadget box', which do *not* provide a PPS
signal.  The idea here was ways of getting betetr timestamps of every
input character, for these older clocks.  That *is* a side issue, as
has been said several times.  As I said in an earlier message:

>From: Jonathan Stone <jonathan@dsg.stanford.edu>
>To: Jukka Marin <jmarin@pyy.jmp.fi>
>Cc: Dennis Ferguson <dennis@juniper.net>
>Cc: Bill Studenmund <wrstuden@loki.stanford.edu>, tech-kern@NetBSD.ORG
>Subject: Re: NTP pulse-per-second timestamp diff
>In-Reply-To: <19980327083722.50899@pyy.jmp.fi>
>

[snip]

>
>And again: For the special case of x86 and a GPS with PPS, just using
>the parallel port for PPS (or the DCD timestamp patch) is good enough.
>And though this is cool stuff to timevultures, I'm still not convinced
>the population of radio-clock users is big enough to justify this.
>Unfortuntely, till now NetBSD hasnt had adequate support for radio
>clocks, so the interested people are all off using some other OS, so
>theres really no way to tell.

Here, the ``cool stuff'' was *not* TIODCDTIMESTAMP patch; i was
referring to is the *non-PPS* timestamping Ken Hornstein and Dennis
Ferguson and I were discussing.  Once again, for those who are still
confused:

       __The support for non-PPS clocks is a side issue__.

I am, I think justifiably, completely fed up with being repeatedly
flamed about a side issue.  I was hoping for discussion of the
TIOCDCDTIMESTAMP patch.

It's even more frustrating to be accused of flaming, and to be flamed
to a crisp in turn, simply for mentioning the relative performance of
NetBSD and FreeBSD at servicing interrupts on i386, using data from
web pages and from my own lab notebook. I didn't intend that as a
flame; it's just a fact.  
I would like to stick to the technical issues.  Can we *please* get
back to discussing the TIOCDCDTIMETAMP patch?  Here it is again:

Index: com.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/com.c,v
retrieving revision 1.143
diff -c -r1.143 com.c
*** com.c	1998/03/22 00:55:37	1.143
--- com.c	1998/03/26 02:47:39
***************
*** 603,608 ****
--- 603,609 ----
  		com_modem(sc, 0);
  		(void) tsleep(sc, TTIPRI, ttclos, hz);
  	}
+ 	sc->sc_dcd_timestamping = 0;
  
  	/* Turn off interrupts. */
  #ifdef DDB
***************
*** 933,938 ****
--- 934,943 ----
  		*(int *)data = bits;
  		break;
  	}
+ 	case TIOCDCDTIMESTAMP:
+ 		com->sc_dcd_timestamping = 1;
+ 		*(struct timeval *)data = com->dcd_timestamp;
+ 		break;
  	default:
  		error = ENOTTY;
  		break;
***************
*** 1749,1754 ****
--- 1754,1763 ----
  		sc->sc_msr = msr;
  		if (ISSET(delta, sc->sc_msr_mask)) {
  			SET(sc->sc_msr_delta, delta);
+ 
+ 			if (sc->sc_dcd_timestamping && ISSET(delta, MSR_DCD)) {
+ 				microtime(&sc->sc_dcd_timestamp);
+ 			}
  
  			/*
  			 * Stop output immediately if we lose the output
Index: comvar.h
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/comvar.h,v
retrieving revision 1.22
diff -c -r1.22 comvar.h
*** comvar.h	1998/02/02 23:01:05	1.22
--- comvar.h	1998/03/26 02:55:02
***************
*** 109,114 ****
--- 109,117 ----
  	void (*disable) __P((struct com_softc *));
  	int enabled;
  
+ 	int	sc_dcd_timestamping;		/* boolean flag */
+ 	struct timeval	sc_dcd_timestamp;
+ 
  #if NRND > 0 && defined(RND_COM)
  	rndsource_element_t  rnd_source;
  #endif



now, can somebody give me a sane, rational, technical explanation of
where this is adding ``too much cruft'' to the serial driver?


I'd prefer to keep the other disucssion, the one about non-PPS
timekeeping and using the line disciplines shipped with the standard
xntpd distribution, in a separate thread.  That would stop anyone who
isn't intimately familiar with NTP from getting them confused.
Personally, I'd welcome any useful, relevant, and to-the-point
technical discussion on either one.

But if, for example, you can't see numbers from public websites that
dont' show NetBSD in an especially good light compared to its rivals,
without taking that as a personal attack and flaming about it, please
don't participate.

Similarly, anyone who tells the author of the "foundation code of
xntpd" that the idea they're proposing is ``fundamentally
incompatible'' with good NTP design, is (a) going to look bloody
stupid, and (b) is unlikely to be taken seriously on NTP-related
matters ever again. I for one have no patience left for more
egregiously wrong `corrections' like that.