NTP and SNTP in the end, give me precision of1ms? - NTP

This is a discussion on NTP and SNTP in the end, give me precision of1ms? - NTP ; Hello everybody! I am new here and I have a question that envolves NTP and SNTP implementations. I work with LAN systems and protocols that needs 1milisecond of precision(not resolution). I always use a GPS clock like Meinberg with Ethernet ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: NTP and SNTP in the end, give me precision of1ms?

  1. NTP and SNTP in the end, give me precision of1ms?

    Hello everybody!

    I am new here and I have a question that envolves NTP and SNTP
    implementations.
    I work with LAN systems and protocols that needs 1milisecond of
    precision(not resolution). I always use a GPS clock like Meinberg with
    Ethernet port to be my NTP/SNTP Server. The clients of this LAN are
    equipments in the same subnetwork and they are SNTP clients. So we have the
    hierarchical system:

    GPS Meinberg Clock - NTP/SNTP Server (Stratum 0?)
    Equipments with SNTP client using the Stratum 0 Server


    It always worked very well but I want to know if I mix NTP Servers and
    Clients with SNTP client, It will give me precision in the end? Let's
    imagine the hierarchical system below:
    GPS Clock - NTP Server (Stratum 0?)
    Workstation - NTP Client and Server (Stratum 1?)
    Workstation - NTP/SNTP Client and Server (Stratum 2?)
    Equipments with SNTP client implemented using the Stratum 2 Server.

    The NTP algorithm will give the precision of 1ms in the end, to the SNTP
    Clients? I know that the first solution is better and to be sure of the
    answer, it will depends on the network traffic, CPU, OS, etc but in theory
    this solution works for 1ms precision?

    Thank you everybody
    Barelo

  2. Re: NTP and SNTP in the end, give me precision of 1ms?

    marcelopimentacs@gmail.com (Marcelo Pimenta) writes:

    >Hello everybody!


    >I am new here and I have a question that envolves NTP and SNTP
    >implementations.
    >I work with LAN systems and protocols that needs 1milisecond of
    >precision(not resolution). I always use a GPS clock like Meinberg with
    >Ethernet port to be my NTP/SNTP Server. The clients of this LAN are
    >equipments in the same subnetwork and they are SNTP clients. So we have the
    >hierarchical system:


    >GPS Meinberg Clock - NTP/SNTP Server (Stratum 0?)
    > Equipments with SNTP client using the Stratum 0 Server


    The GPS is stratum 0. The computer synced to that (ntp server) is stratum 1


    >It always worked very well but I want to know if I mix NTP Servers and
    >Clients with SNTP client, It will give me precision in the end? Let's


    It depends on the quality of your SNTP clients. Some people are incompetent
    in writing computer programs. If you have one of their SNTP clients...

    There is nothing per se that makes this system impossible to deliver 1ms.
    Of course it depends of where those clients are-- if they are at the bottom
    of the sea communicating with 1bd/sec ultralow frequency radio, you will
    not get 1ms precision.



    >imagine the hierarchical system below:
    >GPS Clock - NTP Server (Stratum 0?)

    Stratum 1
    >Workstation - NTP Client and Server (Stratum 1?)

    Stratum 2

    >Workstation - NTP/SNTP Client and Server (Stratum 2?)


    Stratum 1 if its server is the first line.

    An SNTP canot be a server if it is not tied to a hardware clock.

    >Equipments with SNTP client implemented using the Stratum 2 Server.


    >The NTP algorithm will give the precision of 1ms in the end, to the SNTP
    >Clients? I know that the first solution is better and to be sure of the
    >answer, it will depends on the network traffic, CPU, OS, etc but in theory
    >this solution works for 1ms precision?


    Not enough information. It depends entirely on the network, network delays,
    etc.



    >Thank you everybody
    >Barelo


  3. Re: NTP and SNTP in the end, give me precision of 1ms?

    Unruh wrote:

    >
    > An SNTP canot be a server if it is not tied to a hardware clock.


    s/cannot/should not/ Pre-Windows 2003 versions of w32time are examples
    of some things that are commonly used in violation of the rule.

    Generally, though, Unruh is on the right lines; whilst you can make some
    assumptions about the abilities of an NTP client, you can make none
    about those of an SNTP one, as the specification says nothing about how
    it uses the measurements it makes. (NTP is still at the mercy of
    unusual configurations and hardware, software and networking issues.)

    SNTP clients are often used with very long poll intervals, that are not
    compatible with 1ms tracking.

  4. Re: NTP and SNTP in the end, give me precision of 1ms?

    David Woolley writes:

    >Unruh wrote:


    >>
    >> An SNTP canot be a server if it is not tied to a hardware clock.


    >s/cannot/should not/ Pre-Windows 2003 versions of w32time are examples
    >of some things that are commonly used in violation of the rule.


    I should have said, and SNTP which complies with the RFC specification....


    >Generally, though, Unruh is on the right lines; whilst you can make some
    >assumptions about the abilities of an NTP client, you can make none
    >about those of an SNTP one, as the specification says nothing about how
    >it uses the measurements it makes. (NTP is still at the mercy of
    >unusual configurations and hardware, software and networking issues.)


    >SNTP clients are often used with very long poll intervals, that are not
    >compatible with 1ms tracking.


  5. Re: NTP and SNTP in the end, give me precision of 1ms?


    >There is nothing per se that makes this system impossible to deliver 1ms.
    >Of course it depends of where those clients are-- if they are at the bottom
    >of the sea communicating with 1bd/sec ultralow frequency radio, you will
    >not get 1ms precision.


    What's wrong with a (very) slow link? As long as there aren't any
    queueing delays, the delay should be symmetric in both directions
    and I'd expect ntpd to work OK.

    Does 1 bd/sec overflow some of ntpd's assumptions? Would it need
    some minpoll tweaking?

    Or maybe I should ask: How slow a link is still useful?

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  6. Re: NTP and SNTP in the end, give me precision of 1ms?

    Hal Murray wrote:
    >> There is nothing per se that makes this system impossible to deliver 1ms.
    >> Of course it depends of where those clients are-- if they are at the bottom
    >> of the sea communicating with 1bd/sec ultralow frequency radio, you will
    >> not get 1ms precision.

    >
    > What's wrong with a (very) slow link? As long as there aren't any
    > queueing delays, the delay should be symmetric in both directions
    > and I'd expect ntpd to work OK.


    A one baud link would have an uncertainty of a second in the time,
    unless the transmit time stamps were synchronised with the signalling
    units. It would also have a delay that was on the limits of causing
    rejection for a normal NTP implementation.

    A 1 bit/second link would definitely have an unacceptable delay.

    A 1 baud/second link would have a continually varying latency, and,
    unless the bits per signalling unit varied to compensate, a continually
    varying delay. I don't think baud/second was the intended unit. I
    suspect he was suggesting a 1 bit per signalling unit, 1 signalling unit
    per second, case.
    >
    > Does 1 bd/sec overflow some of ntpd's assumptions? Would it need
    > some minpoll tweaking?
    >
    > Or maybe I should ask: How slow a link is still useful?
    >


  7. Re: NTP and SNTP in the end, give me precision of 1ms?

    David Woolley wrote:
    > Hal Murray wrote:
    >
    >>> There is nothing per se that makes this system impossible to deliver
    >>> 1ms. Of course it depends of where those clients are-- if they are at
    >>> the bottom
    >>> of the sea communicating with 1bd/sec ultralow frequency radio, you will
    >>> not get 1ms precision.

    >>
    >>
    >> What's wrong with a (very) slow link? As long as there aren't any
    >> queueing delays, the delay should be symmetric in both directions
    >> and I'd expect ntpd to work OK.

    >
    >
    > A one baud link would have an uncertainty of a second in the time,
    > unless the transmit time stamps were synchronised with the signalling
    > units. It would also have a delay that was on the limits of causing
    > rejection for a normal NTP implementation.
    >
    > A 1 bit/second link would definitely have an unacceptable delay.
    >
    > A 1 baud/second link would have a continually varying latency, and,
    > unless the bits per signalling unit varied to compensate, a continually
    > varying delay. I don't think baud/second was the intended unit. I
    > suspect he was suggesting a 1 bit per signalling unit, 1 signalling unit
    > per second, case.
    >
    >>
    >> Does 1 bd/sec overflow some of ntpd's assumptions? Would it need
    >> some minpoll tweaking?
    >>
    >> Or maybe I should ask: How slow a link is still useful?
    >>


    DCF77 for example is a "1 bit/s" transmission, a sentence taking 60s.
    It seems to not have issues with ms syncing.

    / bits/second and Baud can be a bit mushy: DCF can be
    viewed as a ternary code ( short, long, none ) /

    uwe

  8. Re: NTP and SNTP in the end, give me precision of 1ms?

    Uwe Klein wrote:

    >
    > DCF77 for example is a "1 bit/s" transmission, a sentence taking 60s.
    > It seems to not have issues with ms syncing.


    That's because it transmits rather a large number of bits per signalling
    unit. log2(resolution of timing of edge within second) bits of time
    information are sent on any long or short signalling unit. (In
    practice, you won't recover every bit on every measurement, so you need
    several seconds to improve the signal to noise ratio. Once one is
    synchronised, the number of useful bits drops greatly, because there is
    a very high level of redundancy in the coding.)

    There is nothing in NTP protoco that guarantees that signalling units
    are second aligned. However, one could get high resolution on very slow
    links by making the transmit time represent the start of signalling unit
    time, rather than the time the transmit request was queued. That would
    require special, low level, drivers.

  9. Re: NTP and SNTP in the end, give me precision of 1ms?

    David Woolley wrote:
    > Uwe Klein wrote:
    >
    >>
    >> DCF77 for example is a "1 bit/s" transmission, a sentence taking 60s.
    >> It seems to not have issues with ms syncing.

    >
    >
    > That's because it transmits rather a large number of bits per signalling
    > unit. log2(resolution of timing of edge within second) bits of time
    > information are sent on any long or short signalling unit. (In
    > practice, you won't recover every bit on every measurement, so you need
    > several seconds to improve the signal to noise ratio. Once one is
    > synchronised, the number of useful bits drops greatly, because there is
    > a very high level of redundancy in the coding.)
    >
    > There is nothing in NTP protoco that guarantees that signalling units
    > are second aligned. However, one could get high resolution on very slow
    > links by making the transmit time represent the start of signalling unit
    > time, rather than the time the transmit request was queued. That would
    > require special, low level, drivers.


    sure, you need a syncronised "carrier" or exact timestamps.
    But isn't that the basic assumption in all existing systems
    i.e edge or phase of the bitstream carries relevant information?

    uwe

  10. Re: NTP and SNTP in the end, give me precision of 1ms?

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>There is nothing per se that makes this system impossible to deliver 1ms.
    >>Of course it depends of where those clients are-- if they are at the bottom
    >>of the sea communicating with 1bd/sec ultralow frequency radio, you will
    >>not get 1ms precision.


    >What's wrong with a (very) slow link? As long as there aren't any
    >queueing delays, the delay should be symmetric in both directions
    >and I'd expect ntpd to work OK.


    And I would expect a many second difference in the delay times in the two
    directions. If nthing else but slightly different message lengths.

    >Does 1 bd/sec overflow some of ntpd's assumptions? Would it need
    >some minpoll tweaking?


    >Or maybe I should ask: How slow a link is still useful?


    >--
    >These are my opinions, not necessarily my employer's. I hate spam.



  11. Re: NTP and SNTP in the end, give me precision of 1ms?

    David Woolley writes:

    >Hal Murray wrote:
    >>> There is nothing per se that makes this system impossible to deliver 1ms.
    >>> Of course it depends of where those clients are-- if they are at the bottom
    >>> of the sea communicating with 1bd/sec ultralow frequency radio, you will
    >>> not get 1ms precision.

    >>
    >> What's wrong with a (very) slow link? As long as there aren't any
    >> queueing delays, the delay should be symmetric in both directions
    >> and I'd expect ntpd to work OK.


    >A one baud link would have an uncertainty of a second in the time,
    >unless the transmit time stamps were synchronised with the signalling
    >units. It would also have a delay that was on the limits of causing
    >rejection for a normal NTP implementation.


    >A 1 bit/second link would definitely have an unacceptable delay.


    >A 1 baud/second link would have a continually varying latency, and,
    >unless the bits per signalling unit varied to compensate, a continually
    >varying delay. I don't think baud/second was the intended unit. I
    >suspect he was suggesting a 1 bit per signalling unit, 1 signalling unit
    >per second, case.


    Nope, 1 bit per sec as an off the top of my head estimate of the rate for
    an ultra longwavelength radio link with a submarine under the ocean.
    ..

    >>
    >> Does 1 bd/sec overflow some of ntpd's assumptions? Would it need
    >> some minpoll tweaking?
    >>
    >> Or maybe I should ask: How slow a link is still useful?
    >>


  12. Re: NTP and SNTP in the end, give me precision of 1ms?

    Unruh wrote:
    > David Woolley writes:
    >> A 1 baud/second link would have a continually varying latency, and,
    >> unless the bits per signalling unit varied to compensate, a continually
    >> varying delay. I don't think baud/second was the intended unit. I
    >> suspect he was suggesting a 1 bit per signalling unit, 1 signalling unit
    >> per second, case.

    >
    > Nope, 1 bit per sec as an off the top of my head estimate of the rate for
    > an ultra longwavelength radio link with a submarine under the ocean.


    I don't think you get the point. A baud is a signalling unit per
    second. A signalling unit can carry many bits, and in most transmission
    systems does carry more than one bit. As I said, I think you are
    assuming the degenerate case where one signalling unit carries one bit,
    and the baud rate and bits per second are the same, and equal to 1.

    Incidentally, it would make a lot of sense to me if the strategic
    submarine communication systems used multiple bits per signalling unit.

    Examples of bits per second and bauds differing are:

    56kbps modem (8k baud).

    ADSL (each sub-carrier carries a bit, so there is quite a large ratio).

    QAM modems, 1200 baud and 9600 bps.

    When marketing and popular computing literature refers to the higher
    speed as the baudrate, they are only correct for the baseband signal,
    not for the signal over the wire. The actual signalling unit rate is
    important for propagation delay, though, especially over synchronous
    channels.

    Note packet length needn't matter, on a single hop, as you can calculate
    the start of packet time when working out the transmit and receive
    timestamps, even if the reference implementation doesn't do that. It
    does in a store and forward environment, but note that I believe some
    more sophisticated routers can start forwarding as soon as they have
    enough information to select the outgoing link.

  13. Re: NTP and SNTP in the end, give me precision of 1ms?


    >>What's wrong with a (very) slow link? As long as there aren't any
    >>queueing delays, the delay should be symmetric in both directions
    >>and I'd expect ntpd to work OK.

    >
    >And I would expect a many second difference in the delay times in the two
    >directions. If nthing else but slightly different message lengths.


    I thought NTP packets were the same length in both directions.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread