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
