w32time root delay / root dispersion error

Discussion in 'Windows Server' started by Toni Martikainen, Nov 22, 2005.

  1. Hi All!

    Sorry about the length of this post. There's just so many things involved
    here....

    We have a little problem concerning w32time. We are building a treelike
    network of computers, where every computer should have same time. Time
    synchronization should be done by using NTP protocol. There are simple rules
    how the time synchronization should be done:

    * there are one or more external time sources outside the network (Windowses
    or Unixes or something else, we don't know).
    * level A servers synchronize their time from external time sources.
    * level B servers synchronize their time from level A servers.
    * a level C server synchronize it's time from a level B server.

    All level A, B and C computers are running Windows 2003 Server + SP1.

    I'll try to illustrate the stucture of the network :

    O <-- external time source
    -------/--\--------------------
    | O O <-- level A |
    |----/--\-/-------------------|
    | O O <-- level B |
    |--/----/-\-------------------|
    | O O O <-- level C |
    |-----------------------------|
    (all level B servers should be linked with all level A servers, but I wasn't
    able to draw that. :)

    The problem:

    When we change external time sources, and thus reconfigure level A w32time
    services, the time synchronization fails in level C. The following error
    message is found in Date and Time Properties's "Internet Time" tab: "An error
    occured while Windows was synchronizing with <time server address>. The time
    sample was rejected because: Packet contains unreasonable root delay or root
    dispersion values. This may be caused by poor network conditions."

    The problem in level C server seems to resolve after restarting w32time in
    level B server. But if level B server's clock is synchronized manually (w32tm
    /resync), then same problem reappears in level C server.

    Our server software configures w32time service using following command line
    commands.
    In level A servers:
    w32tm /config /manualpeerlist:"extTimeSource1,0x8" /syncfromflags:MANUAL
    w32tm /config /update
    w32tm /resync

    In level B servers:
    w32tm /config /manualpeerlist:"levelASource1,0x8 levelBSource2,0x8"
    /syncfromflags:MANUAL
    w32tm /config /update
    w32tm /resync

    In level C servers:
    w32tm /config /manualpeerlist:"levelBSource,0x8" /syncfromflags:MANUAL
    w32tm /config /update
    w32tm /resync


    Does anybody know what could cause that root delay/root dispersion problem?
    The problem is not those poor network conditions, that is for sure. Is there
    something I don't understand in NTP protocol itself, or what? (there's a lot,
    I'm sure :) If somebody has faced this kind of problem, is there any
    working workaround available? A solution I thought, is that we restart level
    A and level B w32time server every time we get an event that external time
    source is changed.. But would this solve the problem.

    Then I was wondering if SP1 could do any damage here? When we tested this
    environment a few months ago, without service packs, everything seemed to
    work just perfectly. Now, when service packs were installed, this problem
    (re)appeared. (We faced this problem earlier, but then it wasn't that big
    issue, so we ignored it very soon. If I remember right, the problem appeared
    in a level C server, which included SP1. Other servers didn't have service
    packs installed.)

    Any kind of help is appreciated!

    thanks,
    Toni Martikainen
     
    Toni Martikainen, Nov 22, 2005
    #1
    1. Advertisements

  2. Toni Martikainen

    Paul D.Smith Guest

    Silly question, but why change external time sources? Choose one and stick
    with it!

    I don't know NTP well, but I imagine that there is a "time taken to get time
    from external server X = delta(X)" type value which is applied to the time
    calculation. If you change to server Y then this delta interval changes
    significantly which could be fooling the time syncs. into believing there is
    an error.

    There is, of course, the question of what happens if this occurs in real
    life. Once the (network) error clears, will the time syncs. settle down?
    That's a question that I would like to see answered.

    Paul DS.
     
    Paul D.Smith, Nov 22, 2005
    #2
    1. Advertisements

  3. That no silly question at all. Time synchronization is a feature in a
    software. That software can be installed into different environments, and
    there are different time sources in different environments. I don't think the
    time sources are changed once they are set after installation is done. I
    hope, at least.
    That's true, I think.
    This is the problem here. The time sync. doesn't settle down at all. The
    error seems to persist, even after a few days. It is understandable if a
    short error period occurs, but if error exists days after it appeared, it is
    a bit mysterious. We once waited for 3 days (or even longer?) to see if
    something would happen. But no, error still existed.
     
    Toni Martikainen, Nov 23, 2005
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.