[Thumbgps-devel] good paper on timing and delay

[Thumbgps-devel] good paper on timing and delay

[Dave Taht]

http://queue.acm.org/detail.cfm?id=1773943

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] good paper on timing and delay

[Ron Frazier (NTP)]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Hi Dave T, and others,

(I'm cross posting my reply to the NTP questions list since I think they'd be interested too. The original message was from the Thumbgps-devel mailing list.)

I enjoyed that article. I'll admit to not spending 4 hours studying it, and sometimes my eyes glazed over, but I enjoyed it. It brought up some, perhaps simplistic, questions, but I'll pose them anyway.

The essential problem of time sync is to observe one or more remote time servers, with variable and asymmetric propagation delays between you and them, and choose what the best time to set your clock is. Obviously, not simple.

However, it occurs to me that the GPS receivers are doing essentially the same thing via radio. They are observing numerous satellites at various locations in orbit. Those satellites have precision clocks all calibrated to within 100ns (or .1 us) of true time on Earth. The GPS receiver, cannot "poll" the satellites, but it can observe their broadcasts. Each satellite has a variable and at least somewhat asymmetric propagation delay. That propagation delay can be in the range of .25 sec or 250,000 us. Yet, the GPS receiver can routinely output a PPS pulse with an accuracy of 1us or better, taking the Garmin 18 as an example.

So, the possibly simplistic question is, if our network time sync programs used the same algorithm that the GPS receivers use to read their "servers", ie satellites, which all have variable and perhaps somewhat asymmetric propagation delays, which can be substantial, would we be able to achieve much greater levels of accuracy doing synchronization via the internet?

Thanks in advance for any replies.

Sincerely,

Ron


--

Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.
Please excuse my potential brevity.

(To whom it may concern. My email address has changed. Replying to former
messages prior to 03/31/12 with my personal address will go to the wrong
address. Please send all personal correspondence to the new address.)

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and such.
I don't always see new email messages very quickly. If you need a reply and
haven't heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT techstarship.com

Dave Taht <dave.taht@gmail.com> wrote:

http://queue.acm.org/detail.cfm?id=1773943

--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
_____________________________________________

Thumbgps-devel mailing list
Thumbgps-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/thumbgps-devel


[-- Attachment #2: Type: text/html, Size: 3436 bytes --]

Re: [Thumbgps-devel] good paper on timing and delay

[Dave Hart]

On Tue, May 22, 2012 at 2:07 PM, Ron Frazier (NTP)
<timekeepingntplist@techstarship.com> wrote:
> The essential problem of time sync is to observe one or more remote time
> servers, with variable and asymmetric propagation delays between you and
> them, and choose what the best time to set your clock is. Obviously, not
> simple.
>
> However, it occurs to me that the GPS receivers are doing essentially the
> same thing via radio. They are observing numerous satellites at various
> locations in orbit. Those satellites have precision clocks all calibrated to
> within 100ns (or .1 us) of true time on Earth. The GPS receiver, cannot
> "poll" the satellites, but it can observe their broadcasts. Each satellite
> has a variable and at least somewhat asymmetric propagation delay.

The communication between GPS birds and receivers is one-way.  It is
neither symmetric nor asymmetric.

> That
> propagation delay can be in the range of .25 sec or 250,000 us. Yet, the GPS
> receiver can routinely output a PPS pulse with an accuracy of 1us or better,
> taking the Garmin 18 as an example.
>
> So, the possibly simplistic question is, if our network time sync programs
> used the same algorithm that the GPS receivers use to read their "servers",
> ie satellites, which all have variable and perhaps somewhat asymmetric
> propagation delays, which can be substantial, would we be able to achieve
> much greater levels of accuracy doing synchronization via the internet?

GPS birds tell the receiver the flight plans of all birds, so the
receiver knows the dominant factor in the propagation delay, the
distance between transmitter and receiver.  With WAAS reception, even
more information about delay is provided in the form of atmospheric
conditions.  NTP has a much more difficult row to hoe.

Cheers,
Dave Hart

Re: [Thumbgps-devel] good paper on timing and delay

[Eric S. Raymond]

Dave Hart <hart@ntp.org>:
> > So, the possibly simplistic question is, if our network time sync programs
> > used the same algorithm that the GPS receivers use to read their "servers",
> > ie satellites, which all have variable and perhaps somewhat asymmetric
> > propagation delays, which can be substantial, would we be able to achieve
> > much greater levels of accuracy doing synchronization via the internet?
> 
> GPS birds tell the receiver the flight plans of all birds, so the
> receiver knows the dominant factor in the propagation delay, the
> distance between transmitter and receiver.  With WAAS reception, even
> more information about delay is provided in the form of atmospheric
> conditions.  NTP has a much more difficult row to hoe.

This is true, but Ron might nevertheless be onto something here. 
The solver algorithm for position given a bunch of pseudoranges
is irrelevant to anything NTP does. It's straight-up spherical
trigonometry.  But...

GPSes also use Kalman filtering to try to back out the effects of
variable ionospheric delay, which manifests as noise in the
pseudorange measurements.  The pseudorange noise behaves a lot like
jitter in network packet latencies.

It's possible that Kalman filtering could be useful for cleaning noise
from an NTP server's measurements of propagation delay.  It's a general
technique used for all kinds of noisy time series.

From Wikipedia:

The Kalman filter, also known as linear quadratic estimation (LQE), is
an algorithm which uses a series of measurements observed over time,
containing noise (random variations) and other inaccuracies, and
produces estimates of unknown variables that tend to be more precise
than those that would be based on a single measurement alone. More
formally, the Kalman filter operates recursively on streams of noisy
input data to produce a statistically optimal estimate of the
underlying system state.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>