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 <kb...@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.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. > _______________________________________________ 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.