[ntp:questions] [Android+NTP] synchronise time with millisecond accuracy
michael.cook at sfr.fr
Wed Mar 26 16:50:18 UTC 2014
Le 26 mars 2014 à 14:52, Brian Utterback a écrit :
> On 3/26/2014 8:00 AM, mike cook wrote:
>> Le 26 mars 2014 à 12:09, Coiso22 a écrit :
>>> Hi all,
>>> I am trying to synchronise the time of an Android device with a local machine, for test purposes, using ntp. However, the difference between the time of the device and the ntp server is always around 5 milliseconds.
>> electron:~ mike$ ntpq -pn
>> remote refid st t when poll reach delay offset jitter
>> *192.168.1.4 .PPS1. 1 u 20 64 377 1.600 0.131 14.759
>> As you can see the delay and jitter (which is very variable ) go up, but the offset stays < 1ms. So it should be possible for you to do better.
>> If you have another non Android wifi client on your net, what do you see with that as a client?
> Mike, what makes you think that this is any more accurate than it was before? It surely is the case that NTP thinks that it has less offset, but with a jitter value that high is it almost certainly wrong about that, but it has no way to know what the real value is, so it displays only what the latest calculated offset of the moment was. Essentially you went from an offset of -0.284+/-0.037 to an offset of 0.131+/-14.759 I don't think that is an improvement.
You are right of course. I just picked the last of my samples which happened to be the worst. 10 mins later we were back at
electron:~ mike$ ntpq -pn
remote refid st t when poll reach delay offset jitter
*192.168.1.4 .PPS1. 1 u 50 64 377 1.586 0.031 1.226
with the jitter figures in the >1< 2ms bucket. I was just pointing out that < 5ms looks doable.
That said and in line with your comments, the variability of the jitter over wifi does make sub-ms accuracy questionable.
> Brian Utterback
> questions mailing list
> questions at lists.ntp.org
More information about the questions