Bill, Some of the key topics of this hobby are -- what did it cost, absolute time error, relative frequency instability, and phase noise. In these cases the goal of time nuts is always "mine is smaller than yours". /tvb ----- Original Message ----- From: "William H. Fite" <omniryx@gmail.com> To: "Nick Sayer" <nsayer@kfu.com>; "Discussion of precise time and frequency measurement" <time-nuts@febo.com> Sent: Thursday, October 06, 2016 11:15 AM Subject: Re: [time-nuts] Need Time Help Indeed, Nick. And more than a little (usually) courteous one upmanship couched in terms of being helpful by correcting all previous posters. This gentlemanly "mine is bigger than yours" phenomenon is part of what makes this group fun to read. On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts <time-nuts@febo.com > wrote: > To be fair, this is at least partly because asking a relatively simple > question here routinely turns into a dissertation defense. > > > On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: > > > > Hi > > > > That’s very typical in a lot of forums. The OP tosses up a question and > then pretty much vanishes. > > My observation is that roughly 80% of the “I have a question” threads > work that way. > > I’ve never been able to figure out if it is an expectation that all > answers will arrive in an hour or two > > or if the OP is simply reading along and sees no reason to providing > more information to the group. > > Either way, I’m pretty sure that the focus of the answers is not all > that great a week after the last input. > > > > Bob >

Very true, Tom! I stand corrected. On Thu, Oct 6, 2016 at 2:50 PM, Tom Van Baak <tvb@leapsecond.com> wrote: > Bill, > > Some of the key topics of this hobby are -- what did it cost, absolute > time error, relative frequency instability, and phase noise. In these cases > the goal of time nuts is always "mine is smaller than yours". > > /tvb > > ----- Original Message ----- > From: "William H. Fite" <omniryx@gmail.com> > To: "Nick Sayer" <nsayer@kfu.com>; "Discussion of precise time and > frequency measurement" <time-nuts@febo.com> > Sent: Thursday, October 06, 2016 11:15 AM > Subject: Re: [time-nuts] Need Time Help > > > Indeed, Nick. And more than a little (usually) courteous one upmanship > couched in terms of being helpful by correcting all previous posters. This > gentlemanly "mine is bigger than yours" phenomenon is part of what makes > this group fun to read. > > On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts < > time-nuts@febo.com > > wrote: > > > To be fair, this is at least partly because asking a relatively simple > > question here routinely turns into a dissertation defense. > > > > > On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: > > > > > > Hi > > > > > > That’s very typical in a lot of forums. The OP tosses up a question and > > then pretty much vanishes. > > > My observation is that roughly 80% of the “I have a question” threads > > work that way. > > > I’ve never been able to figure out if it is an expectation that all > > answers will arrive in an hour or two > > > or if the OP is simply reading along and sees no reason to providing > > more information to the group. > > > Either way, I’m pretty sure that the focus of the answers is not all > > that great a week after the last input. > > > > > > Bob > > > > _______________________________________________ > 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. > -- Intelligence has never been proof against stupidity.

On 10/6/16 11:15 AM, William H. Fite wrote: > Indeed, Nick. And more than a little (usually) courteous one upmanship > couched in terms of being helpful by correcting all previous posters. This > gentlemanly "mine is bigger than yours" phenomenon is part of what makes > this group fun to read. Except that here, the popular metrics (AVAR, Phase Noise, etc.) are "smaller is better" so the bragging rights go to the list member claiming 1E-16 over, say, the relatively feeble 1E-6. When you get to those sorts of levels, too, it's a lot of attention to the details that lets you get there. It's like GPS: getting 10 meter accuracy is easy Getting 1 meter is tougher but still straightforward But getting to centimeters, all of a sudden there's all these factors that are insignificant at the 10 meter level but all significant at the centimeter level: solid earth tides, ionospheric issues, multipath, etc. And what's great about this group is that there are people on the list who have been bitten by probably every thing that can go wrong (not one person had ALL of them, but spanning the group) or could be speculated to go wrong. > > On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts <time-nuts@febo.com >> wrote: > >> To be fair, this is at least partly because asking a relatively simple >> question here routinely turns into a dissertation defense. >> >>> On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: >>> >>> Hi >>> >>> That’s very typical in a lot of forums. The OP tosses up a question and >> then pretty much vanishes. >>> My observation is that roughly 80% of the “I have a question” threads >> work that way. >>> I’ve never been able to figure out if it is an expectation that all >> answers will arrive in an hour or two >>> or if the OP is simply reading along and sees no reason to providing >> more information to the group. >>> Either way, I’m pretty sure that the focus of the answers is not all >> that great a week after the last input. >>> >>> Bob >> >> _______________________________________________ >> 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. >> > > >

