I am using a PC and a raspberry pi(both run Linux) to gather sensor data, raspberry pi gathers laser scan data, PC gathers image captured by camera. I must synchronize time for these two machines. I hope the time difference between them can be less than 1ms.

I connect them directly with a network capble, so I can't use some well known NTP servers. I pinged PC on raspberry pi, the ping time is less than 0.6ms. I come up with two ideas:

  1. Regard the PC as a NTP server, raspberry pi synchronize time from it.
  2. Create a socket connection between them, raspberry pi just send its timestamp to PC when the connection is established, thus we can know the time difference of two machines.

Which one is a better idea? Or do you have any better ideas? How to calculate the actual time difference between two machines? Can I limit the time difference to 1ms?

  • You are using a cross-over type cable to link the two ethernet ports together on the Raspberry Pi and the PC? It won't be too hard to insert a, say, small 5-port Ethernet switch or hub and provide them both with a link to the outside world via your ISP (I'm assuming you have a link to the "Interweb thingy" otherwise how would you be posting here 8-) ). I see you are relatively new to Stack Exchange so you may not know about the sister SE Community for Raspberry Pis.
    – SlySven
    Dec 18, 2015 at 3:49
  • @SlySven In fact, these two hosts will work outside on a bridge, so it is not practical to connect them to the outside Internet. Thanks for you advice.
    – Krist Pan
    Dec 18, 2015 at 4:18
  • 1
    Not directly related to synchronisation but don't forget that GPS has a very good time reference source that you ought to be to use with option 1..
    – SlySven
    Dec 18, 2015 at 4:48

1 Answer 1


The socket idea is the old venerable time protocol documented in RFC 868. The utility that synchronizes system time based on that protocol is called rdate.

You're better off using NTP because NTP will track how the clocks of the two systems naturally drift apart over time and correct for it. The time protocol should be reserved for situations where NTP is infeasible, such as embedded systems that are too tight on resources to run something as complicated as NTP (which the rpi is not).

  • OK, thanks. One more question please, Can I limit the time difference between two machines to 1ms?
    – Krist Pan
    Dec 18, 2015 at 4:21
  • NTP will do its best to keep the different as small as possible. On a local lightly loaded LAN I think it should be able to consistently achieve results in the range you are looking for, but you can always monitor (with ntpq) and find out.
    – Celada
    Dec 18, 2015 at 4:26
  • As far as I remember the clock resolution is at least 50ms or something like that...ntp is not the way to go for sync in the 1ms range Dec 18, 2015 at 6:53
  • @RuiFRibeiro I find an introduction here Network Time Protocol daemon, in the first paragraph, it says the accuracy on local area networks can be up to one millisecond. I hope this is true :)
    – Krist Pan
    Dec 18, 2015 at 12:36
  • I do not dispute NTP is pretty good at calculating the amount of time spent transmitting in the network, mind you. the internal clock has a resolution of 1/50 or 1/30 or a second, so I have my doubts it is possible to measure 1ms just using it, or even have true guarantees that both machines are synced so closely. And much less in a rpi without a true RTC chip, albeit the point is a bit moot as the actual RTC is just used to fetch the time when booting. Back when I programmed in assembly, I had to use a PIC internal do the PC (the sound chip ) to measure 150-200ms accurately... – Dec 18, 2015 at 12:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .