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.