frequency adjusting only - NTP

This is a discussion on frequency adjusting only - NTP ; At a guess, it's the correlation that had a period of 2 wks. I'd guess it as a harmonic of a week somehow. But who knows. That's the problem with lrd. Greg Dowd gdowd at symmetricom dot com (antispam format) ...

+ Reply to Thread
Page 5 of 5 FirstFirst ... 3 4 5
Results 81 to 94 of 94

Thread: frequency adjusting only

  1. Re: frequency adjusting only

    At a guess, it's the correlation that had a period of 2 wks. I'd guess
    it as a harmonic of a week somehow. But who knows. That's the problem
    with lrd.


    Greg Dowd
    gdowd at symmetricom dot com (antispam format)
    Symmetricom, Inc.
    www.symmetricom.com
    "Everything should be made as simple as possible, but no simpler" Albert
    Einstein


    > -----Original Message-----
    > From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
    > [mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org]
    > On Behalf Of Brian Utterback
    > Sent: Friday, May 02, 2008 7:38 AM
    > To: questions@lists.ntp.org
    > Subject: Re: [ntp:questions] frequency adjusting only
    >
    > David L. Mills wrote:
    >
    > > Suspecting such could be the case between NTP servers and

    > clients, I
    > > designed an experiment to detect such things and found small but
    > > significant LRD effects with lags up to TWO WEEKS! At short

    > lags up to
    > > several network turns this can be explained by packet lengths,
    > > buffering, retransmissions, etc., but at much longer lags

    > you have to
    > > look for routing flaps, provisioning changes, etc.
    > >

    >
    > Dave, are you saying that you saw an instance of a NTP
    > response arriving 2 weeks after the request was sent?
    >
    > Brian Utterback
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  2. Re: frequency adjusting only

    Brian,

    The longest delay NTP response was from the Moon, as simulated at JPL.
    Next step is the Mars orbiters and then the rovers. JPL discovered the
    max distance threshold had to be increased to handle the Moon delay.

    The longest lived NTP headbanger was when I used ARPAnet IMP 29 back in
    the late 70s. The banger continued without response until the ARPAnet
    was dismantled in the early 90s. There are folks that have been banging
    on our racket.udel.edu at its 128.4.1.1 address since 1981.

    So far, not response has arrived before the request was sent. The code
    even checks for that. I'll let you know.

    Dave

    Brian Utterback wrote:

    > David L. Mills wrote:
    >
    >> Suspecting such could be the case between NTP servers and clients, I
    >> designed an experiment to detect such things and found small but
    >> significant LRD effects with lags up to TWO WEEKS! At short lags up to
    >> several network turns this can be explained by packet lengths,
    >> buffering, retransmissions, etc., but at much longer lags you have to
    >> look for routing flaps, provisioning changes, etc.
    >>

    >
    > Dave, are you saying that you saw an instance of a NTP response arriving
    > 2 weeks after the request was sent?
    >
    > Brian Utterback


  3. Re: frequency adjusting only

    Greg,

    Times change, no pun. Once upon a time an autocorellation function of
    Internet delays showed significant peaks corresponding to daylight
    working hours, complete with lunchtime lulls. That was when packets
    lived most of their lives on queues; now they live mostl on
    overprovisioned fiber or in space. LRD effects were than and now largely
    believed to be due to the length of TCP connections.

    Dave

    Greg Dowd wrote:

    > At a guess, it's the correlation that had a period of 2 wks. I'd guess
    > it as a harmonic of a week somehow. But who knows. That's the problem
    > with lrd.
    >
    >
    > Greg Dowd
    > gdowd at symmetricom dot com (antispam format)
    > Symmetricom, Inc.
    > www.symmetricom.com
    > "Everything should be made as simple as possible, but no simpler" Albert
    > Einstein
    >
    >
    >
    >>-----Original Message-----
    >>From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
    >>[mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org]
    >> On Behalf Of Brian Utterback
    >>Sent: Friday, May 02, 2008 7:38 AM
    >>To: questions@lists.ntp.org
    >>Subject: Re: [ntp:questions] frequency adjusting only
    >>
    >>David L. Mills wrote:
    >>
    >>
    >>>Suspecting such could be the case between NTP servers and

    >>
    >>clients, I
    >>
    >>>designed an experiment to detect such things and found small but
    >>>significant LRD effects with lags up to TWO WEEKS! At short

    >>
    >>lags up to
    >>
    >>>several network turns this can be explained by packet lengths,
    >>>buffering, retransmissions, etc., but at much longer lags

    >>
    >>you have to
    >>
    >>>look for routing flaps, provisioning changes, etc.
    >>>

    >>
    >>Dave, are you saying that you saw an instance of a NTP
    >>response arriving 2 weeks after the request was sent?
    >>
    >>Brian Utterback
    >>
    >>_______________________________________________
    >>questions mailing list
    >>questions@lists.ntp.org
    >>https://lists.ntp.org/mailman/listinfo/questions
    >>


  4. Re: frequency adjusting only

    "David L. Mills" writes:

    >Brian,


    >The longest delay NTP response was from the Moon, as simulated at JPL.
    >Next step is the Mars orbiters and then the rovers. JPL discovered the
    >max distance threshold had to be increased to handle the Moon delay.


    Thats only a few sec.
    And it is symmetrical. Could probably still get usec resolution.


    >The longest lived NTP headbanger was when I used ARPAnet IMP 29 back in
    >the late 70s. The banger continued without response until the ARPAnet
    >was dismantled in the early 90s. There are folks that have been banging
    >on our racket.udel.edu at its 128.4.1.1 address since 1981.


    >So far, not response has arrived before the request was sent. The code
    >even checks for that. I'll let you know.


    >Dave


    >Brian Utterback wrote:


    >> David L. Mills wrote:
    >>
    >>> Suspecting such could be the case between NTP servers and clients, I
    >>> designed an experiment to detect such things and found small but
    >>> significant LRD effects with lags up to TWO WEEKS! At short lags up to
    >>> several network turns this can be explained by packet lengths,
    >>> buffering, retransmissions, etc., but at much longer lags you have to
    >>> look for routing flaps, provisioning changes, etc.
    >>>

    >>
    >> Dave, are you saying that you saw an instance of a NTP response arriving
    >> 2 weeks after the request was sent?
    >>
    >> Brian Utterback


  5. Re: frequency adjusting only

    Unruh wrote:
    > "David L. Mills" writes:
    >
    >> Brian,

    >
    >> The longest delay NTP response was from the Moon, as simulated at JPL.
    >> Next step is the Mars orbiters and then the rovers. JPL discovered the
    >> max distance threshold had to be increased to handle the Moon delay.

    >
    > Thats only a few sec.
    > And it is symmetrical. Could probably still get usec resolution.


    Of course it's not symmetrical. You of all people should know better
    than that.

    Danny

  6. Re: frequency adjusting only

    mayer@ntp.isc.org (Danny Mayer) writes:

    >Unruh wrote:
    >> "David L. Mills" writes:
    >>
    >>> Brian,

    >>
    >>> The longest delay NTP response was from the Moon, as simulated at JPL.
    >>> Next step is the Mars orbiters and then the rovers. JPL discovered the
    >>> max distance threshold had to be increased to handle the Moon delay.

    >>
    >> Thats only a few sec.
    >> And it is symmetrical. Could probably still get usec resolution.


    >Of course it's not symmetrical. You of all people should know better
    >than that.


    The speed of light differs in different directions?
    And if the response is fast, the distance has not changed much either
    (In a msec the moon moves about a meter, which is 3nsec, way below any
    computer resultion)and that is amost all perp to the earth.Ie, the
    difference in distance during the response time of the remote computer is
    negligible. If you aim for the moon when the moon is just setting and you
    are on the equator, the difference in path lengths is about 5usec, again, a
    completely negligible amount.

    Now of course the synchronization will not proper time on the moon, but the
    sync of the earth clock.


    >Danny


  7. Re: frequency adjusting only

    Unruh wrote:
    > mayer@ntp.isc.org (Danny Mayer) writes:
    >
    >> Unruh wrote:
    >>> "David L. Mills" writes:
    >>>
    >>>> Brian,
    >>>> The longest delay NTP response was from the Moon, as simulated at JPL.
    >>>> Next step is the Mars orbiters and then the rovers. JPL discovered the
    >>>> max distance threshold had to be increased to handle the Moon delay.
    >>> Thats only a few sec.
    >>> And it is symmetrical. Could probably still get usec resolution.

    >
    >> Of course it's not symmetrical. You of all people should know better
    >> than that.

    >
    > The speed of light differs in different directions?
    > And if the response is fast, the distance has not changed much either
    > (In a msec the moon moves about a meter, which is 3nsec, way below any
    > computer resultion)and that is amost all perp to the earth.Ie, the
    > difference in distance during the response time of the remote computer is
    > negligible. If you aim for the moon when the moon is just setting and you
    > are on the equator, the difference in path lengths is about 5usec, again, a
    > completely negligible amount.
    >
    > Now of course the synchronization will not proper time on the moon, but the
    > sync of the earth clock.


    And neither the moon or other is moving along their geodesic?

    Danny

  8. Re: frequency adjusting only

    mayer@ntp.isc.org (Danny Mayer) writes:

    >Unruh wrote:
    >> mayer@ntp.isc.org (Danny Mayer) writes:
    >>
    >>> Unruh wrote:
    >>>> "David L. Mills" writes:
    >>>>
    >>>>> Brian,
    >>>>> The longest delay NTP response was from the Moon, as simulated at JPL.
    >>>>> Next step is the Mars orbiters and then the rovers. JPL discovered the
    >>>>> max distance threshold had to be increased to handle the Moon delay.
    >>>> Thats only a few sec.
    >>>> And it is symmetrical. Could probably still get usec resolution.

    >>
    >>> Of course it's not symmetrical. You of all people should know better
    >>> than that.

    >>
    >> The speed of light differs in different directions?
    >> And if the response is fast, the distance has not changed much either
    >> (In a msec the moon moves about a meter, which is 3nsec, way below any
    >> computer resultion)and that is amost all perp to the earth.Ie, the
    >> difference in distance during the response time of the remote computer is
    >> negligible. If you aim for the moon when the moon is just setting and you
    >> are on the equator, the difference in path lengths is about 5usec, again, a
    >> completely negligible amount.
    >>
    >> Now of course the synchronization will not proper time on the moon, but the
    >> sync of the earth clock.


    >And neither the moon or other is moving along their geodesic?


    The moon is, but that is irrelevant if the moon is the server.(Ie, if the
    earth is using ntp to query the moon to see how far off the moon's clock
    is). If the moon
    is the client, (Ie trying to sync to the earth) then the moon's motion
    is almost all perpendicular to the
    earth observer. ( It is only the component of the moon's motion that
    ncreases the distance from the earth that is important, which is onl;y 1/60
    of the moon's proper motion. ) That makes a difference in travel time only
    when the moon is rising or setting and even then it is only about 12m/s,
    which over the 5 sec travel time is only about .2usec, a trivial amount,
    lost in all other noises.

    It also depends on what synchronization frame you want to use
    (relativistically). But all of these corrections are at the usec level.



    >Danny


  9. Re: frequency adjusting only

    Dannt,

    There is a short briefing on NTP in space on the project page. The first
    use of NTP in space was on an AMSAT satellite in the early 80s. NTP has
    been used on Shuttle missions via UHF and TDRSS relay to NASA Goddard
    servers. I have Shuttle data that show more problems with the laptop
    running NTP than with NTP itself. Shuttle astronauts are really busy
    people and don't have time to explain occasional step adjustments.

    On symmetry, etc. There are both gravitational and velocity corrections
    relative to both Earth and solar system barycentric time amounting to
    some 15 ms, but current space missions don't worry much about that. The
    mission times are relative to a clock onboard the spacecraft; nothing
    else matters. Our Earth-Mars simulations didn't worry about these
    effects either. I suspect disciplining an orbiter/rover clock to these
    corrections will be dominated by the frequency noise of affordable
    oscillators. Maybe not.

    On accuracy. Ham radio EME "Moonbounce" experiments can calibrate Moon
    range to the millimeter, so there is no reason why NTP could not achieve
    comparable accuracy as on Earth. There is some talk about using GPS
    "backwards" for navigation on the Moon, but considerable question about
    workable signal levels. Proposed designs use some combination of
    orbiters and fixed sites which could also be used to distribute NTP time.

    The vehicle we designed for NASA/JPL consists of a standard issue NTP
    implementation with a front end that simulates motion in space. The
    simulator uses ephemeris data from JPL to produce state vectors, but the
    positions have some uncertainty resulting in some 10-ms lightime error.
    The real case with spacecraft navigation remains to be determined. My
    real worry is what rover timekeeing is like when the temperature ranges
    from 0 to 50 below C and when things get shut down in a duststorm.

    Dave

    Danny Mayer wrote:
    > Unruh wrote:
    >
    >>mayer@ntp.isc.org (Danny Mayer) writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>"David L. Mills" writes:
    >>>>
    >>>>
    >>>>>Brian,
    >>>>>The longest delay NTP response was from the Moon, as simulated at JPL.
    >>>>>Next step is the Mars orbiters and then the rovers. JPL discovered the
    >>>>>max distance threshold had to be increased to handle the Moon delay.
    >>>>
    >>>>Thats only a few sec.
    >>>>And it is symmetrical. Could probably still get usec resolution.

    >>
    >>>Of course it's not symmetrical. You of all people should know better
    >>>than that.

    >>
    >>The speed of light differs in different directions?
    >>And if the response is fast, the distance has not changed much either
    >>(In a msec the moon moves about a meter, which is 3nsec, way below any
    >>computer resultion)and that is amost all perp to the earth.Ie, the
    >>difference in distance during the response time of the remote computer is
    >>negligible. If you aim for the moon when the moon is just setting and you
    >>are on the equator, the difference in path lengths is about 5usec, again, a
    >>completely negligible amount.
    >>
    >>Now of course the synchronization will not proper time on the moon, but the
    >>sync of the earth clock.

    >
    >
    > And neither the moon or other is moving along their geodesic?
    >
    > Danny


  10. Re: frequency adjusting only

    "Unruh" wrote in message
    news:BK1Sj.3180$PM5.144@edtnps92...

    > [... Delay] assumed to be symmetric and is already cancelled. The
    > ONLY way to really measure if there assymetry is to put a real clock
    > on each of the machines (Ie, a clock synchronized to usec accuracy to
    > UTC-- eg a GPS PPS ) and measure the offset of each of the machines
    > from GPS time.


    I wonder. Would it be possible to rig a PPS signal that isn't really
    synchronised to anything, and distribute it to all the machines? It
    wouldn't even need to use a very precise second.

    (ISTR (possibly wrongly) that this was a single-lab setup. For a WAN
    situation, it would be useless.)

    Groetjes,
    Maarten Wiltink



  11. Re: frequency adjusting only

    On May 4, 2:37 pm, "David L. Mills" wrote:
    >
    > On symmetry, etc. There are both gravitational and velocity corrections
    > relative to both Earth and solar system barycentric time amounting to
    > some 15 ms, but current space missions don't worry much about that. The
    > mission times are relative to a clock onboard the spacecraft; nothing
    > else matters. Our Earth-Mars simulations didn't worry about these
    > effects either. I suspect disciplining an orbiter/rover clock to these
    > corrections will be dominated by the frequency noise of affordable
    > oscillators. Maybe not.


    Just curious, but did you have to deal with relativistic effects of
    relative time dilation as the craft speed increased?

    TIA

  12. Re: frequency adjusting only

    Evandro,

    We didn't account for gravity and time dilation, as the errors in the
    extrapolated ephemeris data dominated the error budget. I am told
    accurate spacecraft navigation needs time to the nanosecond. In
    principle, the Proximity-I protocol and NTP onwire protocol can do that,
    I don't think the transceiver clocks and onboard rover clocks are
    anywhere near that caliber.

    Dave

    Evandro Menezes wrote:
    > On May 4, 2:37 pm, "David L. Mills" wrote:
    >
    >>On symmetry, etc. There are both gravitational and velocity corrections
    >>relative to both Earth and solar system barycentric time amounting to
    >>some 15 ms, but current space missions don't worry much about that. The
    >>mission times are relative to a clock onboard the spacecraft; nothing
    >>else matters. Our Earth-Mars simulations didn't worry about these
    >>effects either. I suspect disciplining an orbiter/rover clock to these
    >>corrections will be dominated by the frequency noise of affordable
    >>oscillators. Maybe not.

    >
    >
    > Just curious, but did you have to deal with relativistic effects of
    > relative time dilation as the craft speed increased?
    >
    > TIA


  13. Re: frequency adjusting only

    "David L. Mills" writes:

    > Evandro,
    >
    > We didn't account for gravity and time dilation, as the errors in the
    > extrapolated ephemeris data dominated the error budget. I am told accurate
    > spacecraft navigation needs time to the nanosecond. In principle, the


    Wow! Spacecraft steering with nanosecond accuracy! Or did they talk about
    longtime stability as in the past for long (sea) ship journeys?

    Just wondering,
    Ulrich

    > Proximity-I protocol and NTP onwire protocol can do that, I don't think the
    > transceiver clocks and onboard rover clocks are anywhere near that caliber.


  14. Re: frequency adjusting only

    Ulrich,

    That's what JPL tells me, but I don't think they intend the orbiters and
    rovers to cling to the nanosecond, even if the Proximity-1 protocol has
    some distinctly awesome timestamping capabilities. Best we could do in
    simulation with ephemeris data was 10 ms, but that was mainly due to
    Chebychev polinomial interpolation. More details in the Initerplanetary
    Internet project at www.eecis.udel.edu/~mills/status.html.

    Dave

    Ulrich Windl wrote:
    > "David L. Mills" writes:
    >
    >
    >>Evandro,
    >>
    >>We didn't account for gravity and time dilation, as the errors in the
    >>extrapolated ephemeris data dominated the error budget. I am told accurate
    >>spacecraft navigation needs time to the nanosecond. In principle, the

    >
    >
    > Wow! Spacecraft steering with nanosecond accuracy! Or did they talk about
    > longtime stability as in the past for long (sea) ship journeys?
    >
    > Just wondering,
    > Ulrich
    >
    >
    >>Proximity-I protocol and NTP onwire protocol can do that, I don't think the
    >>transceiver clocks and onboard rover clocks are anywhere near that caliber.


+ Reply to Thread
Page 5 of 5 FirstFirst ... 3 4 5