Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is so weird I feel compelled to ask for advice.

I have a handful of workstations who are receiving time from a GPS timeclock. The PDC has the default domain policy set to use the GPS timeclock as the NTP timesource. All the workstations sync to the timeclock with precision ranging from 50ms to 1.5ms so my delta values are grossly within margins for Kerebos tickets.

Almost all the workstations access my fileserver with absolutely no problems, however a single workstation began prompting me with the message This server's clock is not synchronized with the primary domain controller's clock and unless w32tm /stripchart /computer:PDC is lying, 20ms is more than close enough to be synchronized.

Is there something I might be missing here?

share|improve this question
    
The problem seems to be the PTP time source that was providing time stamping for the database had been turned back to 7/23/10. Evidently one of our engineers was preforming regression testing on another part of the network and had reset the PTP master time to hand out the same time range as the previous tests. I disabled the PTP radio card from updating the Windows time and set it by hand to be close to the workstations that use NTP. I'll mark answers accordingly if I continue to have no other problems with my time sources. –  Greg Buehler Oct 13 '10 at 13:43
    
Feel free to post your fix as an answer & accept. And thanks for coming back with that - might help someone someday. –  Kara Marfia Oct 13 '10 at 15:29

2 Answers 2

up vote 2 down vote accepted

Now that I'm convinced the problem is fixed, I'll answer my own question.

Things to Verify:

  • Verify the modulation from the timesource If the IRIG signal is modulated, make sure your configuration is looking for a modulated time signal. If the IRIG signal is unmodulated, make sure you have the hardware configured for unmodulated signal.

  • Verify the correct time If the 'Grandmaster Clock' is not receiving the correct time value from the timeclock, nothing is going to be correct. Make sure that you have the correct offset period for the correct year. Leap seconds (as of this writing) should be offset by 34 seconds.

  • Verify there are no forced values, or debugging If someone is debugging a process using a frequency generator to 'fake' the time, nothing is going to be right if it overrides the Stratum time.

  • Verify Time Services If your clock radio has seperate software to synchronize the system time to the timesource, make sure that Windows Time Service is disabled. If you don't turn off Windows Time Service the clock will be corrected by both services.

  • Verify Time Zones Timezones must be set correctly on both the time server and clients. I highly recommend setting everything to GMT without any daylight bias or UTC and creating a second time display showing the local timezone with daylight preferance.

  • Verify DST is Patched If you don't have a correct implementation of DST running, you will encounter 'phantom' problems.

  • Verify delta is small enough for initial synchronization If the delta time is large, the clients cannot synchronize to the time source. You may be required to set the clock to within approximatly 10 minutes for the time service to be able to synchronize.

For troubleshooting:

  • use w32tm /tz to verify the timezones.
  • use w32tm /stripchart /compter:[host to compare with] to measure differeances and time drift
share|improve this answer

My guess is a DST patching issue on that workstation. Last time I ran into it, I'd loaded a workstation from image, then applied XP SP3. That's when I discovered that my image fell into a fringe case where the DST patching didn't take place when patched in that way. If that's the issue, hopefully the MS DST page will help out.

share|improve this answer
1  
Ah yes, this. Try w32tm /tz on a working and non-working machine, and see if one is under DST while the other one is not. –  Chris Thorpe Oct 12 '10 at 21:50
    
Thanks, that's the command I was trying to locate. Brain's not working tonight. –  Kara Marfia Oct 12 '10 at 22:05
    
w32tm /tz showed that they were both set for GMT and ignoring daylight time bias. –  Greg Buehler Oct 13 '10 at 13:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.