Timeline for Synchronizing the clocks of two Windows-XP machines not connected to the internet?
Current License: CC BY-SA 2.5
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 22, 2019 at 8:48 | comment | added | Jamie Hanrahan | One idea: It has been the case that XP has shown marked instability in timekeeping on nForce chipsets. It's been bad enough that NTP on such machines would fail to synchronize. Perhaps this sort of thing is what the OP is experiencing. Someone on the old NTP wiki reported that in one case this was fixed by changing the HAL to a NON-APIC HAL. web.archive.org/web/20060220162421/http://ntp.isc.org/bin/view/…. | |
| Jan 22, 2019 at 8:43 | comment | added | Jamie Hanrahan | btw, my earlier comment was incorrect in the IRQL level: CLOCK_LEVEL is called CLOCK2_LEVEL on x86, and it's IRQL 28, not 24. Still, the only higher IRQLs are IPI_LEVEL (interprocessor interrupt), POWER_LEVEL (an early architectural idea for reporting imminent power failure, never actually implemented), and HIGH_LEVEL (not associated with any device, it is just a level you can raise to momentarily to hold off all other interrupts). | |
| Jan 22, 2019 at 8:35 | comment | added | Jamie Hanrahan | "Other interrupts" wouldn't involve background processes, and the only interrupts of higher IRQL than CLOCK_LEVEL aren't associated with things that occur with any frequency, nor with I/O initiated by processes. So it is wildly unlikely that process-based activity is going to slow down the clock. It's completely unclear to me how the mechanism you describe could occur. Can you explain your idea further? | |
| Jan 22, 2019 at 7:55 | comment | added | harrymc | @JamieHanrahan: The stealing could involve other interrupts. | |
| Jan 21, 2019 at 23:10 | comment | added | Jamie Hanrahan | There is no such thing as "processes stealing idle CPU cycles", and updating the time does not depend on process-based or even thread-based code, nor on "idle CPU cycles" being available. It happens in the interrupt handler for the interval timer (from memory, the routine name is KeUpdateSystemTime). These interrupts are handled at IRQL CLOCK_LEVEL, ie 24 on x86. This is higher than any ordinary I/O device interrupt, let alone process-based code. Something else is going on. | |
| Nov 15, 2009 at 13:54 | comment | added | harrymc | So the cause is installed software that causes the very lousy XP internal clock to lose time, which is only normal, no worry. To sync time, you'll need to network both computers and set one as the time server of the other. | |
| Nov 15, 2009 at 13:16 | comment | added | Roee Adler | Thanks. Currently the two computers are not connected to the network at all, so Firewall settings can't be the cause. | |
| Nov 14, 2009 at 20:50 | history | answered | harrymc | CC BY-SA 2.5 |