tool to collect statistics on round trip delay offset? - NTP

This is a discussion on tool to collect statistics on round trip delay offset? - NTP ; Are there any monitoring tools that allow you to collect statistics on the round trip delay, and offset without using the data. On a small, self contained network, (using no routers, just cisco switches), I have multiple servers that I ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: tool to collect statistics on round trip delay offset?

  1. tool to collect statistics on round trip delay offset?

    Are there any monitoring tools that allow you to collect statistics on the
    round trip delay, and offset without using the data.

    On a small, self contained network, (using no routers, just cisco switches),
    I have multiple servers that I want to be in sync to < 1ms (200-300 usec
    ideally). It is not so important how well these match to GMT, but it is very
    important that they agree with each other. They are used to time tag event
    data that needs to be correlated across servers.

    I want to take some statistics on the measurement jitter (both offset and
    round trip delay) of a typical NTP packet. I envision a utility that would
    send the UPD NTP packets, and be able to calculate delay and offset from a
    specific server (but not use the data), but just collect them for analysis
    later.

    I'm trying to assess how much variation there is in the NTP measurements.

    The standard out of the box NTP takes way too long to stabalize to 1 ms
    offset. I suspect that this is due to the time constants used to be able to
    sync to typical NTP servers on the internet. Since my network will be closed
    (and small - all in the same room), with only 2 NTP servers (one for
    backup), I'm expecting very small variations in measurements, and thus only
    a small amount of filtering should be required. This should result in
    faster converging times, and the ability to respond quickly to server clock
    frequency changes (for example, room temperature changes quickly due to AC
    cooling loss).







  2. Re: tool to collect statistics on round trip delay offset?


    >Are there any monitoring tools that allow you to collect statistics on the
    >round trip delay, and offset without using the data.


    ntpd itself is one option. Use the noselect option on a server
    line and it will go through all the work of collecting the data
    and adding it to the log files but then not use that server.
    You can adjust minpoll/maxpoll to get more data or reduce clutter.

    Details are in the web pages.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  3. Re: tool to collect statistics on round trip delay offset?

    joe blow wrote:

    > Are there any monitoring tools that allow you to collect statistics on the
    > round trip delay, and offset without using the data.
    >
    > On a small, self contained network, (using no routers, just cisco switches),
    > I have multiple servers that I want to be in sync to < 1ms (200-300 usec
    > ideally). It is not so important how well these match to GMT, but it is very
    > important that they agree with each other. They are used to time tag event
    > data that needs to be correlated across servers.
    >
    > I want to take some statistics on the measurement jitter (both offset and
    > round trip delay) of a typical NTP packet. I envision a utility that would
    > send the UPD NTP packets, and be able to calculate delay and offset from a
    > specific server (but not use the data), but just collect them for analysis
    > later.
    >
    > I'm trying to assess how much variation there is in the NTP measurements.
    >
    > The standard out of the box NTP takes way too long to stabalize to 1 ms
    > offset. I suspect that this is due to the time constants used to be able to
    > sync to typical NTP servers on the internet. Since my network will be closed
    > (and small - all in the same room), with only 2 NTP servers (one for


    This configuration is just begging for problems. With but one server
    there is no question which to rely on! With two, there is no way for
    ntpd to determine which of the two is more nearly correct. Use either
    one server, four servers or five servers. Four are necessary and
    sufficient to unambiguously vote out one bad server. Five are necessary
    and sufficient to vote out two bad servers.

    If you are going to measure jitter, it seems to me that you need a
    better clock than the server you are trying to measure else how would
    you know what you are measuring!!

    Ntpd is a little slow to pull into tight synchronization. You should,
    however, only have to do this once. Unless, of course, you are
    rebooting your systems every day. . . .

  4. Re: tool to collect statistics on round trip delay offset?


    "joe blow" wrote:

    > Are there any monitoring tools that allow you to collect statistics on the
    > round trip delay, and offset without using the data.
    >
    > On a small, self contained network, (using no routers, just cisco
    > switches), I have multiple servers that I want to be in sync to < 1ms
    > (200-300 usec ideally). It is not so important how well these match to
    > GMT, but it is very important that they agree with each other. They are
    > used to time tag event data that needs to be correlated across servers.
    >
    > I want to take some statistics on the measurement jitter (both offset and
    > round trip delay) of a typical NTP packet. I envision a utility that
    > would send the UPD NTP packets, and be able to calculate delay and offset
    > from a specific server (but not use the data), but just collect them for
    > analysis later.
    >
    > I'm trying to assess how much variation there is in the NTP measurements.
    >
    > The standard out of the box NTP takes way too long to stabalize to 1 ms
    > offset. I suspect that this is due to the time constants used to be able
    > to sync to typical NTP servers on the internet. Since my network will be
    > closed (and small - all in the same room), with only 2 NTP servers (one
    > for backup), I'm expecting very small variations in measurements, and
    > thus only a small amount of filtering should be required. This should
    > result in faster converging times, and the ability to respond quickly to
    > server clock frequency changes (for example, room temperature changes
    > quickly due to AC cooling loss).


    In the scenario with one single timeserver I would prefer the usage of the
    authenticated broadcast. All the clients get time information every 64
    seconds, the broadcasting server can simply be replaced by another one if
    needed. As mentioned earlier in this thread, all your ntpd client servers
    can be configured on your timeserver with noselect option. Then the single
    peerstats file will contain all the information you need. The best mean
    values of broadcastdelay can also be evaluated.
    Your requirement on sync under 0.2-0.3 ms could be difficult to achieve
    because of quick temperature changes. One of my stratum 2 server has the
    offset sigma ~0.17ms (without AC), but its coefficient 0.127 ppm/K is rather
    uncommon.

    Karel Sandler



  5. Re: tool to collect statistics on round trip delay offset?

    "joe blow" wrote in message
    news:e7S%g.66382$uH6.48179@twister.nyroc.rr.com...
    [...]
    > I have multiple servers that I want to be in sync to < 1ms (200-300
    > usec ideally).


    Okay. NTP can do that easily, if you run nothing else on them.


    > It is not so important how well these match to GMT, ...


    ....to you.


    [...]
    > The standard out of the box NTP takes way too long to stabalize ...


    ....to you.


    > [...] Since my network will be closed (and small - all in the same
    > room), with only 2 NTP servers (one for backup), I'm expecting very
    > small variations in measurements, and thus only a small amount of
    > filtering should be required.


    I regret to inform you that NTP was engineered to work for other people,
    too. Feel free to commission your own product or to hack the - freely
    available - source to NTP.

    That does not mean that configurations don't exist that would suit you
    better than what you have now. Perhaps a PPS source distributed to all
    your nodes? That should get them in very tight synchronisation.

    If you want them synchronised the soonest after you come in in the
    morning, I would recommend not turning them off overnight. Not just to
    be lazy, although it is also the simplest solution, but mostly because
    it minimises frequency changes all around. The less the server's
    frequency excursions, the easier for the clients to follow them. The
    less their own excursions, likewise.

    Groetjes,
    Maarten Wiltink



+ Reply to Thread