My use case is:
- I have old weak laptop running on my desk 24/7, its battery failed, it is powered from wall, I'm using it as a RDP thin client.
- It is not connected to the Internet all the time, only when I'm using it.
- It has the Network Time tool running on it 24/7 with 15min update interval.
- When I stop using it for the day, I disconnect it from the Internet. When I start using it the next day, the time on the laptop is wrong (stop progressing, slows down, goes backward, I'm not sure).
- I connect it to the Internet, start using it and I expect it to synchronize the time during the next ~15min or so.
- But that does not happen. Because time on the computer is bad, the Network Time tool has huuuge timeout until the next synchronization (screenshot in attachment).
Time keeping on my laptop is gone bad, maybe because its battery is non-working anymore, or because its RTC battery is non-working anymore, or whatever. This is exactly the reason why I'm using the Network Time tool. But it fails to keep my clock in sync. Thus in this feature request I'm suggesting to change method used to calculate timeout until next sync. I'm suspecting that current method calculates time in future and waits until the time arrives and then does the sync. Unfortunatley, this does not work for my use case. I would like to suggest to register a short timer (~10 seconds maybe) and at each timer tick to increment internal counter. After this counter reaches equivalent of ~15min, do the sync.
Hi Marek,
That does seem rather odd. It sounds like the time has gone backwards, but NetTime should be detecting that and try to sync straight away. If the network is down at the time, it should detect when the network goes back up and then do a sync then.
It might be worth emailing a full copy of your log file just so that I can get a better idea of what's actually going on. It might still be worth doing as you suggest, however it's also possible that something else is going on which is affecting the sync interval.
It's not really possible for software to account for bad hardware. If on one broken laptop the RTC doesn't work but countdown timers do, there's no reason to think another broken laptop won't be the other way round. As a result I would hesitate to change the way the update interval works.
My log file (2 MB text file): https://mega.nz/file/9VxyzCCD#caH96_X7Q_K51DwAyUFerBW6CunQTKckNC6rtHhSVBw
Hi Marek,
Thanks for that. I've taken a look at your log file and I've gone and taken a look at the NetTime source code as well:
NetTime already actually works pretty much as you're suggesting: It stores the number of seconds until the next sync is due and decrements that counter every second until it reaches 0 and then does a regular sync then.
From your log files, I'm guessing that you're right that there's something wrong with the real time clock in your laptop and the problem is coming about due to Windows fetching the time from the RTC and setting the system time incorrectly as a result.
After a bit of searching, can I suggest that you run the following command from an elevated command prompt:
The above should be all on a single line.
A number of pages suggest that this will actually disable the fetching of the system time from the RTC - even though the setting name doesn't really suggest this.
Make sure that you restart the system after running the above command.
Hopefully this will solve your problem but if it doesn't, let us know and I'll give you some other suggestions for things to try.
I applied the settings, did not help to solve my problem.
OK, do you have another computer that is also running all of the time? If so, you could set that up with NetTime to act as a server and configure your laptop with this issue to sync to it.