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

Chuck Swiger cswiger at mac.com
Thu Apr 15 00:48:51 UTC 2010

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.

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.

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


[1]: HPET should be userland-visible (if you have it, your BIOS makes it available and ACPI maps it into memory which is exposed to userland), and there's also rdtsc(), but if it's not power-state invariant (and sync'ed between CPUs on SMP boxes), you're more likely to obtain remarkably inconsistent results than useful timing from it.

More information about the questions mailing list