How can I keep raspberry timekeeping accurate?

Question

I have 3 Raspberry 3 Model B devices. Their operation system is Windows 10 IOT, they were installed on the same day (yesterday).

I have very strange experiences with their timekeeping, they are highly inaccurate. Some of them some secs behind the correct time, while others 3-4 minutes. The common behaviour is inaccurancy.

I try to force time sync at every startup by calling "w32tm /resync /force" in a startup scheduled script. It does not seem to help at all.

I also tried to use different Wi-Fi networks (from different vendors), the problem exists on all of them.

When queriing time status by w32tm /query /status I get the following results:

Device 1

Leap Indicator: 3(last minute has 61 seconds) Stratum: 0 (unspecified) Precision: -23 (119.209ns per tick) Root Delay: 0.0000000s Root Dispersion: 0.0000000s ReferenceId: 0x00000000 (unspecified) Last Successful Sync Time: unspecified Source: Local CMOS Clock Poll Interval: 10 (1024s)

Device 2

Leap Indicator: 0(no warning) Stratum: 3 (secondary reference - syncd by (S)NTP) Precision: -23 (119.209ns per tick) Root Delay: 0.1734432s Root Dispersion: 0.4173777s ReferenceId: 0x338C7FC5 (source IP: 51.140.127.197) Last Successful Sync Time: 7/14/2017 7:48:12 AM Source: time.windows.com,0x9 Poll Interval: 15 (32768s)

Device 3

Leap Indicator: 0(no warning) Stratum: 3 (secondary reference - syncd by (S)NTP) Precision: -23 (119.209ns per tick) Root Delay: 0.1850726s Root Dispersion: 16.7226250s ReferenceId: 0x338C7FC5 (source IP: 51.140.127.197) Last Successful Sync Time: 7/14/2017 11:42:52 AM Source: time.windows.com,0x9 Poll Interval: 10 (1024s)

I read topics over the net about the issue, but I could not find any working solution. I seems very strange for me, time should be critical factor in the majority of applications, so there must be a solution.

Would you be so kind to help me to solve it? Any suggestions are highly appriciated!

Kaiser

Do you mean the time displayed on the DefaultApp ? – Dobby

In the UWP headless app developed by us. I know the DefaultApp's time is inaccurate, even if the system time I read by my code is OK. – Kaiser

Have you tried using net cable instead of wifi? Can these three device get the same time? – Dobby

Yep, I tried, result is the same. Now all are updated to the latest Win 10 IOT version, it seems much more better now. I'll test it for a while and let you know the results. – Kaiser

After a while, it happens again and again, pi starts to late some minutes. So update did not help! I tried it on 5 devices and 3 wi-fi networks, it happens all of them. – Kaiser

Do you have a Linux box at your place which you could use as time server for your Raspberrys? – Cupcake

Answer 1

At first, I have to state that I did not touch Windows 10 yet, and I did not touch a Raspberry yet. On the other hand, I have seen the following method solving all time synchronization problems with so many Windows machines of all sorts that you could give it a try.

The problems (according to my experience):

1) time.windows.com is extremely unreliable. In my setups and those of several customers, in most cases time did not synchronize reliably after an out-of-the-box installation of Windows, even if no wireless connection was involved and even if there was a reliable high data rate / low latency connection to the internet provider.

2) Windows seems to query the NTP servers in an unusual (we could also say: wrong) way. While I am not deep enough into NTP to give a detailed explanation, Windows as a client seems to send so-called "symmetric active" packets to servers instead of normal "client packets". So at first it works very unreliably with other (standard) NTP servers, too.

Possible solutions

The solution to problem 1) is obvious: Install a standard NTP server somewhere in your network. If you have a Linux box at hand, I eventually could help you configure this correctly. Then, connect your Raspberrys to this NTP server via cable and on the Raspberrys apply the solution to problem 2 (see below).

The solution to problem 2) is less obvious and involves setting an undocumented flag (at least, it is undocumented in Windows 7 Pro which I have at hands right now) for the Windows time service. You already have queried the Windows time service status, and you have shown us the output. Please note the following part from your output (e.g. for device 2):

Source: time.windows.com,0x9 Poll Interval: 15 (32768s)

The problem is the 0x9 which should be 0x8. To change that flag, open a command line window as administrator (just belonging to the administrative group will not be enough) and execute the following command:

w32tm /config /manualpeerlist:xxx.xxx.xxx.xxx,0x8 /syncfromflags:MANUAL

Note how the correct flag 0x8 is added (of course, xxx.xxx.xxx.xxx is the IP address of your NTP server, but you could give a normal host name (e.g. ntpserver.example.org) as well). Basically, the line above tells the Windows time service which server it should synchronize to, that it should synchronize only to that server, and that it should send normal client request packets (instead of active symmetric packets) to that server.

After you have done this, you have to apply the change either by restarting the Windows time service of by updating its configuration (I prefer the first one).

If you then query the status again, there will be the following part in your output:

