"Your clock is not in sync"

[chuacw]

Before filing a new issue, please provide the following information.

I'm running:

• Parity version: 1.7.3
• Operating system: Windows
• And installed: via installer

I'm seeing the following message at the bottom of the browser where the yellow bar/charts are:

"Your node is still syncing, the values you see might be outdated. Wait until it's fully synced.
Your clock is not in sync. Detected difference is too big for the protocol to work. 573ms. Synchronize your clock."

This is despite me syncing the time to time.nist.gov.

[5chdn]

573ms is fine. You can ignore that warning.

The actualy warning is:

Your node is still syncing, the values you see might be outdated. Wait until it's fully synced.

This means your blockchain is not synchronized yet.

[chuacw]

If this warning about the clock not being in sync can be ignored, then please do not provide such a warning.

It is confusing because you say it can be ignored, but at the same time, the output says "Detected difference is too big for the protocol to work".

This makes me think it's not working.

[5chdn]

Actually, you are right, this should be addressed but we are clueless why it shows such high time offsets, it somehow includes latency from somewhere. We are currently unable to fix it, any volunteers welcome! I can give some pointers.

[chuacw]

What files are involved?

[5chdn]

This is the formula:

https://github.com/paritytech/parity/blob/master/dapps/node-health/src/time.rs#L22-L31

Here is the actual code:

https://github.com/paritytech/parity/blob/master/dapps/node-health/src/time.rs#L167-L172

The problem is one of these four variables includes the time to create the package (probably) and this introduces some additional latency.

cc @tomusdrw

[chuacw]

// In the code, drift = ((T2 - T1) + (T3 - T4)) / 2

The problem is that your algorithm doesn't take into account the case where the incoming and outgoing routes between the client and the server do not have similar delay.

Also, is T2 always > T1 and is T3 always > T4? If not, I suggest using the absolute function, eg,

i32::abs(T2 - T1)
i32::abs(T3 - T4)

or i64::abs (Use the appropriate type) which would always yield positive numbers.

It also appears that round trip delay wasn't taken into account.

In addition, I'm unable to see whether there is code to ensure that the client and the server are taking their time from the same NTP server or not.

[5chdn]

The formula is not the issue, it's taken from SNTP, see https://tools.ietf.org/html/rfc1769 (page 9).

The round trip delay was also my first suspection, but the formula takes care of that. The unexplained offset happens somewhere between T1 and T2. You can use something like

trace!(target: "dapps", "T1: {:?}", orig_time);

and run the client with -l dapps=trace to debug the formula.

[robertandrewsmith]

Hi, I am also having a Time Sync problem too. I am running a VPN on a virtual machine. The clock time and date is correct for local time, but the proxy server is in another country in another timezone. How can I retain using my service and have this resolved?

I will add that by turning off the VPN, I am able to sync the blockchain. Seems to me like syncing over a VPN should be a basic parameter for users on Parity.

[ndru123]

I'm also having the same problem after I updated to 1.7.6:
"Your clock is not in sync. Detected difference is too big for the protocol to work: 1398ms. Synchronize your clock."

Parity Version: 1.7.6
OS: Windows 10, 64 Bit
installed: via Installer

Ist this the reason why my past transactions aren't listed in parity anymore? There's also 10000 of a strange coin named Simoleon (SIM) in my wallet since the update. When I watch my address on etherscan.io there has never been a transaction of that coin to my address though. Maybe this is also a sideeffect of my wallet not being correctly synced?

[asmodat]

Parity Version: 1.7.6
OS: Windows 10, 64 Bit
installed: via Installer

exactly the same issue

--ntp-server 216.239.35.8:123
this does not work
--ntp-server time.google.com
also desnt work

[Yuripetusko]

+1 same here on OSX 1.7.6 stable

Your clock is not in sync. Detected difference is too big for the protocol to work: 602ms. Synchronize your clock.

[5chdn]

It's not a time server issue. It's how the time is calculated in parity. Please ignore it for now.

@tomusdrw look, I just had my first negative value at the office.

[tomusdrw]

The formula works fine if the latency from client to server is the same as latency in the other direction. It seems for some reason that it's not the case. I suspect there are two issues here:

1. Parity is trying to discover peers at the same time causing some excessive UDP traffic
2. For further NTP requst we are not using the server that actually responded, but rather go to the main one.

(2) is fixable, but a bit more involved.

Also please note that some of the results listed in this thread might actually be positive - i.e. you should go to https://time.is and confirm that the time is exact. If it is the error can be ignored.

[ineeve]

I also have the warning: "Time Synchronized (-4577 ms)"

[ltfschoen]

I am using Parity v1.8.0-beta and it shows

Time Synchronized (-1311 ms)

Your clock is not in sync. Detected difference is too big for the protocol to work: -1311ms. Synchronize your clock.

When I go to https://time.is/ it displays

Your clock is 1.7 seconds ahead. Accuracy of synchronization was ±0.038 seconds

[chrisdcosta]

I believe this issue is caused by the operating system, not Parity.

I regularly travel between two locations in Belgium and Switzerland. I have a mac, and I use automatic time synchronisation in the date and time settings. However even though I am in the same timezone, the timezone setting on the mac refers to my location in Belgium, and although it is supposed to update automatically, it did not. It was only until I updated the exact location within the timezone did this error go away.

My conclusion is that the operating system may be introducing an offset to the actual time somehow, and this is causing an apparent issue.

Solution
In short, check that your operating system timezone and location are correct as any difference introduces an offset in the system time causing parity to think that there is a time synchronisation issue.

Then restart your node.

This is repeatable on my mac, I can reintroduce the issue and fix it by changing the location even within the same timezone.

Edit: Solution

[TaeRoyle]

The problem is caused by Windows not synching time properly.

Use this link to synch your Windows computer to time.nist.gov not time.windows.com
https://winaero.com/blog/configure-internet-time-ntp-options-in-windows-10/

[ndru123]

My problem isn't caused by the ntp server. I tried time.nist.gov, time.windows.com, pool.ntp.org and even tried not syncing with internettime at all. Problem still persists. My timezone and location is also set correctly.

[5chdn]

It's not a Windows issue, it's a Parity issue :)

[tim0k]

I have this same issue with mac version. Could it be caused by high cpu load or something similar? As you can see, I'm syncing my time automatically.

[tomusdrw]

The threshold to produce warning has been increased in 1.7.10 and 1.8.4 in #7238. Please update Parity.

[tim0k]

I was able to get rid of this error by simply restarting my mac. Thanks anyway

[dwking2000]

workaround for me per info from @chrisdcosta is to stop parity, change timezone in Mac settings, save, change it back to correct timezone, save, start parity.