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 ; Terje Mathisen wrote: > 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

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

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

    Terje Mathisen wrote:
    > 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.


    Another way to get accuracy in the range of a few nanoseconds is what
    IEEE1588 (PTP) does. It picks up a time stamp whenever a packet really
    comes from the network cable, or goes onto the cable.

    Thus the protocol can eliminate latencies of the IP stack and the
    transmission time between 2 nodes can be reduced to the pure cable delay.
    However, special hardware time stamp unit (TSU) is required in the NIC to
    match the packet patterns and pick up a time stamp. Without that special
    TSU the accuracy is also in the range achieved by NTP.

    The accuracy is also degraded if there are switches involved which are not
    PTP-aware and queue all packets internally for up to several milliseconds.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    On Mon, 17 Jul 2006 00:42:44 -0400 in comp.protocols.time.ntp,
    "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.


    Close to state of the art on 10GbE is 450ns switching delay and 6ns/m
    propagation delay; 232ps allows for ~40mm cable, with a theoretical
    limit of ~70mm at c, so is likely to be adequate for any connection.
    Internal resolution *may* require another byte, but current machine
    architecture seems to be a limiting factor on instruction thruput near
    4GHz, vendors are going multithreaded and multicore, and further
    advances may require a new architecture or different technology.

    >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.


    The caesium standard time transitions are only about 110ps, so either
    that's good enough for almost all purposes, or they need a newer
    standard before NTP is likely to be affected.

    --
    Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

    Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address use address above to reply

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

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

    [...]
    > 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.


    Talking about 128bit time formats or so: With today's computing power (just
    think of MP3 decoders), a switch to BCD coded time in 128 bit should be
    sufficient:
    Byte#: 1 2 3 4 5 6 7 8 910 111213 141516
    Value:2006-07-18 09:26:13.12 1234 567890 123456

    So you'd have significant sub-picosecond resolution and peace until year
    "9999".

    Regards,
    Ulrich

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

    Ulrich Windl wrote:
    > mayer@ntp.isc.org (Danny Mayer) writes:
    >
    > [...]
    >> 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.

    >
    > Talking about 128bit time formats or so: With today's computing power (just
    > think of MP3 decoders), a switch to BCD coded time in 128 bit should be
    > sufficient:
    > Byte#: 1 2 3 4 5 6 7 8 910 111213 141516
    > Value:2006-07-18 09:26:13.12 1234 567890 123456
    >
    > So you'd have significant sub-picosecond resolution and peace until year
    > "9999".


    Not at all, unfortunately!

    Your time format is perfect for recording civilian events, but just as
    useless as "UTC_with_pretend_no_leapseconds" for NTP which needs a
    monotonic time scale. :-(

    I.e. we need both ISO style date/time and TAI, and it is only for past
    events that you can know how to do an exact conversion to/from these
    formats.

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

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

    Ulrich Windl wrote:
    > mayer@ntp.isc.org (Danny Mayer) writes:
    >
    > [...]
    >
    >>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.

    >
    >
    > Talking about 128bit time formats or so: With today's computing power (just
    > think of MP3 decoders), a switch to BCD coded time in 128 bit should be
    > sufficient:
    > Byte#: 1 2 3 4 5 6 7 8 910 111213 141516
    > Value:2006-07-18 09:26:13.12 1234 567890 123456
    >
    > So you'd have significant sub-picosecond resolution and peace until year
    > "9999".
    >
    > Regards,
    > Ulrich


    Do YOU want to write the code to manipulate that format? It looks like
    a nightmare to me!

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

    Richard B. Gilbert wrote:
    > Ulrich Windl wrote:
    >> Talking about 128bit time formats or so: With today's computing power
    >> (just
    >> think of MP3 decoders), a switch to BCD coded time in 128 bit should be
    >> sufficient:
    >> Byte#: 1 2 3 4 5 6 7 8 910 111213 141516
    >> Value:2006-07-18 09:26:13.12 1234 567890 123456
    >>
    >> So you'd have significant sub-picosecond resolution and peace until year
    >> "9999".
    >>
    >> Regards,
    >> Ulrich

    >
    > Do YOU want to write the code to manipulate that format? It looks like
    > a nightmare to me!


    Not at all! It is in effect identical to standard ISO format, plus the
    fractional part, except for the two-to-one compression achieved by
    storing in BCD instead of ASCII, but that particular conversion is of
    course trivial.

    BTW, I have written code to convert both ways, between ISO and Unix/NTP
    seconds, and it is the seconds-to-ISO operations which is the tough one:
    The naive code takes several hundred clock cycles to do this, while my
    version did it close to an order of magnitude faster. :-)

    For the ascii/bcd fractional part I have also invented a way to convert
    a 32-bit unsigned number from binary to ascii (the reverse is easy of
    course) in something like 30-50 clock cycles. AMD stole/borrowed this
    code (or about 95% of it), without attribution, for their optimization
    guide.

    Terje

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

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

    Terje Mathisen wrote:

    > Richard B. Gilbert wrote:
    >
    >> Ulrich Windl wrote:
    >>
    >>> Talking about 128bit time formats or so: With today's computing power
    >>> (just
    >>> think of MP3 decoders), a switch to BCD coded time in 128 bit should be
    >>> sufficient:
    >>> Byte#: 1 2 3 4 5 6 7 8 910 111213 141516
    >>> Value:2006-07-18 09:26:13.12 1234 567890 123456
    >>>
    >>> So you'd have significant sub-picosecond resolution and peace until year
    >>> "9999".
    >>>
    >>> Regards,
    >>> Ulrich

    >>
    >>
    >> Do YOU want to write the code to manipulate that format? It looks
    >> like a nightmare to me!

    >
    >
    > Not at all! It is in effect identical to standard ISO format, plus the
    > fractional part, except for the two-to-one compression achieved by
    > storing in BCD instead of ASCII, but that particular conversion is of
    > course trivial.
    >
    > BTW, I have written code to convert both ways, between ISO and Unix/NTP
    > seconds, and it is the seconds-to-ISO operations which is the tough one:
    > The naive code takes several hundred clock cycles to do this, while my
    > version did it close to an order of magnitude faster. :-)
    >
    > For the ascii/bcd fractional part I have also invented a way to convert
    > a 32-bit unsigned number from binary to ascii (the reverse is easy of
    > course) in something like 30-50 clock cycles. AMD stole/borrowed this
    > code (or about 95% of it), without attribution, for their optimization
    > guide.
    >
    > Terje
    >


    I was thinking of the cost of doing all the arithmetic in BCD. The NTP
    timestamps are exchanged between systems for the purpose of
    synchronizing to UTC; there is no advantage to exchanging them in BCD.
    They do not have to be "people readable"!

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

    Richard B. Gilbert wrote:
    > I was thinking of the cost of doing all the arithmetic in BCD. The NTP
    > timestamps are exchanged between systems for the purpose of
    > synchronizing to UTC; there is no advantage to exchanging them in BCD.
    > They do not have to be "people readable"!


    OK, that's perfectly valid. I agree that the NTP protocol should always
    use a compact format which is hardware friendly, i.e. something _very_
    similar to the current 32:32 fixed-bit format. The only obvious
    improvement would be for all packets to also keep around a TAI-UTC
    offset number, since that would make it trivial to handle both leap
    seconds and provide the OS/applications with a monotonic time scale
    along with the regular UTC pseudo-seconds.

    OTOH, using BCD really wouldn't matter much since effectively all
    (modulo a few startup packets with -g in force) NTP timestamp
    comparisons/subtractions happen on numbers which are very close, i.e.
    only the seconds and fraction fields needs to be operated on, and this
    is easy to do in parallel for BCD numbers, it is only a small constant
    factor slower than a binary subtraction.

    The other important part, which is steering the local clock via adjtime
    is much more dependent upon binary numbers, since it needs to do
    multiplications and/or divisions on fractional numbers.

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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2