Re: kern/42742 (Would like Juniper Networks PCI card added to PCI device data)

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

The following reply was made to PR kern/42742; it has been noted by GNATS.

From: Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 hubertf%NetBSD.org@localhost
Subject: Re: kern/42742 (Would like Juniper Networks PCI card added to PCI 
device data)
Date: Wed, 10 Feb 2010 12:31:42 +0800

 On 10 Feb 2010, at 07:15 , hubertf%NetBSD.org@localhost wrote:
 Synopsis: Would like Juniper Networks PCI card added to PCI device data
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: hubertf%NetBSD.org@localhost
 > State-Changed-When: Tue, 09 Feb 2010 23:15:06 +0000
 > State-Changed-Why:
 > Added, thanks!
 > 
 > - Hubert
 > 
 > P.S.: Out of curiosity, what kind of card is that?
 
 Thanks very much, the merge conflicts (and forgetting to fix them
 before rebuilding) were driving me up the wall.
 
 The board is an interface to, e.g. a GPS receiver.  It takes the
 PPS signal and the 5 or 10 MHz frequency output from the receiver
 and produces time, available for sampling from the system, which is
 within 3 ns of the external time source once you get all the delays
 sorted out properly.
 
 I'm using it to figure out how to do a clock adjustment system call
 interface to keep the system clock really precise without a lot of
 overhead, building on the timecounter infrastructure; I can now keep
 the (CPU cycle counter based) clock in the amd64 systems I'm developing
 on within 10 ns of the board by comparing the system clock to the board
 clock 4 times per second and making an adjustment every 8 seconds on
 average, with the sampling and filtering logic running in a user space
 program rather than inside the kernel.  It is also very neat for NTP and
 IEEE 1588 development since putting a board in the client synchronized to
 the same external source as the server gives you a way to independently
 measure the performance of the network time transfer rather than
 depending on the implementation to grade its own homework.  I have
 some reason to think that sub-100 ns synchronization will cost only
 an NTP poll per second and an adjustment every 30-60 seconds; the
 current NTP implementation has trouble keeping the clock within 50 us
 even with a high polling rate and with all that logic in the kernel
 computing adjustments every clock tick.
 
 That's probably more than you wanted to know.
 
 Thanks again,
 Dennis