On 10/6/2016 8:10 PM, Wes wrote: > Although I personally ceased pursuing this activity many years ago, there remain > some of us, who are not Luddites, but still believe that "Deep Search Decoding" > is a questionable practice, no matter how it is rationalized. "Deep Search Decoding" of the JT modes is exactly equivalent to the mental deep search of common call signs done by the CW addicts when receiving just a partial call sign, trying to figure who could be that operator, examining in their brain the list of the most probable persons active in CW EME... Nothing more, nothing less... But this is a discussion best suited for the Moon-Net list, where it happened umpteen times... 73 Alberto I2PHD

 remote           refid      st t when poll reach   delay   offset 

one of his (at best) two or three gateways to your local empire. 

or may not be in the same state you live in.

I was going to post my ntp output and ask for an opinion, then this discussion popped up. It would appear that asymmetric delays are the exact explanation for what I am seeing. Is that a reasonable assumption? It does seem to be rather consistent throughout the day, however. The reason for checking against the net when I have a GPS source is that I want ntp to continue if/when there is no PPS. Is there any way to inform ntp of the asymmetry? Thanks, -- Thomas Valerio Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11 12:37:33 2016 remote refid st t when poll reach delay offset jitter ============================================================================== x127.127.28.0 .NMEA. 0 l 4 16 377 0.000 -30.300 36.009 *127.127.28.1 .PPS. 0 l 3 16 377 0.000 0.001 0.000 -208.53.158.34 216.93.242.12 3 u 9 64 377 17.202 2.907 0.188 +208.100.4.52 216.86.146.46 2 u 64 64 377 16.612 2.332 0.193 +208.69.120.241 142.66.101.13 2 u 5 64 377 24.258 1.688 0.223 -128.118.25.3 130.207.244.240 2 u 53 64 377 40.429 4.956 2.577 > Hi > > NTP can *not* detect “common mode” asymmetric delay. Having a local > GPS does not count in this respect. What does count is an NTP client / > server sitting in your home trying to figure out what time it is only > by hooking to the internet. > >To do this it must do a few things: > > 1) Get a signal out through the (slow / long lag) upload channel on your modem. > 2) Route that signal through the cable guy’s low capacity upstream network to > one of his (at best) two or three gateways to your local empire. These may > or may not be in the same state you live in. > 3) Fly the signal over the backbone to whatever server is involved. > 4) Fly a signal back over the backbone to possibly another set of gateways. > 5) Route that signal through the cable guy’s high capacity downstream network. > 6) Run it through the (quite fast / low lag) downstream channel on your modem. > > Steps 1,2,5 and 6 are common to every single server you try to access. If your > modem has an “upstream” lag of (say) 101 ms and a “downstream” lag > of (say) 1 ms, every server you contact will have a round trip time of at > least 102 ms. They *may* have more than this, but none will ever have less. > > As the day progresses and various groups pop on and off the system in your state, > the usage of the upstream and downstream channels changes. It is not unreasonable > to guess that both change as a percentage. If that guess is correct, your upstream > varies by significantly more than your downstream. That will get into NTP’s loop > correction stuff as well. > > You *might* ask, how about pings? Well, you *might* look into it and find that > your local cable system recognizes pings at a very low level and preferentially > routes them. Yes, that’s hogwash and nobody would ever do it ….. except > that’s the way it works here with my internet. The network can be completely > dead and pings (along with other ICMP traffic) will get through. Hmmm….. > > You are indeed a guy with 5 watches to check against. The gotcha is that every > single one of them has been set fast or slow by the same amount. > > Bob > >> On Oct 6, 2016, at 11:03 AM, Chris Albertson <albertson.chris@gmail.com> >> wrote: >> >> I still think NTP can detect asymmetric delays. Only it can't know that >> is >> what it is detecting. What else generate those offset numbers? Yes >> it >> could very well be that MRS is running slow but I doubt that is the >> case. >> And I really doubt your GPS' PPS is off by even one microsecond. A >> good >> bet is that ALL the results we see is because the real-world >> communication >> path is different from the assumption NTP makes about communications >> paths. >> >> In practice what NTP sees is all due to the Internet and not so much the >> reference clocks. Your data shows this. 162.23.41.10 .MRS has >> different >> stat depending on who is looking at it. So those billboards are showing >> network stats not server stats. (but NTP can't know that for certain so >> it >> is obliged to call them server stats) >> >> This is 2016. Almost any reference clock you are likely to use will be >> pretty much dead-on, at least to within the precision that NTP works >> with. >> So anything those billboards say is really about the communications >> paths. >> But NTP has no theoretical right to assume the cause of what it sees. >> Theory and practice differs, In theory NTP can not detect asymmetric >> delay but in practice that is about all it detects Maybe I should say >> NTP >> detects asymmetric delay just like the speedometer in my car deters >> engine >> failure. >> >> All that said, if the OP is still reading this it should be very good >> news >> for him because your data shows that NTP can give him his required >> accuracy >> even without a GPS if he has an Internet connection as good as yours >> >> In fact what you are showing is that NTP using the Internet can beat GPS >> over USB to Winows. and can certainly beat any software the "jam sets" >> the >> clock. All you need is your Internet connection, no aded hardware.

Thanks,
  -- Thomas Valerio

  remote           refid      st t when poll reach   delay   offset

one of his (at best) two or three gateways to your local empire.

or may not be in the same state you live in.

There is good article to read http://cs.stackexchange.com/questions/103/clock-synchronization-in-a-network-with-asymmetric-delays Probably NTPD uses a weighting schema when processing the measurements. However, beyond a certain level of delay the measurements are likely to be so corrupted as to be useless. On 2016-10-11 13:09, Thomas Valerio wrote: > I was going to post my ntp output and ask for an opinion, then this > discussion popped up. It would appear that asymmetric delays are the > exact explanation for what I am seeing. Is that a reasonable > assumption? > It does seem to be rather consistent throughout the day, however. The > reason for checking against the net when I have a GPS source is that I > want ntp to continue if/when there is no PPS. Is there any way to > inform > ntp of the asymmetry? > > Thanks, > -- Thomas Valerio > > > Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11 > 12:37:33 > 2016 > > remote refid st t when poll reach delay offset > jitter > ============================================================================== > x127.127.28.0 .NMEA. 0 l 4 16 377 0.000 -30.300 > 36.009 > *127.127.28.1 .PPS. 0 l 3 16 377 0.000 0.001 > 0.000 > -208.53.158.34 216.93.242.12 3 u 9 64 377 17.202 2.907 > 0.188 > +208.100.4.52 216.86.146.46 2 u 64 64 377 16.612 2.332 > 0.193 > +208.69.120.241 142.66.101.13 2 u 5 64 377 24.258 1.688 > 0.223 > -128.118.25.3 130.207.244.240 2 u 53 64 377 40.429 4.956 > 2.577 > > >> Hi >> >> NTP can *not* detect “common mode” asymmetric delay. Having >> a local >> GPS does not count in this respect. What does count is an NTP client / >> server sitting in your home trying to figure out what time it is only >> by hooking to the internet. >> >> To do this it must do a few things: >> >> 1) Get a signal out through the (slow / long lag) upload channel on >> your > modem. >> 2) Route that signal through the cable guy’s low capacity >> upstream > network to >> one of his (at best) two or three gateways to your local empire. > These may >> or may not be in the same state you live in. >> 3) Fly the signal over the backbone to whatever server is involved. >> 4) Fly a signal back over the backbone to possibly another set of >> gateways. >> 5) Route that signal through the cable guy’s high capacity >> downstream > network. >> 6) Run it through the (quite fast / low lag) downstream channel on >> your > modem. >> >> Steps 1,2,5 and 6 are common to every single server you try to access. > If your >> modem has an “upstream” lag of (say) 101 ms and a >> “downstream” lag >> of (say) 1 ms, every server you contact will have a round trip time of >> at >> least 102 ms. They *may* have more than this, but none will ever have >> less. >> >> As the day progresses and various groups pop on and off the system in > your state, >> the usage of the upstream and downstream channels changes. It is not > unreasonable >> to guess that both change as a percentage. If that guess is correct, > your upstream >> varies by significantly more than your downstream. That will get into > NTP’s loop >> correction stuff as well. >> >> You *might* ask, how about pings? Well, you *might* look into it and > find that >> your local cable system recognizes pings at a very low level and > preferentially >> routes them. Yes, that’s hogwash and nobody would ever do it >> ….. except >> that’s the way it works here with my internet. The network can be > completely >> dead and pings (along with other ICMP traffic) will get through. >> Hmmm….. >> >> You are indeed a guy with 5 watches to check against. The gotcha is >> that > every >> single one of them has been set fast or slow by the same amount. >> >> Bob >> >>> On Oct 6, 2016, at 11:03 AM, Chris Albertson >>> <albertson.chris@gmail.com> >>> wrote: >>> >>> I still think NTP can detect asymmetric delays. Only it can't know >>> that >>> is >>> what it is detecting. What else generate those offset numbers? >>> Yes >>> it >>> could very well be that MRS is running slow but I doubt that is the >>> case. >>> And I really doubt your GPS' PPS is off by even one microsecond. >>> A >>> good >>> bet is that ALL the results we see is because the real-world >>> communication >>> path is different from the assumption NTP makes about communications >>> paths. >>> >>> In practice what NTP sees is all due to the Internet and not so much >>> the >>> reference clocks. Your data shows this. 162.23.41.10 .MRS has >>> different >>> stat depending on who is looking at it. So those billboards are >>> showing >>> network stats not server stats. (but NTP can't know that for certain >>> so >>> it >>> is obliged to call them server stats) >>> >>> This is 2016. Almost any reference clock you are likely to use will >>> be >>> pretty much dead-on, at least to within the precision that NTP works >>> with. >>> So anything those billboards say is really about the communications >>> paths. >>> But NTP has no theoretical right to assume the cause of what it sees. >>> Theory and practice differs, In theory NTP can not detect >>> asymmetric >>> delay but in practice that is about all it detects Maybe I should >>> say >>> NTP >>> detects asymmetric delay just like the speedometer in my car deters >>> engine >>> failure. >>> >>> All that said, if the OP is still reading this it should be very good >>> news >>> for him because your data shows that NTP can give him his required >>> accuracy >>> even without a GPS if he has an Internet connection as good as yours >>> >>> In fact what you are showing is that NTP using the Internet can beat >>> GPS >>> over USB to Winows. and can certainly beat any software the "jam >>> sets" >>> the >>> clock. All you need is your Internet connection, no aded hardware. > _______________________________________________ > 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. -- WBW, V.P.

Yes, I think you are correct except in one case. The NMEA offset may very well be mostly because the NMEA sentence is actually "off". Such sentences may be as much as a full second "off". First the NMEA standard requires only one second accuracy and also the sentence is sent over a slow serial link along with other data and when you get it depends a lot on what they "other data" is. This is the reason the GPS has a PPS. NMEA was invented for ship navigation, not timing. On Tue, Oct 11, 2016 at 10:09 AM, Thomas Valerio <tjv@westwood-tech.com> wrote: > I was going to post my ntp output and ask for an opinion, then this > discussion popped up. It would appear that asymmetric delays are the > exact explanation for what I am seeing. -- Chris Albertson Redondo Beach, California