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.ch...@gmail.com> > wrote: > > On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp <kb...@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.ch...@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 <att...@kinali.ch> wrote: >>> >>>> On Tue, 4 Oct 2016 15:41:58 +1100 >>>> Larry Hower <ho...@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@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@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.