[ntp:questions] Building FreeBSD V8.0 kernel for PPS

unruh unruh at wormhole.physics.ubc.ca
Thu Apr 15 04:51:07 UTC 2010

On 2010-04-15, Chuck Swiger <cswiger at mac.com> wrote:
> On Apr 14, 2010, at 2:15 PM, unruh wrote:
>> On 2010-04-14, Chuck Swiger <cswiger at mac.com> wrote:
>>> The main point seems to be that a PPS signal should have much more reliable latency and less jitter, so when you examine the current clock and any adjustment, you can use the PPS signal offset instead of the offset being provided to adjtime() and get better results, assuming the clock is already relatively close to accurate time. [1]
>> ??? Interrupt processing on say a serial or parallel interrups is in the
>> 1usec regime. HOw much better are you claiming that the kernel PPS is?
>> Seems to me it uses exactly the same serial or parallel interrupts. 
> Kernel PPS_SYNC discipline is capable of providing around +/- 120 nanosecond accuracy.
> While an ethernet packet containing NTP timestamps might well fire off an interrupt from the NIC, not only is the network ISR a lot more complicated and slower than fielding an interrupt from the serial or parallel port, there's also no guarantee that ntpd running in userland will immediately receive and process this information.  For another thing, modern NICs tend to do some degree of interrupt mitigation, which adds delay.

No I meant serial or parallel port interrupts. The standard drivers for
these will process the interrupts and you can time stamp them. Or you
can write a module for, say, the parallel port whose purpose is to time
stamp the receipt of the PPS signal.  I am not talking about a NIC (not
sure how you would sent a PPS signal to a NIC.
Modules can be compiled without compiling the kernel-- a lot lot easier
to do.

> If that's not what you meant, I'm forced to admit that whatever you're saying is confusing me.  :-)
>>> Search for PPS_SYNC in:
>>>  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_ntptime.c?rev=
>>> ...especially hardpps().
>> It looks like he tries to impliment the FLL or PLL loops in kernel
>> space, which is really not clear to me that it belongs there. Once you
>> have the timestamped PPS input, there is no need to do the rest of the
>> calculation in kernel space. 
> If you need to be in the kernel to have access to your local clock hardware, whether it be ACPI, HPET, 8254, or some other architecture's mechanism [1], and you care enough about timekeeping precision to try and make sure you've got valid clock data (ie, you test that the clock data is monotonically increasing when you read it), then you might conclude it makes sense to deal with your high-precision timing in just such a context.

But there are kernel calls (gettimeofday, adjtimex,...) which will
access precisely those needed aspects of the kernel. 
I am not arguing that the kernel should not have any timing functions in
it, just that PPS handling need not be there. 

> For the sake of reference, here's some data PHK measured some years back for the time required to read various clock sources:
> 		TSC		ACPI-fast	HPET		i8254
> dual Xeon:	580 nsec	1429 nsec	1120 nsec	3980 nsec
> dual Opteron:	212 nsec	1270 nsec	1760 nsec	4420 nsec


> Regards,

More information about the questions mailing list