I don't know this API. But my first reaction when I saw the designation "PPS" is to think of GPS timekeeping boxes and other precision frequency sources that have a PPS output. On those devices, the PPS output is divided down from the main oscillator frequency, i.e., you can expect accuracies of 10^-9 for modest price crystal oscillators, 10^-10 to 10^-12 for higher end stuff -- and jitter in the nanosecond range or better. Yes, I have a GPS receiver with a precise pps signal inside that hooks it up to DCD on a pl2303 usb/serial chip. You can't expect 1 ns; typically GPS receivers are specified to something closer to 50 ns. The receiver I'm using is specifided at 30 ns RMS (before USB). As for the API, see RFC2783, which explicitly conceptually supports arbitrary sources. Other than the fact that there's ~1ms of USB fuzz (vs unknown (but ~surely better) serial port behavior), this is the same thing as serial pps. As to enabling it, to use this one either has to to write a program to use the time_pps interface in <sys/timepps.h>, or make a symlink in /dev and add a line to ntpd, which requires searching the web to find documentation. This isn't the sort of thing that happens by accident. And "enabling it" simply means that a user-space program can get timestamps -- it doesn't set the clock, unless one calls a further API procedure (which the spec says is privileged). It's not like this is changing behavior of existing systems, which would be a good case for a sysctl.
Attachment:
pgp4mY8EFvTMZ.pgp
Description: PGP signature