How can I accurately follow raspberries?

Question

I have 3 devices for raspberries 3 models B. Their operating system is Windows 10 IOT, they were installed on the same day (yesterday).

I have a very strange experience of their timing, they are very inaccurate. Some of them take some time behind the correct time, while others take 3-4 minutes. Common behavior is inaccuracy.

I am trying to force the time to be synchronized every time I run, by calling "w32tm / resync / force" in the scheduled run script. It doesn't seem to help.

I also tried to use different Wi-Fi networks (from different providers), a problem exists for all of them.

When requesting time on w32tm / query / status, I get the following results:

Device 1

Jump indicator: 3 (last minute 61 seconds) Strat: 0 (not specified) Accuracy: -23 (119.209 ns per tick) Root delay: 0.0000000 Root dispersion: 0.0000000 ReferenceId: 0x00000000 (not specified) Last successful synchronization time : unspecified Source: local CMOS clock Poll interval: 10 (1024 s)

Device 2

Jump indicator: 0 (without warning) Stratum: 3 (secondary link - synchronization by (S) NTP) Accuracy: -23 (119.209 ns per tick) Root delay: 0.1734432s Root dispersion: 0.4173777 ReferenceId: 0x338C7FC5 (IP source: 51.140.127.197) Last successful synchronization time: 07/14/2017 7:48:12 AM Source: time.windows.com, 0x9 Poll interval: 15 (32768s)

Device 3

Jump indicator: 0 (without warning) Stratum: 3 (secondary link - (S) NTP synchronization) Accuracy: -23 (119.209 ns per tick) Root delay: 0.1850726s Root dispersion: 16.7226250s ReferenceId: 0x338C7FC5 (IP source: 51.140 .127.197) Last successful synchronization time: 07/14/2017 11:42:52 AM Source: time.windows.com, 0x9 Poll interval: 10 (1024 s)

I read online topics about the problem, but I could not find any working solution. It seems very strange to me, time should be a critical factor in most applications, so there should be a solution.

Could you help me solve this problem? Any suggestions are very welcome!

Answer 1

First I have to say that I have not touched Windows 10 yet, and I have not touched raspberries yet. On the other hand, I saw the following method for solving all the problems of time synchronization with a large number of Windows machines of all kinds that you could try.

Problems (in my experience):

1) time.windows.com is extremely unreliable. In my settings and for several clients, in most cases, the time did not provide reliable synchronization after installing Windows, even if the wireless connection was not involved, and even if there was a high data transfer rate / low latency connection to the Internet provider.

2) Windows seems to be requesting NTP servers in an unusual (we can also say: wrong) way. Although I am not deep enough in NTP to give a detailed explanation, Windows as a client seems to send so-called "symmetrical active" packets to the servers instead of the usual "client packets". Thus, at first it works very unrealistically with other (standard) NTP servers.

Possible solutions

The solution to the problem 1) is obvious: install a standard NTP server somewhere on your network. If you have a Linux box on hand, I could eventually help you set it up correctly. Then connect your raspberries to this NTP server via cable, and on raspberries, apply the solution to Problem 2 (see below).

The solution to the problem 2) is less obvious and involves setting an undocumented flag (at least it is not documented in Windows 7 Pro, which I now have) for the Windows time service. You have already requested the status of the Windows Time Service, and you have shown us the result. Pay attention to the following part of your output (for example, for device 2):

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

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

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

Please note that the correct 0x8 flag has been added (of course, xxx.xxx.xxx.xxx is the IP address of your NTP server, but you can specify the usual host name (for example, ntpserver.example.org) as Well). Basically, the above line tells the Windows Time service which server it should synchronize to, that it should only synchronize with this server, and that it should send regular client requests (instead of active symmetric packets) to this server.

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

If you request status again, your output will include the following part:

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

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

Last two notes

1) I'm not sure if the solution to the problem works 2) if you insist on synchronization with time.windows.com. Since it is not reliable, I have not used it for many years. Most likely, the situation even gets worse if you change the flag from 0x9 to 0x8 , but still use time.windows.com as an NTP server.

Setting up your own NTP server on your local network is a very good idea for several reasons (I will not go into details here because it will be off topic). If you cannot or do not 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 solving the problem 2).

2) As a last resort, you can try to install another time service on Windows. For example, there is a full-blown NTP software port 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 any other time maintenance software, so this is just an idea if every other method fails.

Answer 2

Device 1 does not seem to use a temporary server at all, applies the same configuration on all devices.

I just suggest you try a different time server. I had similar problems, sometimes it’s not even hardware, but a network thing. No one knows what is between you and the time server, and may be enough to try another network.

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 does not have an RTC (real time clock) on board. You can buy one tho, google for raspberry pie rtc .

Without RTC, RPi builds time with its processor cycles. This is not so super accurate and can be even more drifting when overclocking the processor.

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

If you do not want to buy a chip, you can try to change the voltage and allow time to be updated more often from timers.

Answer 3

Since Pi does not have enough real-time clocks, you should choose a two-way approach for best results.

Choose a different time server to perform long-term corrections, and then install a real-time clock module similar to this one on top of it to keep the time very close if it is not connected to the network. This module is temperature stabilized, does not require soldering, uses the ubiquitous I2C interface and requires high accuracy and long battery life. I was pleased with many Adafruit products.

Regarding time servers, please see this resource . They even include (in their terms of service) recommendations on how to configure ntp for best use (and the distributed load on their pool).

Answer 4

Try using a real-time clock (RTC) such as this , because with some devices, when you turn it off, it will reset the time and date. If your time is off quite a bit. It may take up to 3 hours to fix, as changes from the server are gradually applied to your local clock. Network stability has the greatest impact on accuracy because an unpredictable network (something more wireless like 3G, for example) will make it very difficult to be accurate. You can also find support . If you have a fake-hwclock package, it will also do the trick to save time so that the clock does not reset. This will not speed up the time while the device is turned off, so it will lag. The internal clock will also drift a bit.

Sources

Answer 5

I can offer some insights based on experience. Our machine devices have many resources available to update time. To some extent, this is a deployment requirement. Although our device has a built-in clock, the battery is not enough to keep it accurate for extended periods of time when the vehicle on which the device is installed does not work. (Hardware upgrades have been made to improve this.)

We provide a web service and a time service, each of which allows the internal clock to be updated every 24 hours or when it is turned on. In some cases, time is included in some data transfers that the device performs and checks for accuracy, and is said to update if the variance is too large. In some configurations, the user can check the time and activate and update if necessary. A little old school, but they have been around for several years.

RTC quality and battery should be specified if it requires a solution to the device, do not discard this equipment if it is really necessary.

The troubleshooting guide is pretty good here, I think this is different equipment, but the principles are similar.

Here is a good list of RTC

There is also a link to Adafruit