Path: csiph.com!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.fr7!futter-mich.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!post01.iad!fx03.iad.POSTED!not-for-mail Subject: Re: clock synchronization over IP Newsgroups: comp.arch.embedded References: <62e2b060-8c06-4d78-99cf-144b9b183e88@googlegroups.com> <4245ed03-69bb-423a-aee2-369e84299ebb@googlegroups.com> From: Clifford Heath User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4245ed03-69bb-423a-aee2-369e84299ebb@googlegroups.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Lines: 9 Message-ID: X-Complaints-To: DMCA@thecubenet.com NNTP-Posting-Date: Tue, 18 Sep 2018 11:10:12 UTC Date: Tue, 18 Sep 2018 21:10:12 +1000 X-Received-Bytes: 1566 X-Received-Body-CRC: 3362403061 Xref: csiph.com comp.arch.embedded:28047 On 17/09/18 18:45, gp.kiwi@gmail.com wrote: > Without hardware support I suspect that kind of accuracy requires a low traffic LAN, although it's possible that it keeps trying until it achieves a really short round-trip time. NTP tries to measure the minimum round-trip time, then halve it to get the one-way time, and choose the packets that arrived quickest. It's surprisingly good even on a busy network, because it can detect that and spend longer searching for "good" round trips.