Tech Off Thread

90 posts

time.windows.com

Back to Forum: Tech Off
  • User profile image
    PeterIn​Sydney

    It looks to me as if there has been a change in the NTP packet returned from some timeservers.

    Looking at a log file from w32time I see the error "Rejecting packet w/ bad precision". The pack concerned has a very high precision
    (-31).

    My solution is to use a closer time server with less precision.

    http://ntp.isc.org/bin/view/Servers/WebHome

    is a good place to start.

    Peter.

    The log file:
    148401 11:27:57.7586250s - ListeningThread -- response heard from
    192.43.244.18:123
    148401 11:27:57.7586250s - /-- NTP Packet:
    148401 11:27:57.7586250s - | LeapIndicator: 0 - no warning;  VersionNumber:
    3;  Mode: 2 - SymmetricPassive;  LiVnMode: 0x1A
    148401 11:27:57.7586250s - | Stratum: 1 - primary reference (syncd by radio
    clock)
    148401 11:27:57.7586250s - | Poll Interval: 10 - 1024s;  Precision: -31 -
    -0.465661ns per tick
    148401 11:27:57.7586250s - | RootDelay: 0x0000.0000s - unspecified; 
    RootDispersion: 0x0000.0000s - unspecified
    148401 11:27:57.7586250s - | ReferenceClockIdentifier: 0x41435453 - source
    name: "ACTS"
    148401 11:27:57.7586250s - | ReferenceTimestamp:   0xC9D8680621210B5F148401
    11:27:57.7586250s -  - 12821887622129410500ns - 148401 11:27:02.1294105s
    148401 11:27:57.7586250s - | OriginateTimestamp:   0xC9D8683D8A353F7C148401
    11:27:57.7586250s -  - 12821887677539875000ns - 148401 11:27:57.5398750s
    148401 11:27:57.7586250s - | ReceiveTimestamp:     0xC9D8683DA69BA24C148401
    11:27:57.7586250s -  - 12821887677650812300ns - 148401 11:27:57.6508123s
    148401 11:27:57.7586250s - | TransmitTimestamp:    0xC9D8683DA69CF3C1148401
    11:27:57.7586250s -  - 12821887677650832400ns - 148401 11:27:57.6508324s
    148401 11:27:57.7586250s - >-- Non-packet info:
    148401 11:27:57.7586250s - | DestinationTimestamp: 148401 11:27:57.7586250s
    - 0xC9D8683DC2353F7C148401 11:27:57.7586250s -  -
    12821887677758625000ns148401 11:27:57.7586250s -  - 148401 11:27:57.7586250s
    148401 11:27:57.7586250s - | RoundtripDelay: 218729900ns (0s)
    148401 11:27:57.7586250s - | LocalClockOffset: 1572300ns - 0:00.001572300s
    148401 11:27:57.7586250s - \--
    148401 11:27:57.7586250s - Rejecting packet w/ bad precision
    148401 11:27:57.7586250s - Ignoring garbage packet.
    148401 11:27:59.1180000s - W32TmServiceMain: timeout
    148401 11:27:59.1180000s - TimeProvCommand([NtpClient], TPC_GetSamples)
    called.
    148401 11:27:59.1180000s - NtpClient returned 0 samples.
    148401 11:27:59.1180000s - W32TmServiceMain: waiting 1024.000s
    148401 11:42:57.5555000s - PeerPollingThread: WaitTimeout

  • User profile image
    Matthew van Eerde

    PeterInSydney wrote:
    Looking at a log file from w32time I see the error "Rejecting packet w/ bad precision". The pack concerned has a very high precision (-31).


    Alas, this is a bug in the w32time client; nothing we can do about it at the server end.  The w32time client incorrectly rejects packets with precision < -30.

    It's fixed in Vista; it was considered for a Server 2003 hotfix but rejected.  If there's sufficient demand I can ask that it be reconsidered.

  • User profile image
    PeterIn​Sydney

    > Alas, this is a bug in the w32time client; nothing we can do
    > about it at the server end.  The w32time client incorrectly
    > rejects packets with precision < -30.

    If you can't do a hotfix, how about some publicity, it would be a good idea to encourage everyone to use NTP servers other than time.microsoft.com and xxx.nist.gov.

    Peter.

  • User profile image
    Matthew van Eerde

    I note the IP address you're using is time.nist.gov.  I hope time.windows.com doesn't trigger this bug... does it?

  • User profile image
    PeterIn​Sydney

    time.windows.com (207.46.130.100) is fine, it shows up here in Australia as precision -6.

    Peter.

  • User profile image
    Matthew van Eerde

    I think I have a pretty good understanding of this now, and I can see that a hotfix is a lot more useful now than it was at the time the bug was fixed.  I'll see what the hotfix team thinks.

    As I understand it:

    Defaults: most people

    xp-workstation.example <-LAN-> domain-controller.example <-Internet-> time.windows.com <-Internet-> time.nist.gov
    personal-xp.example <-Internet-> time.windows.com <-Internet-> time.nist.gov

    Common variations: a reasonable number of people

    xp-workstation.example <-LAN-> domain-controller.example <-Internet-> time.nist.gov
    personal-xp.example <-> time.nist.gov

    Uncommon variations: a small number of people

    xp-workstation.example <-LAN-> domain-controller.example <-Internet-> time.somewhereelse.example
    personal-xp.example <-Internet-> time.somewhereelse.example

    XP and Windows Server 2003 shipped with a bug where this broke:

    XP/W2k03 <-> Very-high-precision server

    This broke some of the "uncommon variations."

    The bug was fixed in Vista... but because of the low impact, the hotfix request for XP/W2k03 was rejected.

    Over time, more and more time servers have become "very high precision."  More and more "uncommon variations" broke.

    Recently (March time frame) time.nist.gov became "very high precision."

    THIS BROKE "COMMON VARIATIONS" AS WELL AS "DEFAULTS."

    We were able to TEMPORARILY fix "Defaults" by switching time.windows.com to pull from a lower-precision server (time-nw.nist.gov) but this is not an appealing fix.

    "COMMON VARIATIONS" IS STILL BROKEN.

    That is, it is still not possible to sync to time.nist.gov (and others) from an XP or a Windows Server 2003  machine.

  • User profile image
    Andy H

    Hadnt checked in on this for a while

    Just tried synching with time.windows.com and alas it works :O how long for i dont know Tongue Out but it responded in less than a second and the time is correct. So hopefully its fixed. Funny though how it hadn't been working for about 3 months Perplexed

    Thanks for looking into this Smiley

  • User profile image
    Andy H

    spoke too soon. Something odd is still happening.

    <<edit>>

    ok so i was able to synch with time.windows.com but now on subsequent attempts i get :

    An error occurred while windows was synchronizing with time.windows.com. This operation returned because the timeout period expired

    the event log shows :

    The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.  No attempt to contact a source will be made for 2001 minutes. NtpClient has no source of accurate time.

  • User profile image
    figuerres

    this fixes it:

    http://www.kaska.demon.co.uk/

    Tardis 2000 -- been around for a long time and it just works.

  • User profile image
    figuerres

    figuerres wrote:
    this fixes it:

    http://www.kaska.demon.co.uk/

    Tardis 2000 -- been around for a long time and it just works.



    By the way:  why does windows not show / use a list of servers?

    seems that it should show and allow the user to edit say 12 time servers to search so that if one or two are not reachable it can try several others.

  • User profile image
    Sven Groot

    There's this KB article: http://support.microsoft.com/kb/262680

  • User profile image
    Andy H

    trouble is though sven , whilst i appreciate that kb article, many systems out there are set to time.windows.com by default. The "average user" may not even realise that there pc hasnt synched since feb/march when the new daylight saving changes came in (i dont know if this is what caused time.windows.com to stop functioning or if its related, but thats when it started happening for me)

    There needs to be an update for xp/server 2003 if time.windows.com is likely to be unusable for the forseable future. Perhaps an update to add more time servers and switch the default from time.windows.com

    Its one of those things you wouldnt notice, but there are certain system and applications which depend upon a system having synched correctly with a time server. Im really suprised that this went on for so long un-noticed.

  • User profile image
    kaoeki

    I have programs that I have set up to automatically log in when I take my comp out of hibernation/stand-by/sleep... and I am continuing to get the same message that it can not connect because my time is different from there time.  I tried to ping time.windows.net and the whole site is down.  I then found this thread through Google and was happy that I am not insane.   I was freaking out that this was happening.  I did notice I am not getting the same message most of you all are getting.  On Windows Time in the Internet tab, it says: An error occured getting the status of the last synchronization.  The RPC server is unavailable." 
    I am getting this message after I have tried to connect to another Time Server besides time.windows.net.  In fact, it is with EACH server I am getting this message.  I live in the U.S. and wasn't sure if this type of problem is esculated by geographical locations.  Is this something I can call Windows for?  I find it odd that Vista can sychronize without a problem, but any OS before that can not.  Is this Microsofts way to force  people to break down and buy VISTA although they don't want to?  I am a conspiracy theorist, pardon my teetering off subject. Smiley

  • User profile image
    Cannot​Resolve​Symbol

    kaoeki wrote:
    I have programs that I have set up to automatically log in when I take my comp out of hibernation/stand-by/sleep... and I am continuing to get the same message that it can not connect because my time is different from there time.  I tried to ping time.windows.net and the whole site is down.  I then found this thread through Google and was happy that I am not insane.   I was freaking out that this was happening.  I did notice I am not getting the same message most of you all are getting.  On Windows Time in the Internet tab, it says: An error occured getting the status of the last synchronization.  The RPC server is unavailable." 
    I am getting this message after I have tried to connect to another Time Server besides time.windows.net.  In fact, it is with EACH server I am getting this message.  I live in the U.S. and wasn't sure if this type of problem is esculated by geographical locations.  Is this something I can call Windows for?  I find it odd that Vista can sychronize without a problem, but any OS before that can not.  Is this Microsofts way to force  people to break down and buy VISTA although they don't want to?  I am a conspiracy theorist, pardon my teetering off subject.


    I'm having no trouble connecting to time.windows.com or any of the other time servers now.  It sounds like you're having connection issues if you can't access any of the time servers--  are you sure your firewall isn't blocking NTP (UDP port 123)?

    I am not using Windows Vista, so stop with the conspiracy nonsense, at least.

  • User profile image
    kaoeki

    I feel foolish, but how do I find out if the firewall is blocking the NTP. Where do I go to see this.  I have not touched my firewall and have let Windows operate it for a while now with no problems.  I use PC-Cillin for virus protection.  This just happened this morning because I was able to log onto my accounts last night with no problems.  Today, my clocks do not match up. 

    My CMOS clock says 11:49am right now.

  • User profile image
    AndyC

    kaoeki wrote:
    
    My CMOS clock says 11:49am right now.


    Doesn't mean much unless we know what it should be. However you should note that NTP won't work at all unless your clock is reasonably accurate. If it is a long way off, you should probably set it manually before attempting to sync.

  • User profile image
    PeterIn​Sydney

    Another problem I'm seeing in Windows XP with the W32time service is a time instability in XP members of a Domain. 

    The problem seems to occur when the dispersion of an earlier NTP message is better then the current message resulting in an error message
    "ClockDispln:ClockDispln Update: *STALE*"
    and the clock wandering several seconds away from the correct time.

    In one case I have logged the time varied by up to 20 seconds from the NTP server.

    I plan (when I have some spare time) to think through the Register settings for the XP machine to make sure that it cannot move too far from the NTP server, which I hope will help.

    I manage sever machine which need to be with in one second of the correct time. So this is important to me.

    Peter.

    Here is part of the log, let me know if you would like more:

    148397 17:55:11.2320513s - ListeningThread -- response heard from 10.2.0.36:123
    148397 17:55:11.2320513s - /-- NTP Packet:
    148397 17:55:11.2320513s - | LeapIndicator: 0 - no warning;  VersionNumber: 3;  Mode: 4 - Server;  LiVnMode: 0x1C
    148397 17:55:11.2320513s - | Stratum: 6 - secondary reference (syncd by (S)NTP)
    148397 17:55:11.2320513s - | Poll Interval: 12 - 4096s;  Precision: -6 - 15.625ms per tick
    148397 17:55:11.2320513s - | RootDelay: 0x0000.0F37s - 0.059433s;  RootDispersion: 0x0000.537As - 0.32608s
    148397 17:55:11.2320513s - | ReferenceClockIdentifier: 0x0A0A0001 - source IP: 10.10.0.1
    148397 17:55:11.2320513s - | ReferenceTimestamp:   0xC9D37CCD57F95C77148397 17:55:11.2320513s -  - 12821565261343648700ns - 148397 17:54:21.3436487s
    148397 17:55:11.2320513s - | OriginateTimestamp:   0xC9D37CFF3B67B6C8148397 17:55:11.2320513s -  - 12821565311232051300ns - 148397 17:55:11.2320513s
    148397 17:55:11.2320513s - | ReceiveTimestamp:     0xC9D37D0264018D9E148397 17:55:11.2320513s -  - 12821565314390648700ns - 148397 17:55:14.3906487s
    148397 17:55:11.2320513s - | TransmitTimestamp:    0xC9D37D0264018D9E148397 17:55:11.2320513s -  - 12821565314390648700ns - 148397 17:55:14.3906487s
    148397 17:55:11.2320513s - >-- Non-packet info:
    148397 17:55:11.2320513s - | DestinationTimestamp: 148397 17:55:11.2320513s - 0xC9D37CFF3B67B6C8148397 17:55:11.2320513s -  - 12821565311232051300ns148397 17:55:11.2320513s -  - 148397 17:55:11.2320513s
    148397 17:55:11.2320513s - | RoundtripDelay: 000ns (0s)
    148397 17:55:11.2320513s - | LocalClockOffset: 3158597400ns - 0:03.158597400s
    148397 17:55:11.2320513s - \--
    148397 17:55:11.2320513s - Peer poll: Max:4096.0000000s Cur:4096.0000000s
    148397 17:55:11.2320513s - Response from peer EGON.research.canon.com.au (ntp.d|10.2.5.206:123->10.2.0.36:123), ofs: +03.1585974s
    148397 17:55:11.2320513s - 5 Age:3 Ofs:-10.3860595s Dly:+00.0826310s Dsp:00.6192537s Dst:00.6605692s FDsp:08.0000000s
    148397 17:55:11.2320513s - 4 Age:4 Ofs:-05.2235615s Dly:+00.0763550s Dsp:00.5937232s Dst:00.6319007s FDsp:11.7829201s
    148397 17:55:11.2320513s - 3 Age:5 Ofs:+10.2885856s Dly:+00.0616302s Dsp:00.5710607s Dst:00.6018758s FDsp:05.9183066s
    148397 17:55:11.2320513s - 2 Age:2 Ofs:-15.5680073s Dly:+00.0598145s Dsp:00.3610925s Dst:00.3909997s FDsp:10.9591533s
    148397 17:55:11.2320513s - 1 Age:0 Ofs:+03.1585974s Dly:+00.0594330s Dsp:00.3416934s Dst:00.3714099s FDsp:09.0714173s
    148397 17:55:11.2320513s - 0 Age:1 Ofs:+10.3422788s Dly:+00.0585785s Dsp:00.3194398s Dst:00.3487290s FDsp:04.5357086s
    148397 17:55:11.2320513s - W32TmServiceMain: resync req, irreg now pending.
    148397 17:55:11.2320513s - W32TmServiceMain: waiting i0.000s (4088.794s)
    148397 17:55:11.2320513s - W32TmServiceMain: timeout
    148397 17:55:11.2320513s - TimeProvCommand([NtpClient], TPC_GetSamples) called.
    148397 17:55:11.2320513s - NtpClient returned 1 samples.
    148397 17:55:11.2320513s - Sample 0 offset:+10.3422788s delay:+00.0585785s dispersion:04.8551484s
    148397 17:55:11.2320513s - Intersection successful with 0 dropped samples.
    148397 17:55:11.2320513s -   0: Sample:0 SyncDist:1008844376 SelectDisp:0
    148397 17:55:11.2320513s - Sample 0 chosen. Select Dispersion:00.0000000s
    148397 17:55:11.2320513s - ClockDispln:ClockDispln Update: *STALE*
    148397 17:55:11.2320513s -   PhCRA:0 phcT:12543 KPhO:11859

  • User profile image
    Matthew van Eerde

    The "precision is too good" bug is being reconsidered by WinSE for XP/Server03 backporting.  Will advise.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.