May 2013 Windows Update causing rapid 'ntpd' drift

[starligh...@binnacle.cx]

Hello,

Just installed this month's Windows Update
patches on an old/slow Windows XP laptop
(1.5GHz Pentium-M) and it appears to have
damaged Windows 'ntpd' time-keeping.

Has anyone else observed this?

Before the patch 'ntpd' frequency was -15.761
PPM. After the patches 'ntpd' frequency
went to -500 PPM and the system was still
gaining time so fast that 'ntpd' reset the
time between -1.5 and -5 seconds every fifteen
minutes. This went on for 12 hours after the
system was rebooted. No change in the running
applications and very light load most of the
time.

Restarted 'ntpd' with the same -g parameter
and the problem persisted.

Restarted 'ntpd' with the -M option added and it
looks like it's doing ok now at around -55 PPM,
but -M has its down-sides so I prefer to avoid
using it if possible.

Running a somewhat older version 4.2.4p4
against two local CDMA time servers. Generally
get offsets under 100 microseconds.
The version running here is patched to allow
a one-second polling interval, which I've
found necessary to obtain decent time-keeping
with Windows.

My best guess is that the problem results from
kernel-mode 'Win32k.sys' driver patch
KB2829361 aka MS13-046

http://support.microsoft.com/default.aspx?kbid=2829361

Installed three other patches at the same time
but two are for IE and one is for Active-X
and don't seem likely culprits. In case
someone suspects otherwise, they are
KB2847204, KB2829530, KB2820197. The other
May patches were installed three days ago
since rebooting was not required for them.

Any thoughts or comments are appreciated.

Thanks

[Jeroen Mostert]

On 2013-05-18 15:50, starligh...@binnacle.cx wrote:
> Just installed this month's Windows Update patches on an old/slow Windows XP
> laptop (1.5GHz Pentium-M) and it appears to have damaged Windows 'ntpd'
> time-keeping.
>
> Has anyone else observed this?
>

FWIW, I'm running 4.2.7p362 on 91 Windows servers. This issue does not occur on
any of them. I have no Windows XP or Windows Server 2003 32-bit machines,
however. I checked two fully patched Windows Server 2003 64-bit machines (which
is almost but not quite the same as Windows XP). The offset stays under 250
microseconds, and the server is not local LAN but on a VPN. Polling interval
maximum of clients is capped at 16 seconds; the server syncs with the NTP pool
using regular settings.

> Restarted 'ntpd' with the -M option added and it looks like it's doing ok now
> at around -55 PPM, but -M has its down-sides so I prefer to avoid using it if
> possible.
>

Unfortunately (for you) both my servers are using -M so my comparison might be
entirely useless if it wasn't already. I can see why you wouldn't want to use it
on a laptop, of course. Also, obviously, the servers are not using
variable-frequency CPU settings.

> Running a somewhat older version 4.2.4p4 against two local CDMA time servers.
> Generally get offsets under 100 microseconds. The version running here is
> patched to allow a one-second polling interval, which I've found necessary to
> obtain decent time-keeping with Windows.
>

You should definitely try a more recent ntpd version, since there's been
considerable improvements in timekeeping on Windows (though most improvements
focused on Vista and beyond). In particular, very frequent polling doesn't seem
to be required in any case.

It's a bit of a crapshoot, but you can also try using the /USEPMTIMER option in
boot.ini if you're using the ACPI HAL. Timer frequency is quite a mess on
Windows, but /USEPMTIMER typically does *something*. Whether it has any effect
on ntpd is another matter. BIOS and driver updates can also make a difference.

--
J.

[David Taylor]

I have not seen the problem here, although my own 1.6 GHz Pentium-M PC
is now running Windows-7, even though it has only 1.25 GB RAM.

On my XP systems, I do run with -M and have found no drawbacks. The
LAN-synched PCs run with a poll interval of either 32 or 64 seconds, and
the performance can be seen here:

http://www.satsignal.eu/mrtg/performance_ntp.php

Windows-8 should offer the chance of better time-keeping performance due
to the introduction of a more precise GetSystemTime call which NTP uses
(in the development branch). 4.2.4 is rather old, and it may be worth
at least trying a more recent version. I have some pre-compiled ones here:

http://www.satsignal.eu/ntp/x86/

--
Cheers,
David
Web: http://www.satsignal.eu