[time-nuts] Need Time Help

Wed Oct 5 11:14:30 UTC 2016

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.