NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide - NTP

This is a discussion on NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide - NTP ; 1. The different modes are (in sum and total) a good design decision. 2. NTP5, when it is created -- will probably be more evolutionary in design. 3. The 32 bits (or 128 bits) mode could be used to get ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

  1. NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    1. The different modes are (in sum and total) a good design decision.
    2. NTP5, when it is created -- will probably be more evolutionary in design.
    3. The 32 bits (or 128 bits) mode could be used to get around the times when
    NTP fields all go to '0'

    >> NTP4 has 3 different time formats!
    >> Namly (32, 64, 128) bits wide.

    >
    > The i386 has commands to operate on 4 bits, 8 bits, 16 bits, 32 bits, and
    > 64
    > bits, but what are you saying?




  2. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    "Max Power" writes:

    > 1. The different modes are (in sum and total) a good design decision.
    > 2. NTP5, when it is created -- will probably be more evolutionary in design.
    > 3. The 32 bits (or 128 bits) mode could be used to get around the times when
    > NTP fields all go to '0'


    NTP being a network protocol with an implementation: Where in the network
    protocol are timestamps of 64 and 128 bits? Please explain!

    Ulrich

    >
    > >> NTP4 has 3 different time formats!
    > >> Namly (32, 64, 128) bits wide.

    > >
    > > The i386 has commands to operate on 4 bits, 8 bits, 16 bits, 32 bits, and
    > > 64
    > > bits, but what are you saying?


  3. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    Ulrich Windl wrote:
    > "Max Power" writes:
    >
    >
    >>1. The different modes are (in sum and total) a good design decision.
    >>2. NTP5, when it is created -- will probably be more evolutionary in design.
    >>3. The 32 bits (or 128 bits) mode could be used to get around the times when
    >>NTP fields all go to '0'

    >
    >
    > NTP being a network protocol with an implementation: Where in the network
    > protocol are timestamps of 64 and 128 bits? Please explain!
    >
    > Ulrich
    >


    See RFC-1305 page 50. In the description of the packet format the four
    timestamps are all shown as 64 bits. AFAIK 32 and 128 bit timestamps
    are a figment of someone's imagination.

  4. Re: Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Richard B. Gilbert wrote:
    >
    > See RFC-1305 page 50. In the description of the packet format the four
    > timestamps are all shown as 64 bits. AFAIK 32 and 128 bit timestamps
    > are a figment of someone's imagination.
    >


    No, they are defined. You can find them in Das Buch and I believe the
    latest version of the NTP protocol in draft for the IETF WG.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Richard B. Gilbert wrote:
    > Danny Mayer wrote:
    >
    >> Richard B. Gilbert wrote:
    >>
    >>> See RFC-1305 page 50. In the description of the packet format the four
    >>> timestamps are all shown as 64 bits. AFAIK 32 and 128 bit timestamps
    >>> are a figment of someone's imagination.
    >>>

    >>
    >>
    >> No, they are defined. You can find them in Das Buch and I believe the
    >> latest version of the NTP protocol in draft for the IETF WG.
    >>
    >> Danny
    >> _______________________________________________
    >> questions mailing list
    >> questions@lists.ntp.isc.org
    >> https://lists.ntp.isc.org/mailman/listinfo/questions
    >>

    >
    > They have not been implemented, have they? They are not yet part of a
    > standard are they?
    >
    > Wherever someone may have speculated about them, I think that, until
    > they become part of an adopted standard and/or are implemented, it is
    > fair to call them a figment of someone's imagination!
    >
    > I believe that we run out of bits in about thirty years. It's clear
    > that we will need more. The need for a 32-bit timestamp is less than
    > clear!
    >


    Well VMS always used 64 bits for time. Windows has now added a 64 bit
    version of time_t and introduced 64-bit time functions. I don't think
    that the *BSD's will be far behind. Dunno about Linux or Solaris.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    Danny Mayer wrote:

    > Richard B. Gilbert wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>
    >>>Richard B. Gilbert wrote:
    >>>
    >>>
    >>>>See RFC-1305 page 50. In the description of the packet format the four


    >
    >
    > Well VMS always used 64 bits for time. Windows has now added a 64 bit
    > version of time_t and introduced 64-bit time functions. I don't think
    > that the *BSD's will be far behind. Dunno about Linux or Solaris.
    >


    NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    was a count of 100 nanosecond "ticks" since some date in (I think)
    November 1857. The format will represent any date-time from the base
    date through the next thirty thousand years or so. Of course VMS
    updates the clock by adding 10,000 "ticks" at a time. There is no
    documented or supported interface that will allow you to set or read the
    clock to greater than centisecond precision. I've often thought that
    VMS Engineering should support a little greater precision; Solaris can
    keep time to microsecond precision and even, with NTP, keep it
    accurately to that precision!

    The current 64 bit NTP timestamp wastes some bits in picosecond
    precision. I say "wastes" because even today's computers cannot
    exchange time without an uncertainty of two or three microseconds and
    those low order bits are meaningless noise.


  7. Re: Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Richard B. Gilbert wrote:
    >
    > NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    > was a count of 100 nanosecond "ticks" since some date in (I think)
    > November 1857.


    18 November, 1857 to be exact! See, I still remember!

    The format will represent any date-time from the base
    > date through the next thirty thousand years or so.


    Actually I think it was only to the year 8000 or something for some reason.

    Of course VMS
    > updates the clock by adding 10,000 "ticks" at a time. There is no
    > documented or supported interface that will allow you to set or read the
    > clock to greater than centisecond precision. I've often thought that
    > VMS Engineering should support a little greater precision;


    At the time that was about as good as you could get. Don't forget that
    VMS was originally designed in the mid-70's and first released in 1977.
    Who could imagine that kind of precision in those days? And clocks were
    not that good in those days. I remember working developing the clock
    module tester for the Aquarius line (VAX 9000) at the end of the 1980's
    and the precision that you could achieve was not that good at the time.

    > Solaris can
    > keep time to microsecond precision and even, with NTP, keep it
    > accurately to that precision!
    >


    Solaris is modern in comparison.

    > The current 64 bit NTP timestamp wastes some bits in picosecond
    > precision. I say "wastes" because even today's computers cannot
    > exchange time without an uncertainty of two or three microseconds and
    > those low order bits are meaningless noise.
    >


    That's for today. In 10 years that may very well not be true.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  8. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    Danny Mayer wrote:

    > Richard B. Gilbert wrote:
    >
    >>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>was a count of 100 nanosecond "ticks" since some date in (I think)
    >>November 1857.

    >


    >
    >>The current 64 bit NTP timestamp wastes some bits in picosecond
    >>precision. I say "wastes" because even today's computers cannot
    >>exchange time without an uncertainty of two or three microseconds and
    >>those low order bits are meaningless noise.
    >>

    >
    >
    > That's for today. In 10 years that may very well not be true.
    >


    The limitation, I believe, is in the round trip delay. My Sun Ultra
    10s, separated by a Cisco 1548M switch and a few feet of cable, show
    delays of the order of 4 microseconds at 100mb full duplex. Gigabit
    Ethernet might shave a little off of that but not a whole lot.

    If you are getting time over the internet you don't, and won't, have a
    clue what the nanoseconds should be. Even over a fast LAN, the delay is
    a killer.


  9. Re: Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Danny Mayer wrote:
    > Richard B. Gilbert wrote:
    >>
    >> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >> was a count of 100 nanosecond "ticks" since some date in (I think)
    >> November 1857.

    >
    > 18 November, 1857 to be exact! See, I still remember!


    I often wondered why that base was chosen - something to do with the
    Smithsonian?

    David



  10. Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    On 2006-07-14, David J Taylor wrote:
    >> 18 November, 1857 to be exact! See, I still remember!

    >
    > I often wondered why that base was chosen - something to do with the
    > Smithsonian?


    That date is the epoch of Modified Julian Date. Which is JD -
    2400000.5


  11. Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    David J Taylor wrote:

    > Danny Mayer wrote:
    >
    >>Richard B. Gilbert wrote:
    >>
    >>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>>was a count of 100 nanosecond "ticks" since some date in (I think)
    >>>November 1857.

    >>
    >>18 November, 1857 to be exact! See, I still remember!

    >
    >
    > I often wondered why that base was chosen - something to do with the
    > Smithsonian?
    >
    > David
    >
    >

    Something to do with the Smithsonian and an astronomer's star catalog.

    One suspects that these various base dates were chosen by rolling dice,
    flipping coins, or picking them out of a hat. They all work. More or less!

  12. Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Greg Hennessy wrote:
    > On 2006-07-14, David J Taylor
    > wrote:
    >>> 18 November, 1857 to be exact! See, I still remember!

    >>
    >> I often wondered why that base was chosen - something to do with the
    >> Smithsonian?

    >
    > That date is the epoch of Modified Julian Date. Which is JD -
    > 2400000.5


    Thanks,
    David



  13. Re: Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bits wide

    Richard B. Gilbert wrote:
    > Danny Mayer wrote:
    >
    >> Richard B. Gilbert wrote:
    >>
    >>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>> was a count of 100 nanosecond "ticks" since some date in (I think)
    >>> November 1857.

    >>

    >
    >>
    >>> The current 64 bit NTP timestamp wastes some bits in picosecond
    >>> precision. I say "wastes" because even today's computers cannot
    >>> exchange time without an uncertainty of two or three microseconds and
    >>> those low order bits are meaningless noise.
    >>>

    >>
    >>
    >> That's for today. In 10 years that may very well not be true.
    >>

    >
    > The limitation, I believe, is in the round trip delay. My Sun Ultra
    > 10s, separated by a Cisco 1548M switch and a few feet of cable, show
    > delays of the order of 4 microseconds at 100mb full duplex. Gigabit
    > Ethernet might shave a little off of that but not a whole lot.
    >
    > If you are getting time over the internet you don't, and won't, have a
    > clue what the nanoseconds should be. Even over a fast LAN, the delay is
    > a killer.
    >


    On a network, that's true enough and is likely to be for a while,
    despite Internet 2 and other advances. However, we also have refclocks
    that are not limited in that way and I don't necessarily mean just GPS.
    There are other technologies coming along which have the potential for
    much improved accuracy. The current limitations there will be likely the
    path between the peripherals and the drivers, the O/S and NTP itself.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  14. Re: Re: NTP4 has 3 different time formats!Namly(32, 64, 128) bits wide

    David J Taylor wrote:
    > Danny Mayer wrote:
    >> Richard B. Gilbert wrote:
    >>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>> was a count of 100 nanosecond "ticks" since some date in (I think)
    >>> November 1857.

    >> 18 November, 1857 to be exact! See, I still remember!

    >
    > I often wondered why that base was chosen - something to do with the
    > Smithsonian?
    >


    Oops, I'm off by a year, it's 1858. From this URL if you want all of the
    details: http://vms.tuwien.ac.at/info/humour/...ime-origin.txt

    "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
    1858.
    [...]

    The Modified Julian Day was adopted by the Smithsonian Astrophysical
    Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
    satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
    when Sputnik was launched. The Julian day was 2,435,839 on January 1,
    1957. This is 11,225,377 in octal notation, which was too big to fit
    into an 18-bit field (half of its standard 36-bit word). And, with only
    8K of memory, no one wanted to waste the 14 bits left over by keeping
    the Julian Day in its own 36-bit word. However, they also needed to
    track hours and minutes, for which 18 bits gave enough accuracy. So,
    they decided to keep the number of days in the left 18 bits and the
    hours and minutes in the right 18 bits of a word."

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  15. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bits wide

    Danny Mayer wrote:

    > Richard B. Gilbert wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>
    >>>Richard B. Gilbert wrote:
    >>>
    >>>
    >>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>>>was a count of 100 nanosecond "ticks" since some date in (I think)
    >>>>November 1857.
    >>>

    >>
    >>
    >>>>The current 64 bit NTP timestamp wastes some bits in picosecond
    >>>>precision. I say "wastes" because even today's computers cannot
    >>>>exchange time without an uncertainty of two or three microseconds and
    >>>>those low order bits are meaningless noise.
    >>>>
    >>>
    >>>
    >>>That's for today. In 10 years that may very well not be true.
    >>>

    >>
    >>The limitation, I believe, is in the round trip delay. My Sun Ultra
    >>10s, separated by a Cisco 1548M switch and a few feet of cable, show
    >>delays of the order of 4 microseconds at 100mb full duplex. Gigabit
    >>Ethernet might shave a little off of that but not a whole lot.
    >>
    >>If you are getting time over the internet you don't, and won't, have a
    >>clue what the nanoseconds should be. Even over a fast LAN, the delay is
    >>a killer.
    >>

    >
    >
    > On a network, that's true enough and is likely to be for a while,
    > despite Internet 2 and other advances. However, we also have refclocks
    > that are not limited in that way and I don't necessarily mean just GPS.
    > There are other technologies coming along which have the potential for
    > much improved accuracy. The current limitations there will be likely the
    > path between the peripherals and the drivers, the O/S and NTP itself.
    >


    I'm sure that it's possible to integrate a refclock and a computer in
    such a way the that time down to the picosecond level is gated directly
    onto the computers data bus and so that computer will know what the nano
    and pico seconds are. It still will not be able to convey that
    information to another computer without loss of precision. The more
    distant the two computers, the more difficult the problem becomes.

  16. Re: Re: NTP4 has 3 different time formats!Namly(32, 64, 128) bits wide

    Danny Mayer wrote:
    > David J Taylor wrote:
    >> Danny Mayer wrote:
    >>> Richard B. Gilbert wrote:
    >>>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC
    >>>> it was a count of 100 nanosecond "ticks" since some date in (I
    >>>> think) November 1857.
    >>> 18 November, 1857 to be exact! See, I still remember!

    >>
    >> I often wondered why that base was chosen - something to do with the
    >> Smithsonian?
    >>

    >
    > Oops, I'm off by a year, it's 1858. From this URL if you want all of
    > the details:
    > http://vms.tuwien.ac.at/info/humour/...ime-origin.txt
    >
    > "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
    > 1858.
    > [...]
    >
    > The Modified Julian Day was adopted by the Smithsonian Astrophysical
    > Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
    > satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
    > when Sputnik was launched. The Julian day was 2,435,839 on January 1,
    > 1957. This is 11,225,377 in octal notation, which was too big to fit
    > into an 18-bit field (half of its standard 36-bit word). And, with
    > only 8K of memory, no one wanted to waste the 14 bits left over by
    > keeping the Julian Day in its own 36-bit word. However, they also
    > needed to track hours and minutes, for which 18 bits gave enough
    > accuracy. So, they decided to keep the number of days in the left 18
    > bits and the hours and minutes in the right 18 bits of a word."
    >
    > Danny


    Thanks, Danny. The reference also states:

    "The year 1858 preceded the oldest star catalog in use at SAO, which
    also avoided having to use negative time in any of the satellite tracking
    calculations."

    which explains why that particular year was chosen as the new base for
    Modified Julian Date. It then goes on to say:

    "This base time of Nov. 17, 1858 has since been used by TOPS-10,
    TOPS-20, and VAX/VMS. Given this base date, the 100 nanosecond
    granularity implemented within VAX/VMS, and the 63-bit absolute time
    representation (the sign bit must be clear), VMS should have no trouble
    with time until:

    31-JUL-31086 02:48:05.47

    "At this time, all clocks and time-keeping operations within VMS will
    suddenly stop, as system time values go negative.

    "Note that all time display and manipulation routines within VMS allow
    for only 4 digits within the 'YEAR' field. We [Digital] expect this to be
    corrected in a future release of VAX/VMS sometime prior to 31-DEC-9999."



    David



  17. Re: NTP4 has 3 different time formats! Namly(32, 64, 128) bitswide

    Danny,

    Careful what you say about the 704; I learned machine programming on it
    in 1959. It had not 8K, but 32K of 36-bit words divided into four fields
    in bigendian order, 3-bit opcode, 15-bit decrement (used in loop
    instructions) known by Lispers as CDR, 3-bit tag (index register select)
    and 15-bit address known by Lispers as CAR. It would be absolutely
    stupid to divide the word in two 18-bit fields and very expensive in
    programming. So far as I remember, the time was kept in two 36-bit
    words, but then that was specific to the U Michigan operating system. In
    that era there were lots of operating systems, all different and all
    incompatible.

    In 1957 your reference might be the 1820 or even the 650, which was an
    absolutely stupid machine that used tables to do arithmetic add. The
    1820 I remember fell of the back of a truck and was destroyed. The last
    704 I remember was buried in the Negev desert because the Israelis
    wouldn't pay the rent beyond one year. The Universities got them for
    free, at least until the Feds told IBM they couldn't write them off for
    tax purposes.

    The successor to the 704 was the 709, also using vacuum tubes, and that
    succeeded by the 709T (for transistorized), popularly called the 7090,
    and then the 7094. The 70x breed was dead by 1968, killed by the System/360.

    Dave

    Danny Mayer wrote:
    > David J Taylor wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>>Richard B. Gilbert wrote:
    >>>
    >>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>>>was a count of 100 nanosecond "ticks" since some date in (I think)
    >>>>November 1857.
    >>>
    >>>18 November, 1857 to be exact! See, I still remember!

    >>
    >>I often wondered why that base was chosen - something to do with the
    >>Smithsonian?
    >>

    >
    >
    > Oops, I'm off by a year, it's 1858. From this URL if you want all of the
    > details: http://vms.tuwien.ac.at/info/humour/...ime-origin.txt
    >
    > "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
    > 1858.
    > [...]
    >
    > The Modified Julian Day was adopted by the Smithsonian Astrophysical
    > Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
    > satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
    > when Sputnik was launched. The Julian day was 2,435,839 on January 1,
    > 1957. This is 11,225,377 in octal notation, which was too big to fit
    > into an 18-bit field (half of its standard 36-bit word). And, with only
    > 8K of memory, no one wanted to waste the 14 bits left over by keeping
    > the Julian Day in its own 36-bit word. However, they also needed to
    > track hours and minutes, for which 18 bits gave enough accuracy. So,
    > they decided to keep the number of days in the left 18 bits and the
    > hours and minutes in the right 18 bits of a word."
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  18. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bitswide

    Richard,

    I can't claim preconition, as the current NTP timestamp format was
    invented in 1978 when nominal accuracies were in the 16-ms range.
    However, the resolution limit of 232 picoseconds is likely to be
    exceeded when the CPU clock rate approaches 4 GHz, which might not be
    long off.

    Dave

    Danny Mayer wrote:

    > Richard B. Gilbert wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>
    >>>Richard B. Gilbert wrote:
    >>>
    >>>
    >>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
    >>>>was a count of 100 nanosecond "ticks" since some date in (I think)
    >>>>November 1857.
    >>>

    >>
    >>
    >>>>The current 64 bit NTP timestamp wastes some bits in picosecond
    >>>>precision. I say "wastes" because even today's computers cannot
    >>>>exchange time without an uncertainty of two or three microseconds and
    >>>>those low order bits are meaningless noise.
    >>>>
    >>>
    >>>
    >>>That's for today. In 10 years that may very well not be true.
    >>>

    >>
    >>The limitation, I believe, is in the round trip delay. My Sun Ultra
    >>10s, separated by a Cisco 1548M switch and a few feet of cable, show
    >>delays of the order of 4 microseconds at 100mb full duplex. Gigabit
    >>Ethernet might shave a little off of that but not a whole lot.
    >>
    >>If you are getting time over the internet you don't, and won't, have a
    >>clue what the nanoseconds should be. Even over a fast LAN, the delay is
    >>a killer.
    >>

    >
    >
    > On a network, that's true enough and is likely to be for a while,
    > despite Internet 2 and other advances. However, we also have refclocks
    > that are not limited in that way and I don't necessarily mean just GPS.
    > There are other technologies coming along which have the potential for
    > much improved accuracy. The current limitations there will be likely the
    > path between the peripherals and the drivers, the O/S and NTP itself.
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  19. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bitswide

    David L. Mills wrote:

    > Richard,
    >
    > I can't claim preconition, as the current NTP timestamp format was
    > invented in 1978 when nominal accuracies were in the 16-ms range.
    > However, the resolution limit of 232 picoseconds is likely to be
    > exceeded when the CPU clock rate approaches 4 GHz, which might not be
    > long off.
    >


    I suppose that even a 2 GHz machine could slice time into 500 picosecond
    increments. But I was thinking in terms of the ability to set a clock
    that accurately. There's no way that I can think of that it could be
    done over a network using today's technology. I'm seeing a ~4us delays
    on my 100 Mb full duplex LAN. I think that means I can't pass time from
    machine A to machine B over my LAN without an uncertainty of ~2us.
    The error is probably less than that but probably is the best we can say.

    So you could get delta time measurments with 232 picosecond resolution
    but getting absolute time accurately with that precsion is not going to
    be easy.

  20. Re: NTP4 has 3 different time formats! Namly (32, 64, 128) bitswide

    Richard B. Gilbert wrote:
    > David L. Mills wrote:
    >
    >> Richard,
    >>
    >> I can't claim preconition, as the current NTP timestamp format was
    >> invented in 1978 when nominal accuracies were in the 16-ms range.
    >> However, the resolution limit of 232 picoseconds is likely to be
    >> exceeded when the CPU clock rate approaches 4 GHz, which might not be
    >> long off.
    >>

    >
    > I suppose that even a 2 GHz machine could slice time into 500 picosecond
    > increments. But I was thinking in terms of the ability to set a clock
    > that accurately. There's no way that I can think of that it could be
    > done over a network using today's technology. I'm seeing a ~4us delays
    > on my 100 Mb full duplex LAN. I think that means I can't pass time from
    > machine A to machine B over my LAN without an uncertainty of ~2us. The
    > error is probably less than that but probably is the best we can say.
    >
    > So you could get delta time measurments with 232 picosecond resolution
    > but getting absolute time accurately with that precsion is not going to
    > be easy.


    If you can get _repeatable_, at least some of the time, 4 us delays,
    then you can use the same statistical methods which NTP is already using
    to get absolute accuracy close to an order of magnitude better, i.e.
    half a us or so.

    The real limiter will be the need for (a) a really good local clock
    source, i.e. better than the current 10 cent (?) quartz crystals, and
    (b) a hardware method to measure the interrupt latency.

    Poul-Henning of FreeBSD and NTP fame did both on his _very_ good NTP
    servers, it might be possible that some new motherboards will include a
    timing facility to handle (b).

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"