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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
