andreas@planix.com (Andreas Wrede) writes:
> Is anyone using ntp refclocks that make use of kernel pps?

Kernel pps yes, ntp no.  I see the same problems with ntp that you do.

I did get a small PPS program (essentially lifted from "RFC 2783,
Pulse-Per-Second API, March 2000" running under -current.

One thing I noticed was that the CLEAR/ASSERT settings were reversed.
One I inverted the test, I do get a stream of PPS reports as such:

 Clear timestamp: 958156930.999696000, sequence: 419
 Clear timestamp: 958156931.999696000, sequence: 420
 Clear timestamp: 958156932.999697000, sequence: 421
 Clear timestamp: 958156933.999698000, sequence: 422
 Clear timestamp: 958156934.999695000, sequence: 423
 Clear timestamp: 958156935.999695000, sequence: 424
 Clear timestamp: 958156936.999696000, sequence: 425
 Clear timestamp: 958156937.999696000, sequence: 426
 Clear timestamp: 958156938.999695000, sequence: 427
 Clear timestamp: 958156939.999696000, sequence: 428
 Clear timestamp: 958156940.999695000, sequence: 429
 Clear timestamp: 958156941.999695000, sequence: 430
 Clear timestamp: 958156942.999697000, sequence: 431
 Clear timestamp: 958156943.999697000, sequence: 432
 Clear timestamp: 958156944.999698000, sequence: 433
 Clear timestamp: 958156945.999695000, sequence: 434
 Clear timestamp: 958156946.999695000, sequence: 435
 Clear timestamp: 958156947.999695000, sequence: 436
 Clear timestamp: 958156948.999695000, sequence: 437

Notice that the nS part of the timestamp is always 0.  

I'm concerned that most of the advantage of using a GPS with a few
10's of nS of noise on it PPS line will be lost if the kernel proceeds
to timestamp things with only 1uS of resolution.

Anyone know how the other open source folks do this?  Do they grab the
higher frequency information from the CPU's tick-counter register?

-wolfgang
-- 
       Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
DGPS signals via the Internet  http://www.wsrcc.com/wolfgang/gps/dgps-ip.html