ntpd on Windows attempts to raise itself to the realtime priority class, but on many installations, it will silently fail and run in the high priority class instead. This is because Windows requires a special privilege to raise priority to realtime, as a runaway realtime program can interfere with the operation of the system as a whole. By default, the Administrators group has this privilege while normal users do not. If you install ntp using the Meinberg installer (which I recommend) and follow the suggested practice of letting it create a restricted "ntp" user, unfortunately this user isn't granted the privilege needed for realtime. I've mentioned previously you can work around this by adding the ntp user to the Administrators group, but that completely defeats the purpose of running ntpd.exe under a restricted user account. Below I detail how to accomplish this until Meinberg's installer adds the needed privilege for us. If you've previously added ntp to the administrators group, remove it:
C:\>net localgroup administrators ntp /de Next, open Local Security Policy. There are different approaches, but Start/Run secpol.msc is easiest for me to type :) Drill down to Local Policies then User Rights Assignment. Scroll down the right side to see "Increase Scheduling Priority". Double-click on it to edit and in the resulting dialog box you'll likely see only Administrators listed. Click the "Add user or group" button and type "ntp" and hit enter. If you used a different user name when installing ntp, type that instead of "ntp". Click OK twice, close the Local Security Policy window, and restart ntpd to verify it worked. Look in Task Manager on the Processes tab for ntpd.exe. If you don't see it, make sure "Show processes for all users" is enabled. Show the priority by choosing View / Select columns... from the menu, and in that box turn on the check mark next to "Base priority". Click OK and you should see ntpd.exe at Realtime base priority. If it's High, the privilege wasn't available. If you're running one of my test releases, a message is written to the event log or configured log file at startup indicating whether High or Realtime priority is being used. Speaking of my test versions of ntpd, I've released a new one today with substantially refined (and quieted!) performance counter frequency compensation. http://davehart.net/ntp/refclock/ Sources, release and debug binaries and symbols, but most people would want just: http://davehart.net/ntp/refclock/ntp-4.2.4p6-DLH-QPC-20090306-bin.zip http://tinyurl.com/c9otm2 Now instead of jolting a new counter frequency value into the time interpolation calc all at once after 30 minutes, the change is smoothly introduced over 10 sample periods, by using a running average that begins with the 10 history entries at the nominal performance counter frequency. In order to adapt more quickly on most machines while still performing reasonably on machines with relatively slow counters (like 3.5 MHz), the sample period for measuring the counter frequency depends on the nominal frequency, 512 seconds for <75MHz (counter, not CPU freq), 256 seconds for 75MHz to 1GHz, 128 seconds for the rest. A message is logged after each of the first 10 sample periods showing the average now being used. After that initial burst, the code quiets down and logs an average perf ctr frequency every 4 hours. Caveats: Windows 2000 and later, sadly programs built with Visual C++ 9 won't load on Windows NT. Systems with 100 Hz clock interrupt frequency (10 msec OS clock precision) do not yet perform as well as the more common 64 Hz cases. It's probably better than the old interpolation 1 msec jitter, but more work is needed to find a better value for the interpolation interval (currently tweaked using the NTPD_INT_INT environment variable). Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
