[ntp:questions] [Android+NTP] synchronise time with millisecond accuracy

Brian Utterback brian.utterback at oracle.com
Wed Mar 26 13:52:32 UTC 2014


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.
>>
>> Is there any way to synchronise the device with milliseconds accuracy?
>>
>> Here is my test scenario configuration:
>>
>> Android Server:
>> This is a machine running Debian that will be used as the ntp server and will send traffic to the Android device. This machine is connected with an Ethernet cable to have internet access
>>
>> Android AP:
>> This machine is running Debian and acts as an Access Point. It is also connected to the Android Server with an Ethernet cable.
>>
>> Android Device:
>> An Android device with root access. It is connected to the Android AP via WiFi. This device will receive the traffic generated by the Android Server, and must be synchronised with it.
>>
>> Some notes:
>> I do not need the Android Server to be synchronised with an external ntp server. Therefore, I changed the ntp.conf to have only "server 127.127.1.0".
>>
>> In order to synchronise the Android device I use the ntpd and have also tried with ntpclient. However, the results are very similar.
>    You could take out any network transmit/receive asymmetry by having the server broadcast and configure the android device as a broadcast client.
>
>    As a quick test I pulled the ethernet cable on my laptop and configured wifi so I have a similar topology to you , though BSD. It is configured in standard client/server mode.
>
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> 	ether 34:15:9e:01:e5:9c
> 	inet 192.168.1.12 netmask 0xffffff00 broadcast 192.168.1.255
> 	media: autoselect (100baseTX <full-duplex,flow-control>)
> 	status: active
> electron:~ mike$ ntpq -pn
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *192.168.1.4     .PPS1.           1 u   49   64  377    0.938   -0.284   0.037
>
> # pull the ethernet cable and configure wifi
>
> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> 	ether f8:1e:df:e4:49:41
> 	inet 192.168.1.14 netmask 0xffffff00 broadcast 192.168.1.255
> 	media: autoselect
> 	status: active
>
> # wait until the dust settles. NTP takes a bit of time to get to a clean state.
>
> 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.

Brian Utterback



More information about the questions mailing list