[time-nuts] Need Time Help

Graham / KE9H ke9h.graham at gmail.com
Wed Oct 5 12:50:49 UTC 2016 

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham

==

On Wed, Oct 5, 2016 at 6:14 AM, Bob Camp <kb8tq at n1k.org> wrote:

> Hi
>
> If you buy a GPS receiver and get it set up for timing …. just use it.
> Then there is no
> need for NTP at all….
>
> Bob
>
> > On Oct 5, 2016, at 12:33 AM, Chris Albertson <albertson.chris at gmail.com>
> wrote:
> >
> > On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp <kb8tq at n1k.org> wrote:
> >
> >> Hi
> >>
> >> If:
> >>
> >> 1) You are a typical Ham in a home environment
> >> 2) All the servers are “out there” on the internet
> >> 3) You have any of the normal modems feeding your home
> >>
> >> You have a very basic issue in terms of path delay. All the servers you
> >> can access
> >> have the *same* asymmetric delay. In that case, no matter how many
> servers
> >> you
> >> add to the ensemble, the situation never gets better. You are always
> stuck
> >> with the
> >> (likely unknown) uplink / downlink delay difference of your modem.
> Exactly
> >> what
> >> that number is depends a *lot* on the modern and the system feeding the
> >> modem.
> >> It is *very* possible to see static delay asymmetry well beyond the 5 ms
> >> that the OP is after.
> >> On most systems there is also a dynamic asymmetry that is related to
> >> loading. That
> >> just makes things harder to work out …..
> >>
> >
> > But this is easy to measure, you buy a GPS receiver and use that as an
> 8th
> > or 6th reference clock along with the 5 or 7 Internet servers then you
> look
> > at the difference between GPS and the Internet servers.  The Internet
> > servers do much better than you'd think.  Not as good as GPS but really
> > good.  Why?
> >
> > Because NTP normally never actually sets you clock to match a server's
> > clock.   It adjusts the RATE of your clock so the it cruises on the
> middle
> > of the pack of vetted servers.  It adjusts your clock over a long period
> to
> > it has the benefit of averaging out lots of random behavior.   The result
> > is that you can keep within a few milliseconds of the GPS even with tens
> of
> > millisecond of delay in the communication path.
> >
> > For people new to NTP, the algorithm has it's hands the system clocks
> > "fast/Slow? lever and never normally moves the clocks hands directly
> >
> > And all those Internet servers do NOT have the same asymmetric delay.
> Well
> > they might but that would be a pathological case.  Typically delays
> really
> > are more symmetric than not (one way trip really is 1/2 the round trip)
> > The clocks that don't meet this assumption are found and removed from the
> > pool.   It works because the dells are NOT the same but random  Ans like
> I
> > said, it is easy enough to measure.  You can see that peer offsets are
> all
> > over the map
> >
> > Also your modem is likely not causing an asymmetric delay.  That modern
> > wetter is is the old phone kind or a fiber optic system only takes you to
> > the fist router.  The modern likely has the same time of flight in both
> > directions.   The delay is cause by a queue some place of packets that
> are
> > aggregated from many users.  These are random  but sort of predictable.
> A
> > packet going across a continent or will see more of this then going to a
> > nearby server
> >
> >
> >> Bob
> >>
> >>> On Oct 4, 2016, at 9:05 PM, Chris Albertson <albertson.chris at gmail.com
> >
> >> wrote:
> >>>
> >>> The problem, I think with your Internet sync's NTP servers is you are
> >> only
> >>> using one server S.  The most common practice is to use 3 to 5 with 5
> >> being
> >>> about the right number.   If you get Ntp enough Internet servers to
> work
> >>> with it can detect problem like asymmetric path lengths which I'm sure
> is
> >>> you problem.
> >>>
> >>> NTP solved the problem that stumped a few people back in the 1970's of
> >> how
> >>> to sync two clocks when there is a long delay and not constant in there
> >>> communications path.  (Of course the problem is simple if the delay is
> >>> known and well measured)  But the solution required the the average
> path
> >>> delay is the same going in each direction.  worse no software can't
> know
> >>> there is an asymmetric delay.  Well not unless it is using a few
> servers.
> >>> NTP basically finds then ignores the "problem servers".
> >>>
> >>> PTP solves the problem by requiring that all the network hardware has
> >>> special time stamp ability that is designed to work with PTP.  This
> >>> hardware is rare unless the user provides it.  So PTP can't really work
> >> on
> >>> the public Internet.
> >>>
> >>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
> >>> Internet servers, but pick 5 of them or even 7.  and make sure they are
> >>> dispersed and not all at the same place.
> >>>
> >>> On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali <attila at kinali.ch>
> wrote:
> >>>
> >>>> On Tue, 4 Oct 2016 15:41:58 +1100
> >>>> Larry Hower <hower at hower.net> wrote:
> >>>>
> >>>>> Ultimately we want sub-millisecond accuracy.
> >>>>
> >>>> If you want to go that way, you will have to leave windows as
> >>>> this operating system does not offer the facilities to get down
> >>>> to such a low level....Unless you calibrate the whole path by
> injecting
> >>>> a time pulse into the signal path like Jim Lux and TvB suggested
> >>>>
> >>>> With linux you can get systems synchronized to better than 1ms by
> >>>> using a PTP server in the local network or by directly using PPS.
> >>>> This should get you in the order of better than 100µs probaly 20-30µs.
> >>>>
> >>>> BTW: A word of advice against using NTP servers over the internet
> >>>> for accurate time distribution. I recently set-up two NTP servers
> >>>> to be used as stratum 2 servers (server A and B). Both synchronize
> >>>> to the same stratum 1 server (server S), but are at different ISPs
> >>>> and thus use different paths. NTP on both A and B reports the
> following
> >>>> values (current snapshot, values are representative):
> >>>>
> >>>> Link    delay   offset  jitter
> >>>> A-S     4.205    0.020   0.081
> >>>> B-S     2.112    0.039   0.079
> >>>> A-B     0.606   -0.877   3.192 (as reported by A)
> >>>>
> >>>> I.e. even though A and B use the same server S as reference, the
> >>>> time difference between both servers is 800-900µs. I am not sure
> >>>> where this path asymmetry comes from, but my guess would be on
> >>>> the connectivity of A (there are two groups of stratum 2 it syncs
> >>>> to and one of them shows the same ~900µs offset). I also do not
> >>>> know why the jitter between A and B is so large even though the
> >>>> delay is pretty low (seems to be a weirdness at a router inbetween).
> >>>>
> >>>>
> >>>>                       Attila Kinali
> >>>>
> >>>> --
> >>>> It is upon moral qualities that a society is ultimately founded. All
> >>>> the prosperity and technological sophistication in the world is of no
> >>>> use without that foundation.
> >>>>                -- Miss Matheson, The Diamond Age, Neil Stephenson
> >>>> _______________________________________________
> >>>> time-nuts mailing list -- time-nuts at febo.com
> >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >>>> mailman/listinfo/time-nuts
> >>>> and follow the instructions there.
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Chris Albertson
> >>> Redondo Beach, California
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts at febo.com
> >>> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >>> and follow the instructions there.
> >>
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>

More information about the Time-nuts_lists.febo.com mailing list