Re: pulse-per-second API status

[Warner Losh <imp%bsdimp.com@localhost>]

On Nov 1, 2013, at 12:19 PM, Paul_Koning%Dell.com@localhost wrote:

> 
> On Nov 1, 2013, at 2:04 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> 
> wrote:
> 
>> ...
>> But it still may not work in the sense of living up to the expectations
>> people have come to have for PPS on serial ports.
>> 
>> My worry is not that it's not the best time available in some
>> circumstances.  My worry is that putting it into the tree will lead to
>> its getting used as if it were as good as PPS on anything else, leading
>> both to timeservers that claim stratum 1 but give bad chime and to
>> people blaming NetBSD for its crappy PPS support when the real problem
>> is that they don't understand the USB issues and it _looks_ like any
>> other PPS support until you test the resulting time carefully.
> 
> Not just PPS on serial ports, but PPS on other hardware.
> 
> 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.
> 
> It seems rather confusing to have another interface that goes by the same 
> name but has specs 6 or more orders of magnitude worse.  How about a 
> different name that avoids this confusion?

Just because the signal has an Allen Variance of 10^-10 doesn't mean that 
you'll be able to measure each pulse with that precision, or that the tau of 
that figure is 1s... Most common time counter hardware in SoCs and the like is 
good to anywhere from hundreds of microseconds to tens of nano seconds. 
Hundreds of microseconds isn't much worse than the millisecondish USB accuracy. 
The PPS API even allows for an estimate of the accuracy of the measurements, 
IIRC, but that may be a higher-level facility of NTP (it has been a few years 
since I've done this stuff professionally). I don't think there will be any 
confusion at all, especially if the measured accuracy and variance of this 
facility is documented.

1ms is quite accurate enough for NTP though. NTP has trouble on the network 
getting below 1ms of accuracy, especially when there are any hops at all in the 
topology. It won't be the best NTP server in the world, but it will be accurate 
enough for most things. If you need more accuracy, get better hardware..

To those saying 'fix NMEA mode to be better': You can't. The characters that 
spit this code out aren't guaranteed to be at top of second any more than 
approximately...The exact timing varies from receiver to receiver, and if USB 
is involved, the same silly delays are present there too, only worse because 
the message spans USB packets (or likely would since it is just short of 100 
characters long IIRC)... And even if you get those issues out of the way, I 
also believe there's ambiguity in the NMEA standard between the 'on time' point 
for the NMEA messages. Is it the start of the message, the end? Is is the first 
transition of the first bit of the message, or the end of the first character?  
Since it isn't considered a precision signal, nobody times it exactly (or 
didn't a few years ago). It is useful, at best, for knowing what time the 
external PPS is about to be or just was...

So adding support to ucom isn't a horrible idea, as long as expectations are 
managed...

Warner