[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [questions] GPS+PPS vs NTP server, why a huge offset ?




> On 19 Jun 2022, at 17:43, David Taylor <david-taylor@xxxxxxxxxxxxxxxx> wrote:
> 
> On 19/06/2022 07:30, Daniel O'Connor wrote:
>> I think for standard PC timing in a network it is more than adequate.
>> Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.
> 
>> Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.
> 
> If PPS over USB is all you have, of course use it.  But if you have a local stratum-1 server it's likely to produce much better results, just using a LAN connection.

I am not sure this is true, but the difference if probably negligible.

However.. if you had a local stratum 1 server then using a GPS receiver seems pointless unless you want redundancy..

> Probably on the RPi using an input capture timer wouldn't produce much better results than simply using the GPIO pins and the the built-in kernel PPS support and reference NTP.  I tend to think of the RPi alone as "tens of microseconds or better", and capture 

Input capture is nice because it means interrupt latency is no longer a problem.

The PPS edge is captured by the clock and so it doesn't matter how long the CPU takes to read it (until the next edge anyway..) there is no loss of accuracy.

> timer (PTP) as sub-microsecond level.  Both are quite adequate for "standard PC timing".

Sure, but NMEA (even without PPS) is fine for "standard PC timing".

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
-- 
This is questions@xxxxxxxxxxxxx
Subscribe: questions+subscribe@xxxxxxxxxxxxx
Unsubscribe: questions+unsubscribe@xxxxxxxxxxxxx