Source: xxx.xxx.xxx.xxx,0x8 Poll Interval: xx (xxxxxs)

Note that the flag in the output now has changed from 0x9 to 0x8.

Two final notes

1) I am not sure if the solution to problem 2) works if you insist on synchronizing to time.windows.com. Since it is not reliable, I haven't used it for years now. Chances are that the situation even becomes worse if you change said flag from 0x9 to 0x8, but still use time.windows.com as NTP server.

Setting up your own NTP server in your local network is a very good idea for several reasons (I won't go into detail here because it would be off-topic). If you can't or don't want to do this, I recommend using other public time servers (start your search by visiting http://www.ntp.pool.org) instead of time.windows.com. They will definitely work with the solution to problem 2).

2) As a last resort, you could try to install another time service into Windows. For example, there is a full-blown port of the NTP software for Windows, but AFAIK, only for the Intel platform. Since I don't know anything about the Raspberry (ARM) platform, I don't know if there is another time service software at all, so this is just an idea in case every other method fails.

Cupcake

Answer 2

Device 1 does not seem to use a timeserver at all, enforce the same config on all devices.

I would simply suggest you to try a different timeserver. I've had similiar issues, sometimes this is not even hardware related but a network thing. Noone knows what is between you and a timeserver and it can be sufficient to try a different network then.

http://www.pool.ntp.org/en/use.html

w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

It should be good enough... but the RPi has no RTC (Real Time Clock) onboard. You can buy one tho, google for raspberry pie rtc.

Without an RTC, the RPi builds a time with its CPU cycles. These are not as super accurate and can be even more drifting when you overclock the CPU.

This question could maybe be better answered on https://raspberrypi.stackexchange.com/

If you don't want to buy the chip, you could try to change the voltage and let the time update more often from the timeservers.

Leary

I tried 3 networks, and othr devices has timeserver, which are also inaccurate. Thanks a lot! – Kaiser

And thank you for your suggestion, I'll try to set a different time server. – Kaiser

It did not help. After some days of testing device lates 5 minutes. – Kaiser

How often do you update the time? It must be accurate as soon as it updates (every hour for example). – Leary

How can I set update frequency? Isn't it handled by the OS itself? – Kaiser

I only know how to do it in linux but it works also in windows. Maybe you don't even really syncronize the time or only a single time!. Please google for windows time server interval it will give you good explanations. – Leary

you could try to change the voltage and let the time update That's not how any of this works... – Mooncalf

@Mooncalf I am not a physician but I guess the voltage affects the accuracy of the RPIs timekeeping. Please tell me if this is wrong. Yet of course if you let the time update more often throug ntp it is more likely to be accurate. But that's two different things. – Leary

[electronic engineer] And no, it does not affect it. The frequency can affect it. Voltage has nothing to do with it in this case. – Mooncalf

Answer 3

Since the Pi lacks a real-time clock, you should choose a two-pronged approach for best results.

Choose a different time server to do long-term corrections and then install real-time clock module similar to this one on top of it to keep the time very close when not connected to the network. This module is temperature-stabilized, requires no soldering, uses the ubiquitous I2C interface, and claims high accuracy and long battery life. Been happy with many Adafruit products.

As far as time servers go, please have a look at this resource. They even include (in their terms of service) guidelines on how to set up ntp for best use (and distributed load on their pool).

Bebop

Answer 4

Try using a Real Time Clock (RTC) like this because with some devices when you unplug it it will reset the time and date. If your clock's time is off by quite a bit. It may take up to 3 hours to correct itself, because changes from the server are applied gradually to your local clock. Network stability has the biggest impact on the accuracy, because a unpredictable network (something more wireless, like 3G) will make it very hard to be accurate. You can also find a support. If you have the fake-hwclock package, it will also do a timestamp saving trick to prevent the clock from being reset. That won't advance time while the device is off, so it will lag behind. The internal clock will also drift a tiny bit while on.

Sources

Danelaw

Do RasPi RTC devices work with Windows 10 IoT? (Does Windows 10 IoT support them?) The time must be read from the RTC upon boot and applied to the system. Linux supports this, does Windows? – Seraphine

Answer 5

I can offer some insight based on experience. Our machine devices have a multitude of resources available to update time. Somewhat a requirement of the deployment. Although there is an internal clock on our device, the battery is insufficient to keep it accurate over long periods of time when the vehicle each is installed on is not running. (Hardware upgrades have been done to improve this.)

We provide a web service, and a time service which each allows the internal clock to update every 24 hours or when turned on. In some cases, the time is included with some of the data transmissions that the device does and checked for accuracy and told to update if the variance is too large. In some configs, the user can check the time and activate and update if needed. A bit old school, but these have been around for a few years now.

A quality RTC, and battery, should be spec'd if the device solution requires it, don't skimp out on this hardware if it really is needed.

Here is pretty good troubleshooting guide as well, I think this is different hardware but the principles are similar.

Here is a good list of some RTCs

Also here is a link to Adafruit

Glorygloryofthesnow