Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Mike S wrote: At 08:26 PM 2/1/2011, Brolin Empey wrote... As I have already stated in a previous message in this thread, I am not using ntpd. I do not need ntpd: Then let me be the first to tell you that you're on the wrong mailing list. This one deals with NTP, if it's not obvious from the name. I don't fully agree: the newsgroup is called comp.*protocols*.time.ntp, and in fact the reference implementation is only *one* implementation of this protocol, though it's probably the version which is most often used beside w32time, which also uses the NTP *protocol*. So even though this thread may not be fully on topic since it discusses how the system time and RTC are handled by Windows, this is also relevant if you run ntpd on this machine since the RTC would not also be set when ntpd would step the system time, or sets the system time when it (ntpd) shuts down. I don't know a better place to discuss something like this. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Martin Burnicki wrote: Brolin, sorry for the late reply. I've been offline due to a really bad cold. I have kept deferring replying to your message, at least partly because of the nature of the medium. However, I am glad to report my hardware clock has been sufficiently accurate since I ran “ntpdate-debian” followed by “hwclock -w --utc” on Ubuntu probably at least 2 weeks ago. I know I should keep (better) records, but at least I am satisfied even without the ability to write the Windows NT system time to the hardware clock. After synchronising brolin-N900 with time.windows.com , brolin-V13 is 8 seconds behind brolin-N900 . I know this may be significant for certain applications, but it is good enough for me. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
On 2011-02-01, Brolin Empey bro...@brolin.be wrote: After synchronising brolin-N900 with time.windows.com , brolin-V13 is 8 seconds behind brolin-N900 . I know this may be significant for certain applications, but it is good enough for me. FWIW ... NTP can typically keep your clock synced within +/- 0.01 sec across a WAN (e.g. The Internet) and better than +/- 0.005 sec across a LAN. And your 8 second offset is well outside ntpd's 0.128 sec default step threshold. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Steve Kostecke wrote: On 2011-02-01, Brolin Empeybro...@brolin.be wrote: After synchronising brolin-N900 with time.windows.com , brolin-V13 is 8 seconds behind brolin-N900 . I know this may be significant for certain applications, but it is good enough for me. FWIW ... NTP can typically keep your clock synced within +/- 0.01 sec across a WAN (e.g. The Internet) and better than +/- 0.005 sec across a LAN. Apparently you have not redd the previous messages in this thread. Synchronising brolin-V13’s Windows NT system clock with NTP is only useful until I shut down Windows NT because the synchronised system clock’s time is /not/ written to the hardware clock when RealTimeIsUniversal=1 . And your 8 second offset is well outside ntpd's 0.128 sec default step threshold. As I have already stated in a previous message in this thread, I am not using ntpd. I do not need ntpd: I need Microsoft to change Windows 7 so it can write the system time to the hardware clock during the shut down process when RealTimeIsUniversal=1 . Until that happens, I accept an 8 second offset as good enough. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
After synchronising brolin-N900 with time.windows.com , brolin-V13 is 8 seconds behind brolin-N900 . I can understand that some people don't need to time sync their servers. Not everyone runs data centers. But 8 seconds tells me something is just plain broken. No reasonable working system can be that poor. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
At 08:26 PM 2/1/2011, Brolin Empey wrote... As I have already stated in a previous message in this thread, I am not using ntpd. I do not need ntpd: Then let me be the first to tell you that you're on the wrong mailing list. This one deals with NTP, if it's not obvious from the name. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
On 2011-02-02, Brolin Empey bro...@brolin.be wrote: Steve Kostecke wrote: On 2011-02-01, Brolin Empeybro...@brolin.be wrote: After synchronising brolin-N900 with time.windows.com , brolin-V13 is 8 seconds behind brolin-N900 . I know this may be significant for certain applications, but it is good enough for me. FWIW ... NTP can typically keep your clock synced within +/- 0.01 sec across a WAN (e.g. The Internet) and better than +/- 0.005 sec across a LAN. Apparently you have not redd the previous messages in this thread. Synchronising brolin-V13?s Windows NT system clock with NTP is only useful until I shut down Windows NT because the synchronised system clock?s time is /not/ written to the hardware clock when RealTimeIsUniversal=1 . The RTC is only used to initially set the system clock. NTP can do this as well if you can accept a big time step at system boot. And your 8 second offset is well outside ntpd's 0.128 sec default step threshold. As I have already stated in a previous message in this thread, I am not using ntpd. I do not need ntpd: I need Microsoft to change Windows 7 so it can write the system time to the hardware clock during the shut down process when RealTimeIsUniversal=1 . This request belongs on a Microsoft support forum. There's nothing we can do about it here. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Steve Kostecke wrote: This request belongs on a Microsoft support forum. There's nothing we can do about it here. I suspect one actually needs a Microsoft paid support channel to get anywhere near a decision maker. Even then, given the size of Microsoft, and the relatively low importance to them of this requirement, I wouldn't hold out much hope. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
David, David J Taylor wrote: Some extra reference points for you - I just checked on a couple of Windows-7 64-bit systems: Intel D330 Atom PC (Molde): QPC: 1.563 MHz, 51ns (my own software shows 26ns for a GetTickCount call, and 51ns for QPC) Intel i5-760 PC (Alta) QPC: 2.744 MHz, 33ns QPC: 2.744 MHz, 15ns (second run) (my own software shows 6ns for a GetTickCount call, and 12ns for QPC) Thanks for the additional information. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
David, David J Taylor wrote: In fact I've heard of *nobody* except you, me, Danny, and Terje building ntpd on Windows ;-) [] Regards, Martin Martin, I did attempt to do this with considerable help from the folk here, and I think I even got as far as set of executables once, but as I'm not a C/C++ person, the effort involved was considerable, and I still had many warning messages (and I want to see no error or warning messages when I compile my own software). Unfortunately there *are* quite some warning messages. However, looks like the number of warnings has been significantly reduced in the current gode, which I appreciate very much. That was with VS2005, and I don't think that even runs under the Windows-7 I'll have on my next PC. Could try the XP for WIndows-7, I suppose. For Windows you do not need to compile with the latest version of the compiler under the same version of the OS as you are going to run the binary on. The 4.2.4p8 version we are still offering for download has been built with VC6 and basically runs on all Windows versions from NT up to Win 7 and Server 2k8. The only problem with the old VC6 build environments is that the header files are missing e.g. definitions of data structures required to have IPv6 support. This is only available with newer compiler versions. On the other hand, without quite some effort in the source code binaries built with newer compilers may not run on older Windows versions like NT and 2k anymore. That's why I've suggested to provide several installers in the future, a legacy 32 bit version built with VC6, a fullfeatured 32 bit version and a native x64 version built with a newer compiler. There is a free Borland C/C++ compiler for Windows, but I don't know what effort might be required to port to that version, or whether it will run under Windows-7. http://edn.embarcadero.com/article/20633 Quite some time ago I've made some efforts to build the NTP package under Borland C/C++ 5. However, the required changes and the project file have never made it into the NTP code base. So it would require quite some effort to build the package under a build environment which is not currently supported. On the other hand, MS Visual Studio 2008 Express has been available as a fre download (don't know if it's still, yet, or if ther is a newer version available for free), so anyone who has installed this compiler could build NTP under Windows. I realise that my efforts don't qualify as building ntp under Windows, but I did try! Usually it should be sufficient to unback the source code, open the appropriate project file for the compiler you have, and rebuild all targets. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
David Woolley wrote: Martin Burnicki wrote: also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. Did you mean that? NTP has been buildable for 32 bit Intel machines running Windows, since NT 3.5, and Meinberg provide an installer for 32 bit Windows. Aargh. This was a misunderstanding on my side. I recently worked with a customer who was running Linux IA64 and when I read IA32 then I thought of some some 32 bit variant of Itanium. Of course this is is nonsense, and of course I know NTP builds for 32 bit Windows on standard Intel architecture. Sorry for the confusion. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Dave Hart wrote: On Mon, Jan 3, 2011 at 16:34 PM, Martin Burnicki martin.burni...@meinberg.de wrote: I have configured the w32time service to start automatically, but it does not seem to start automatically, so my system time is approximately 2 minutes behind until I run net start w32time w32tm /resync in an elevated (with administrative privileges) cmd.exe session. So this is already a different problem which should be fixed. Ntpdate should also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. http://davehart.net/ntp/win/x86/ has a lot of evidence that should assure you. Dave, sorry for the confusion. Please see m reply to David Woolley for details. By the way, now would be a good time to verify the current ntp-dev sources build on VC6 and the result works, as another -dev - -stable transition is about due. It's been just over a year since 4.2.6 came out, and a lot of good stuff has been introduced in 4.2.7. Just did so. There are a few errors which should be easy to fix. I'll send you the build logs for -stable and -dev per private mail. I am aware of no one else building NTP on Windows using a compiler older than Visual Studio 2008 recently, despite highly duplicative and maintenance-heavy vc6, vs2003 and vs2005 project files. In fact I've heard of *nobody* except you, me, Danny, and Terje building ntpd on Windows ;-) I wish there were others with access to VC6 reporting problems sooner, but I expect once again it will be left to you and I to ping-pong through any vc6 build issues that have crept up. I agree I should have tried this earlier, but I've been very busy the last months. We at Meinberg are mostly still using VC6 because it provides a high level of backward compatibility. For example, we build the driver software for our PCI cards with VC6 and an old version of the DDK, and the resulting binaries can be used on all Windows versions from WinNT up to Win7 and Win server 2008. Also the latest ntpd v4.2.4p8 version can still be used on WinNT and Win2k, and on all newer Windows versions. Of course I see the problem with IPv6 which may not be supported properly with the old VC6 build environment. So maybe we can provide several versions of the binary packages for Windows in the future: - a full featured version built with a recent compiler, supporting IPv6, which may not be usable on WinNT and Win2k - a legacy version built with VC6, without support for IPv6, but also usable on WinNT and Win2k - and maybe a native 64 bit version built with a recent compiler Hm, BTW, I don't know how I could load such a kernel driver under Windows? Under NT you could install non-PNP drivers like a service, and then load them with net start my_kernel_driver. In current systems drivers are loaded by the kernel automatically, e.g. if a PCI card is detected which is handled by that driver. Don't know if you can still load a kernel driver manually. I believe so, to the extent you can load the driver at all: Most new Windows installations are x64, and Microsoft makes it enough of a pain to use unsigned drivers on 64-bit versions of Windows that I suspect it's impractical for unattended use. I believe unsigned drivers are still allowed in x86 installs of Vista and Win7, likely with a few layers of Danger! popups. This is a bit of a looming brick wall for my serialpps.sys hack, unless some kind soul manages the unlikely feat of getting it through WHQL driver certification and signed by Microsoft.. For our own drivers we also don't do WHQL certification, but we have the possibility to build signed drivers, so they can be loaded on x64 systems without problems. If you want we can also sign your driver with our key to simplify installation on x64 versions. If you'd like to do so just le me know. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
David J Taylor wrote: It would certainly be good to have kernel-mode timestamps in Win-64. Although the average jitter reduction achieved by switching from user-mode to kernel-mode is not great (say from 3.5 microseconds to 2.2 microseconds), the greater consistency and freedom from jitter spikes may well be helpful. Hm, I recently found that at least under Windows Server 2008 x64 the QueryPerformanceCounter (QPC) call is obviously emulated when running 32 bit applications on this 64 bit system. My wclkres program (32 bit binary) http://www.meinberg.de.www/download/utils/windows/wclkres-1.4.zip reports a QPC frequency of 2.341 MHz and a thus a resolution of 427 ns only. The mean execution time of a QPC call is about 64 ns, so subsequent QPC calls often return the same values. So maybe native 64 bit binaries would yield better results than 32 bit binaries on an x64 system. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
In fact I've heard of *nobody* except you, me, Danny, and Terje building ntpd on Windows ;-) [] Regards, Martin Martin, I did attempt to do this with considerable help from the folk here, and I think I even got as far as set of executables once, but as I'm not a C/C++ person, the effort involved was considerable, and I still had many warning messages (and I want to see no error or warning messages when I compile my own software). That was with VS2005, and I don't think that even runs under the Windows-7 I'll have on my next PC. Could try the XP for WIndows-7, I suppose. There is a free Borland C/C++ compiler for Windows, but I don't know what effort might be required to port to that version, or whether it will run under Windows-7. http://edn.embarcadero.com/article/20633 I realise that my efforts don't qualify as building ntp under Windows, but I did try! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Hm, I recently found that at least under Windows Server 2008 x64 the QueryPerformanceCounter (QPC) call is obviously emulated when running 32 bit applications on this 64 bit system. My wclkres program (32 bit binary) http://www.meinberg.de.www/download/utils/windows/wclkres-1.4.zip reports a QPC frequency of 2.341 MHz and a thus a resolution of 427 ns only. The mean execution time of a QPC call is about 64 ns, so subsequent QPC calls often return the same values. So maybe native 64 bit binaries would yield better results than 32 bit binaries on an x64 system. Regards, Martin -- Martin Burnicki Martin, Some extra reference points for you - I just checked on a couple of Windows-7 64-bit systems: Intel D330 Atom PC (Molde): QPC: 1.563 MHz, 51ns (my own software shows 26ns for a GetTickCount call, and 51ns for QPC) Intel i5-760 PC (Alta) QPC: 2.744 MHz, 33ns QPC: 2.744 MHz, 15ns (second run) (my own software shows 6ns for a GetTickCount call, and 12ns for QPC) Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Brolin, sorry for the late reply. I've been offline due to a really bad cold. Brolin Empey wrote: Martin Burnicki wrote: Brolin, Brolin Empey wrote: I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Hm, this sounds like a Windows bug ... No, it is by design. :( Hm, then this is IMO a bad design. I knew there was a registry flag telling Windows the RTC runs on UTC instead of local time, and yet I had assumed the OS would read UTC instead of local time from the RTC at startup, and write UTC instead of local time to the RTC on shutdown. Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. Do you need correct time for the on-board RTC for a special application? No, but I still want my clocks to have accurate time. As far as I know this is only used to initialize the Windows system time when Windows starts up, so your system time may be wrong until ntpd has a chance to correct it, i.e. it can reach an NTP server. I am using Microsoft?s w32time service, not ntpd. OK. I have configured the w32time service to start automatically, but it does not seem to start automatically, so my system time is approximately 2 minutes behind until I run net start w32time w32tm /resync in an elevated (with administrative privileges) cmd.exe session. So this is already a different problem which should be fixed. Ntpdate should also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling ?hwclock.exe? returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. During normal operation the ntpd service should not call the Windows SetSystemTime() API since doing so causes a time offset offset to be applied to the system time. As far as I know ntpd calls SetSystemTime() only when the Windows system time needs to be stepped anyway, or when the ntpd service shuts down. Calling SetSystemTime() should also set the HW clock. If this doesn't happen then the Windows bug mentioned above is probably inside that Windows API call. Again, I am using w32time, not ntpd. The behaviour you call a bug is by design. I looked up SetSystemTime on MSDN but could not find anything even suggesting SetSystemTime is supposed to update the hardware clock. I actually could not find any official documentation on how to set the hardware clock from a userspace application on Windows NT, but I have found how (see below). I said as far as I know SetSystemTime() also sets the system time. I had made some tests a few years ago, and if I remember correctly the RTC
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Martin Burnicki wrote: also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. Did you mean that? NTP has been buildable for 32 bit Intel machines running Windows, since NT 3.5, and Meinberg provide an installer for 32 bit Windows. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
On Mon, Jan 3, 2011 at 16:34 PM, Martin Burnicki martin.burni...@meinberg.de wrote: I have configured the w32time service to start automatically, but it does not seem to start automatically, so my system time is approximately 2 minutes behind until I run net start w32time w32tm /resync in an elevated (with administrative privileges) cmd.exe session. So this is already a different problem which should be fixed. Ntpdate should also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. http://davehart.net/ntp/win/x86/ has a lot of evidence that should assure you. By the way, now would be a good time to verify the current ntp-dev sources build on VC6 and the result works, as another -dev - -stable transition is about due. It's been just over a year since 4.2.6 came out, and a lot of good stuff has been introduced in 4.2.7. I am aware of no one else building NTP on Windows using a compiler older than Visual Studio 2008 recently, despite highly duplicative and maintenance-heavy vc6, vs2003 and vs2005 project files. I wish there were others with access to VC6 reporting problems sooner, but I expect once again it will be left to you and I to ping-pong through any vc6 build issues that have crept up. Hm, BTW, I don't know how I could load such a kernel driver under Windows? Under NT you could install non-PNP drivers like a service, and then load them with net start my_kernel_driver. In current systems drivers are loaded by the kernel automatically, e.g. if a PCI card is detected which is handled by that driver. Don't know if you can still load a kernel driver manually. I believe so, to the extent you can load the driver at all: Most new Windows installations are x64, and Microsoft makes it enough of a pain to use unsigned drivers on 64-bit versions of Windows that I suspect it's impractical for unattended use. I believe unsigned drivers are still allowed in x86 installs of Vista and Win7, likely with a few layers of Danger! popups. This is a bit of a looming brick wall for my serialpps.sys hack, unless some kind soul manages the unlikely feat of getting it through WHQL driver certification and signed by Microsoft.. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
[] I believe so, to the extent you can load the driver at all: Most new Windows installations are x64, and Microsoft makes it enough of a pain to use unsigned drivers on 64-bit versions of Windows that I suspect it's impractical for unattended use. I believe unsigned drivers are still allowed in x86 installs of Vista and Win7, likely with a few layers of Danger! popups. This is a bit of a looming brick wall for my serialpps.sys hack, unless some kind soul manages the unlikely feat of getting it through WHQL driver certification and signed by Microsoft.. Cheers, Dave Hart It would certainly be good to have kernel-mode timestamps in Win-64. Although the average jitter reduction achieved by switching from user-mode to kernel-mode is not great (say from 3.5 microseconds to 2.2 microseconds), the greater consistency and freedom from jitter spikes may well be helpful. Here's one observation of a PC here: http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#kernel Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Dave Hart wrote: On Mon, Jan 3, 2011 at 16:34 PM, Martin Burnicki martin.burni...@meinberg.de wrote: I have configured the w32time service to start automatically, but it does not seem to start automatically, so my system time is approximately 2 minutes behind until I run net start w32time w32tm /resync in an elevated (with administrative privileges) cmd.exe session. So this is already a different problem which should be fixed. Ntpdate should also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. http://davehart.net/ntp/win/x86/ has a lot of evidence that should assure you. By the way, now would be a good time to verify the current ntp-dev sources build on VC6 and the result works, as another -dev - -stable transition is about due. It's been just over a year since 4.2.6 came out, and a lot of good stuff has been introduced in 4.2.7. I am aware of no one else building NTP on Windows using a compiler older than Visual Studio 2008 recently, despite highly duplicative and maintenance-heavy vc6, vs2003 and vs2005 project files. I wish there were others with access to VC6 reporting problems sooner, but I expect once again it will be left to you and I to ping-pong through any vc6 build issues that have crept up. I still have my VC6 ISOs, I could load them into a VMware client machine (I don't expect it to be possible to install VC6 alongside VS2008?). I have been compiling and uploading new releases of both ntp stable and -dev about weekly for a while now, but as you noted this has been with VS2008. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Martin Burnicki wrote: Brolin, Brolin Empey wrote: I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Hm, this sounds like a Windows bug ... No, it is by design. :( Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. Do you need correct time for the on-board RTC for a special application? No, but I still want my clocks to have accurate time. As far as I know this is only used to initialize the Windows system time when Windows starts up, so your system time may be wrong until ntpd has a chance to correct it, i.e. it can reach an NTP server. I am using Microsoft’s w32time service, not ntpd. I have configured the w32time service to start automatically, but it does not seem to start automatically, so my system time is approximately 2 minutes behind until I run net start w32time w32tm /resync in an elevated (with administrative privileges) cmd.exe session. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling ?hwclock.exe? returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. During normal operation the ntpd service should not call the Windows SetSystemTime() API since doing so causes a time offset offset to be applied to the system time. As far as I know ntpd calls SetSystemTime() only when the Windows system time needs to be stepped anyway, or when the ntpd service shuts down. Calling SetSystemTime() should also set the HW clock. If this doesn't happen then the Windows bug mentioned above is probably inside that Windows API call. Again, I am using w32time, not ntpd. The behaviour you call a bug is by design. I looked up SetSystemTime on MSDN but could not find anything even suggesting SetSystemTime is supposed to update the hardware clock. I actually could not find any official documentation on how to set the hardware clock from a userspace application on Windows NT, but I have found how (see below). So, is there an NTP client or any other application for Windows NT which can write the Windows NT system time to the hardware clock so I do not have to write hwclock.exe for Windows NT? A proper solution would indeed be to write a program which just reads the current system time without changing it, and then writes the system time to the HW clock. However, this requires a devce driver to be able to write to the CMOS chip. I'm not sure whether there is a documented or undocumented software interface to the Windows kernel to call Windows' built-in driver. The HalSetRealTimeClock function in the Windows NT kernel’s HAL needs to be called but, AFAICT, even a device driver cannot call HalSetRealTimeClock. I actually downloaded and installed Microsoft’s Windows Driver
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Brolin, Brolin Empey wrote: I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Hm, this sounds like a Windows bug ... Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. Do you need correct time for the on-board RTC for a special application? As far as I know this is only used to initialize the Windows system time when Windows starts up, so your system time may be wrong until ntpd has a chance to correct it, i.e. it can reach an NTP server. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling ?hwclock.exe? returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. During normal operation the ntpd service should not call the Windows SetSystemTime() API since doing so causes a time offset offset to be applied to the system time. As far as I know ntpd calls SetSystemTime() only when the Windows system time needs to be stepped anyway, or when the ntpd service shuts down. Calling SetSystemTime() should also set the HW clock. If this doesn't happen then the Windows bug mentioned above is probably inside that Windows API call. So, is there an NTP client or any other application for Windows NT which can write the Windows NT system time to the hardware clock so I do not have to write hwclock.exe for Windows NT? A proper solution would indeed be to write a program which just reads the current system time without changing it, and then writes the system time to the HW clock. However, this requires a devce driver to be able to write to the CMOS chip. I'm not sure whether there is a documented or undocumented software interface to the Windows kernel to call Windows' built-in driver. Maybe a workaround would be the usual way to let Windows write the local time to the RTC, and then tell your Linux system the RTC runs in local time. This should only cause a problem if you whut down Windows before a DST changes, and boot Linux the next time after DST has changed. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Brolin Empey bro...@brolin.be wrote: David Woolley wrote: unruh wrote: On 2010-12-11, Jan Ceuleers janspam.ceule...@skynet.be wrote: Piece of feedback below. There's no way I'm going to read all that. If you have a question for us, please can you put it a little more succinctly? Thanks. Actually, I /did/ write my question succinctly at the end of my post. I think your post was very clear and I learned something from it that I did not know. You clearly formulated what you want. Don't bother with Jan Ceuleers. There will always be people who don't read your post because they don't feel like it, and there is no need to post that fact in a followup. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13’s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling “hwclock.exe” returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. So, is there an NTP client or any other application for Windows NT which can write the Windows NT system time to the hardware clock so I do not have to write hwclock.exe for Windows NT? Thanks for reading, Brolin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Piece of feedback below. On 11/12/10 13:07, Brolin Empey wrote: I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13’s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling “hwclock.exe” returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. So, is there an NTP client or any other application for Windows NT which can write the Windows NT system time to the hardware clock so I do not have to write hwclock.exe for Windows NT? Thanks for reading, Brolin There's no way I'm going to read all that. If you have a question for us, please can you put it a little more succinctly? Thanks. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
On 2010-12-11, Jan Ceuleers janspam.ceule...@skynet.be wrote: Piece of feedback below. On 11/12/10 13:07, Brolin Empey wrote: I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware clock (RTC) runs in UTC, as it should, instead of the local time zone, as Microsoft still uses for the completely illogical default configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully working beginning in Windows Vista SP2 + Windows 7, but there is still a problem: When RealTimeIsUniversal=0, which is also used when the RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT system time to the hardware clock during the shut down process. When RealTimeIsUniversal=1, though, the Windows NT system time is never written to the hardware clock. Consequently, I have to boot Ubuntu from a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then use ntpdate-debian + hwclock to synchronise the Linux system clock with an NTP server on the Internet, then write the sufficiently-accurate-for-me Linux system time to the hardware clock so Windows 7 will set the Windows NT system clock from the accurate time in the hardware clock. After some time (at least 1 week, not sure.), though, my hardware clock is approximately 2 minutes behind the correct time from an NTP server, but Windows 7 never writes the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, so I have to use my Ubuntu USB flash drive again. I know the proper solution is to get Microsoft to change Windows 7 so it can write the Windows NT system time to the hardware clock even when RealTimeIsUniversal=1, but that has not yet happened. I have at least asked a Microsoft employee about it, though, so they know users (well, at least 1 user. :)) want the feature. I can use w32time to force a synchronisation, but then I have to do that every time I boot Windows 7. brolin-V13 travels with me between home and work, so it is not always running. Maybe this causes the hardware clock to fall behind, but I do not think I can prevent having to shut down and boot brolin-V13 on a daily basis. Since I do not know if Microsoft will ever enable Windows 7 to write the Windows NT system time to the hardware clock when RealTimeIsUniversal=1, the next best solution is probably to write a hwclock.exe application for Windows NT, but I am hoping someone has already implemented this functionality in an application such as an NTP client. Googling ?hwclock.exe? returns lots of noise because some malware uses this file name, but I have not found any real hwclock.exe equivalent to hwclock used on Linux. So, is there an NTP client or any other application for Windows NT which can write the Windows NT system time to the hardware clock so I do not have to write hwclock.exe for Windows NT? Thanks for reading, Brolin There's no way I'm going to read all that. If you have a question for us, please can you put it a little more succinctly? Thanks. To summarize as I understand it-- how do you keep the RTC synced to the true time under Windows? (System running ntp so assume that the system time is the true time). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
unruh wrote: On 2010-12-11, Jan Ceuleers janspam.ceule...@skynet.be wrote: Piece of feedback below. There's no way I'm going to read all that. If you have a question for us, please can you put it a little more succinctly? Thanks. That's not a good policy to encourage. You will get the common Subject: Help; It doesn't work. Fix it. postings common on many support groups. To summarize as I understand it-- how do you keep the RTC synced to the true time under Windows? (System running ntp so assume that the system time is the true time). He wants the RTC to contain UTC, even though Windows isn't in the GMT timezone with DST disabled. Windows normally stores the system wall clock time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
David Woolley wrote: unruh wrote: On 2010-12-11, Jan Ceuleers janspam.ceule...@skynet.be wrote: Piece of feedback below. There's no way I'm going to read all that. If you have a question for us, please can you put it a little more succinctly? Thanks. Actually, I /did/ write my question succinctly at the end of my post. To summarize as I understand it-- how do you keep the RTC synced to the true time under Windows? (System running ntp so assume that the system time is the true time). He wants the RTC to contain UTC, even though Windows isn't in the GMT timezone with DST disabled. Windows normally stores the system wall clock time. My RTC already runs in UTC, but my RTC is approximately 2 minutes behind because I have no way of writing the Windows NT system time to the hardware clock (RTC) after using an NTP client to synchronise the Windows NT system time. On Ubuntu, I use ntpdate-debian + hwclock, but I cannot find a real hwclock for Windows NT, only malware which uses the name hwclock.exe as a disguise. I need an hwclock.exe application for Windows NT so I can run “hwclock --utc --systohc” like on Ubuntu. I am asking in this group because I thought someone may know of an NTP client for Windows NT with this functionality, now that Microsoft has finally fully fixed support for RealTimeIsUniversal=1 beginning in Windows Vista SP2 + Windows 7. My original post (and this reply too) make perfect sense to me, but I suspect my readers did not have all of the required background knowledge. If you are not already familiar with Windows NT’s RealTimeIsUniversal registry key, please read http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html. If you are not already familiar with the hwclock command from the util-linux(-ng) package, please read http://manpages.ubuntu.com/manpages/lucid/man8/hwclock.8.html. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?
Brolin Empey bro...@brolin.be wrote in message news:nssmo.1329$317.1...@newsfe20.iad... [] My RTC already runs in UTC, but my RTC is approximately 2 minutes behind because I have no way of writing the Windows NT system time to the hardware clock (RTC) after using an NTP client to synchronise the Windows NT system time. On Ubuntu, I use ntpdate-debian + hwclock, but I cannot find a real hwclock for Windows NT, only malware which uses the name hwclock.exe as a disguise. I need an hwclock.exe application for Windows NT so I can run “hwclock --utc --systohc” like on Ubuntu. I am asking in this group because I thought someone may know of an NTP client for Windows NT with this functionality, now that Microsoft has finally fully fixed support for RealTimeIsUniversal=1 beginning in Windows Vista SP2 + Windows 7. Brolin, If it helps, here is rather old code for DOS for reading the RTC. I'm not sure how you would map the INT 26 (hex 1A) to Windows. You may also need to give the program port mapping capabilities. Cheers, David function from_bcd (bcd: byte): word; begin from_bcd := 10 * ((bcd and $F0) shr 4) + (bcd and $0F); end; procedure get_rtc_time (var h, m, s: word); var r: Registers; begin with r do begin ah := $02; Intr ($1A, r); h := from_bcd (ch); m := from_bcd (cl); s := from_bcd (dh); end; end; procedure get_rtc_date (var y, m, d: word); var r: Registers; begin with r do begin ah := $04; Intr ($1A, r); y := 100*from_bcd (ch) + from_bcd (cl); m := from_bcd (dh); d := from_bcd (dl); end; end; ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
