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

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

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