ticksDelta is extremely unstable

[pawelByszewski]

Hey, I started using Kronos a few days ago. May I have few questions regarding time sync/drifting on android?

The time seems to be complately unstable, almost each sync process ends with different diff

2020-05-01 01:49:16.804 6818-6928/Application$onCr: [kronos][sync] success sync ticksDelta[-118] responseTimeMs[222]
2020-05-01 01:50:16.934 6818-6928/Application$onCr: [kronos][sync] success sync ticksDelta[-151] responseTimeMs[129]
2020-05-01 01:50:16.994 6818-6928/Application$onCr: [kronos][sync] success sync ticksDelta[-128] responseTimeMs[56]

The calls are a minute apart from each other but the responses say that the device clock drifted 20milliseconds

Is it standard behavior of Android or am I doing something wrong?

[artem-zinnatullin]

Hey Pawel, I'm not the maintainer, but couple questions:

• do you provide custom NTP servers or use default ones?
• do you run it on emulator/device? (time might be drifting depending on that)

[pawelByszewski]

Thank you for replay @artem-zinnatullin
I tried to use the default and custom NTP servers. I run the app only on real devices(recently s8 and Pixel 2 with similar results)
Here is a piece of code form my app:

        kronosClock = AndroidClockFactory.createKronosClock(applicationContext,
//                ntpHosts = listOf("pool.ntp.org", "time.google.com", "time.apple.com"),
//                ntpHosts = listOf("time.apple.com"),
                syncListener =  object: SyncListener {
                    override fun onError(host: String, throwable: Throwable) {
                        Timber.e(throwable, "[kronos] Cannot sync for $host")
                    }

                    override fun onStartSync(host: String) {
                        Timber.d("[kronos] Start sync for host $host")
                    }

                    override fun onSuccess(ticksDelta: Long, responseTimeMs: Long) {
                        Timber.d("[kronos][sync] success sync ticksDelta[$ticksDelta] responseTimeMs[$responseTimeMs]")
                    }

                }
        )
        kronosClock!!.syncInBackground()

It is called on main thread in method onCreate class that extends MultiDexApplication.
That piece of code produces logs like that

2020-05-01 03:00:16.228 9834-10038/com.******$onCr: [kronos] Start sync for host 2.us.pool.ntp.org
2020-05-01 03:00:16.546 9834-10038/com.******$onCr: [kronos][sync] success sync ticksDelta[-172] responseTimeMs[319]
2020-05-01 03:01:31.227 9834-10038/com.******$onCr: [kronos] Start sync for host 2.us.pool.ntp.org
2020-05-01 03:01:31.502 9834-10038/com.******$onCr: [kronos][sync] success sync ticksDelta[-159] responseTimeMs[276]
2020-05-01 03:02:46.228 9834-10038/com.*****$onCr: [kronos] Start sync for host 2.us.pool.ntp.org
2020-05-01 03:02:46.458 9834-10038/com.*****$onCr: [kronos][sync] success sync ticksDelta[-145] responseTimeMs[231]
2020-05-01 03:04:01.228 9834-10038/com.*****$onCr: [kronos] Start sync for host 2.us.pool.ntp.org
2020-05-01 03:04:01.519 9834-10038/com.*****$onCr: [kronos][sync] success sync ticksDelta[-170] responseTimeMs[291]
2020-05-01 03:05:16.228 9834-10038/com.*****$onCr: [kronos] Start sync for host 2.us.pool.ntp.org
2020-05-01 03:05:16.429 9834-10038/$onCr: [kronos][sync] success sync ticksDelta[-138] responseTimeMs[201]

[amphora001]

Thanks for reporting. We will investigate this, but may take some time, pls bear with us.

[jamieadkins95]

I found that the time delta was very susceptible to high response times.

We ended up using NTP servers based in our country and ignoring any delta that had a response time of > 50ms. This made the deltas that we were using much more consistent, within a range of about 10ms.