Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27990 > unrolled thread

clock synchronization over IP

Back to article view | Back to comp.arch.embedded

Contents

  clock  synchronization over IP gp.kiwi@gmail.com - 2018-08-24 17:54 -0700
    Re: clock  synchronization over IP Paul Rubin <no.email@nospam.invalid> - 2018-08-24 18:28 -0700
    Re: clock  synchronization over IP wzab01@gmail.com - 2018-09-15 09:00 -0700
      Re: clock  synchronization over IP gp.kiwi@gmail.com - 2018-09-15 15:08 -0700
        Re: clock  synchronization over IP George Neuner <gneuner2@comcast.net> - 2018-09-16 08:49 -0400
          Re: clock  synchronization over IP gp.kiwi@gmail.com - 2018-09-17 01:45 -0700
            Re: clock  synchronization over IP George Neuner <gneuner2@comcast.net> - 2018-09-17 11:30 -0400
              Re: clock  synchronization over IP gp.kiwi@gmail.com - 2018-09-17 15:04 -0700
                Re: clock  synchronization over IP George Neuner <gneuner2@comcast.net> - 2018-09-17 22:10 -0400
                  Re: clock  synchronization over IP graeme.prentice@gmail.com - 2018-09-18 04:23 -0700
                    Re: clock  synchronization over IP Andrew Smallshaw <andrews@sdf.org> - 2018-09-18 13:19 +0000
                    Re: clock  synchronization over IP Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-09-19 18:56 +0300
                    Re: clock  synchronization over IP upsidedown@downunder.com - 2018-09-22 11:51 +0300
            Re: clock synchronization over IP Clifford Heath <no.spam@please.net> - 2018-09-18 21:10 +1000
    Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-21 15:00 +0100
      Re: clock  synchronization over IP Dimiter_Popoff <dp@tgi-sci.com> - 2018-09-21 17:12 +0300
        Re: clock  synchronization over IP Robert Wessel <robertwessel2@yahoo.com> - 2018-09-21 09:58 -0500
          Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-21 16:26 +0100
        Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-21 16:02 +0100
      Re: clock  synchronization over IP George Neuner <gneuner2@comcast.net> - 2018-09-21 17:15 -0400
        Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-21 22:35 +0100
          Re: clock  synchronization over IP "gp.kiwi@gmail.com" <graeme.prentice@gmail.com> - 2018-09-21 15:16 -0700
            Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-22 00:11 +0100
              Re: clock  synchronization over IP "gp.kiwi" <graeme.prentice@gmail.com> - 2018-09-21 16:35 -0700
                Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-22 14:19 +0100
                Re: clock  synchronization over IP gnuarm.deletethisbit@gmail.com - 2018-09-22 07:22 -0700
              Re: clock  synchronization over IP graeme.prentice@gmail.com - 2018-09-21 19:40 -0700
          Re: clock  synchronization over IP George Neuner <gneuner2@comcast.net> - 2018-09-21 22:17 -0400
            Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-22 13:58 +0100
            Re: clock synchronization over IP Brett <ggtgp@yahoo.com> - 2018-09-22 18:50 +0000
      Re: clock  synchronization over IP upsidedown@downunder.com - 2018-09-22 11:56 +0300
        Re: clock  synchronization over IP gnuarm.deletethisbit@gmail.com - 2018-09-22 07:31 -0700
          Re: clock  synchronization over IP upsidedown@downunder.com - 2018-09-22 20:02 +0300
            Re: clock  synchronization over IP gnuarm.deletethisbit@gmail.com - 2018-09-22 14:40 -0700
      Re: clock  synchronization over IP gnuarm.deletethisbit@gmail.com - 2018-09-22 07:06 -0700
      Re: clock  synchronization over IP Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-09-22 20:16 +0300
        Re: clock  synchronization over IP Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-22 22:22 +0100

Page 1 of 2  [1] 2  Next page →

#27990 — clock synchronization over IP

We need to synchronize clocks (so we can synchronize audio) on physically separated controllers that are connected via ethernet that may or may not be connected to the internet.  The controllers have ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more than 50 ms difference but preferably less.  Synchronization needs to continue working between any two controllers regardless of the failure of any other controller.

Does anyone have an idea what is the easiest way to do this?  

[toc] | [next] | [standalone]

#27991

gp.kiwi@gmail.com writes:
> than 50 ms difference but preferably less....
> Does anyone have an idea what is the easiest way to do this?  

Ordinary NTP should be able to do that, especially over local ethernet.

[toc] | [prev] | [next] | [standalone]

#28022

gp....@gmail.com wrote:
> We need to synchronize clocks (so we can synchronize audio) on physically separated controllers that are connected via ethernet that may or may not be connected to the internet.  The controllers have ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more than 50 ms difference but preferably less.  Synchronization needs to continue working between any two controllers regardless of the failure of any other controller.
> 
> Does anyone have an idea what is the easiest way to do this?

If you need better precision than NTP gives, you should take a look at PTP ( http://www.nist.gov/el/isd/ieee/ieee1588.cfm ).
For extremally high precision (sub ns) there is White Rabbit ( https://www.ohwr.org/projects/white-rabbit/wiki/synchronization ).

HTH & Regards,
Wojtek

[toc] | [prev] | [next] | [standalone]

#28026

On Sunday, September 16, 2018 at 4:00:57 AM UTC+12, wza...@gmail.com wrote:
> gp....@gmail.com wrote:
> > We need to synchronize clocks (so we can synchronize audio) on physically separated controllers that are connected via ethernet that may or may not be connected to the internet.  The controllers have ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more than 50 ms difference but preferably less.  Synchronization needs to continue working between any two controllers regardless of the failure of any other controller.
> > 
> > Does anyone have an idea what is the easiest way to do this?
> 
> If you need better precision than NTP gives, you should take a look at PTP ( http://www.nist.gov/el/isd/ieee/ieee1588.cfm ).
> For extremally high precision (sub ns) there is White Rabbit ( https://www.ohwr.org/projects/white-rabbit/wiki/synchronization ).
> 
> HTH & Regards,
> Wojtek

Thanks, I did eventually discover PTP.  The hardware timestamping appeals to me but PTP is apparently harder to set up and you need routers and switches that support it.  I found an article that says this.
<quote>
In the case of PTP a slave synchronizes to a master clock, which other masters listen in, so that they can take over if the active master goes away for any reason. That’s good, but NTP does one better. The client gets time from all of the servers and ignore one which seems to be too far off in time compared to the other servers.  </>

https://blog.meinbergglobal.com/2013/11/22/ntp-vs-ptp-network-timing-smackdown/

I'm concerned that NTP is more for synchronizing "clock time" rather than audio but if it does what the above article says then it should be ok.

[toc] | [prev] | [next] | [standalone]

#28033

On Sat, 15 Sep 2018 15:08:11 -0700 (PDT), gp.kiwi@gmail.com wrote:


>Thanks, I did eventually discover PTP.  The hardware timestamping
>appeals to me but PTP is apparently harder to set up and you need
>routers and switches that support it. 

PTP doesn't need any special network hardware - it implemented over
UDP.

George

[toc] | [prev] | [next] | [standalone]

#28039

On Monday, September 17, 2018 at 12:49:25 AM UTC+12, George Neuner wrote:
> On Sat, 15 Sep 2018 15:08:11 -0700 (PDT), gp...@gmail.com wrote:
> 
> 
> >Thanks, I did eventually discover PTP.  The hardware timestamping
> >appeals to me but PTP is apparently harder to set up and you need
> >routers and switches that support it. 
> 
> PTP doesn't need any special network hardware - it implemented over
> UDP.
> 
> George

After googling for information it seems that some hardware does support hardware timestamping and there are implementations of both NTP and PTP that use it.
https://en.wikipedia.org/wiki/List_of_PTP_implementations

The main wikipedia article on PTP actually gives (almost) no indication that hardware timestamping gives better accuracy and claims that on a LAN, it can achieve sub-microsecond accuracy.  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.

[toc] | [prev] | [next] | [standalone]

#28040

On Mon, 17 Sep 2018 01:45:53 -0700 (PDT), gp.kiwi@gmail.com wrote:

>On Monday, September 17, 2018 at 12:49:25 AM UTC+12, George Neuner wrote:
>> On Sat, 15 Sep 2018 15:08:11 -0700 (PDT), gp...@gmail.com wrote:
>> 
>> 
>> >Thanks, I did eventually discover PTP.  The hardware timestamping
>> >appeals to me but PTP is apparently harder to set up and you need
>> >routers and switches that support it. 
>> 
>> PTP doesn't need any special network hardware - it implemented over
>> UDP.
>> 
>> George
>
>After googling for information it seems that some hardware does
>support hardware timestamping and there are implementations of both
>NTP and PTP that use it.
>https://en.wikipedia.org/wiki/List_of_PTP_implementations
>
>The main wikipedia article on PTP actually gives (almost) no
>indication that hardware timestamping gives better accuracy and
>claims that on a LAN, it can achieve sub-microsecond accuracy. 
>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.

You need enough protocol packets to get through (to every node) in a
timely manner to correct for the node's clock drift.  But what you
need depends on how good (or bad) is the clock.  You could need
several packets/second, or you might need just a few packets/minute,
depending ...

Obviously you need to start with high precision time source ... an
easy way to do it is to buy a network switch that has PTP built in.
But in a simple setup your time source could be just some node
designated to be the timekeeper.

You don't need routers/bridges to implement the protocol unless there
is significant congestion and lots of variance in packet time across
the network.  A few milliseconds here and there will be sorted out by
the protocol.

I think you said you needed +-20ms ... you didn't say how large or
complex the network, but if the cross section is under 10 milliseconds
(a pretty large wired net), you should be easily able to achieve your
desired resolution just with software PTP.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#28041

On Tuesday, September 18, 2018 at 3:30:50 AM UTC+12, George Neuner wrote:
> On Mon, 17 Sep 2018 01:45:53 -0700 (PDT), gp...@gmail.com wrote:
> 
> >On Monday, September 17, 2018 at 12:49:25 AM UTC+12, George Neuner wrote:
> >> On Sat, 15 Sep 2018 15:08:11 -0700 (PDT), gp...@gmail.com wrote:
> >> 
> >> 
> >> >Thanks, I did eventually discover PTP.  The hardware timestamping
> >> >appeals to me but PTP is apparently harder to set up and you need
> >> >routers and switches that support it. 
> >> 
> >> PTP doesn't need any special network hardware - it implemented over
> >> UDP.
> >> 
> >> George
> >
> >After googling for information it seems that some hardware does
> >support hardware timestamping and there are implementations of both
> >NTP and PTP that use it.
> >https://en.wikipedia.org/wiki/List_of_PTP_implementations
> >
> >The main wikipedia article on PTP actually gives (almost) no
> >indication that hardware timestamping gives better accuracy and
> >claims that on a LAN, it can achieve sub-microsecond accuracy. 
> >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.
> 
> You need enough protocol packets to get through (to every node) in a
> timely manner to correct for the node's clock drift.  But what you
> need depends on how good (or bad) is the clock.  You could need
> several packets/second, or you might need just a few packets/minute,
> depending ...
> 
> Obviously you need to start with high precision time source ... an
> easy way to do it is to buy a network switch that has PTP built in.
> But in a simple setup your time source could be just some node
> designated to be the timekeeper.
> 
> You don't need routers/bridges to implement the protocol unless there
> is significant congestion and lots of variance in packet time across
> the network.  A few milliseconds here and there will be sorted out by
> the protocol.
> 
> I think you said you needed +-20ms ... you didn't say how large or
> complex the network, but if the cross section is under 10 milliseconds
> (a pretty large wired net), you should be easily able to achieve your
> desired resolution just with software PTP.
> 
> YMMV,
> George

Thanks.  It's for synching audio so +-20ms is ok.  There can be up to 64 nodes.  We can assume a dedicated network but we may have some VOIP traffic with up to six people on a phone conference call.  We were intending to use NTP in hierarchical mode because it seems easier to configure.  We need the synch to keep working if there's a break in the network or a node is offline.

[toc] | [prev] | [next] | [standalone]

#28042

On Mon, 17 Sep 2018 15:04:58 -0700 (PDT), gp.kiwi@gmail.com wrote:

>On Tuesday, September 18, 2018 at 3:30:50 AM UTC+12, George Neuner wrote:
>>
>> I think you said you needed +-20ms ... you didn't say how large or
>> complex the network, but if the cross section is under 10 milliseconds
>> (a pretty large wired net), you should be easily able to achieve your
>> desired resolution just with software PTP.
>
>Thanks.  It's for synching audio so +-20ms is ok.  There can be up to
>64 nodes.  We can assume a dedicated network but we may have some
>VOIP traffic with up to six people on a phone conference call.  We
>were intending to use NTP in hierarchical mode because it seems
>easier to configure.  We need the synch to keep working if there's a
>break in the network or a node is offline.

Are these nodes some kind of networkable speakers?

+-20ms is no good for audio.  Ears are a lot more sensitive to
syncronization artifacts than are eyes.  Even "tin" ears will perceive
some artifacts at +-20ms.  Depending on content [e.g., people tolerate
hiccups in voice better than in music] stereo streams need to be
sync'd within +-8ms to be acceptible to most people. Under optimal
listening conditions, audiophiles with really good ears can hear sync
artifacts even down to +-3ms.

That said, 64 nodes is not all that many - cable lengths permitting
they all could be on one switch.  Even with a handful of switches, the
cross section of the LAN should be < ~3ms.  Unless you have a
congested network or serious drift problems with your nodes, NTP can
be about as accurate as the network cross section.

Software PTP can do better than NTP - if you can afford the protocol
traffic it can get down to the accuracy of the timekeeper clock.  But
if you want reliable sub-millisecond synchronization with minimum
traffic then you are going to need PTP hardware.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#28048

On Tuesday, September 18, 2018 at 2:11:06 PM UTC+12, George Neuner wrote:
> On Mon, 17 Sep 2018 15:04:58 -0700 (PDT), gp....@gmail.com wrote:
> 
> >On Tuesday, September 18, 2018 at 3:30:50 AM UTC+12, George Neuner wrote:
> >>
> >> I think you said you needed +-20ms ... you didn't say how large or
> >> complex the network, but if the cross section is under 10 milliseconds
> >> (a pretty large wired net), you should be easily able to achieve your
> >> desired resolution just with software PTP.
> >
> >Thanks.  It's for synching audio so +-20ms is ok.  There can be up to
> >64 nodes.  We can assume a dedicated network but we may have some
> >VOIP traffic with up to six people on a phone conference call.  We
> >were intending to use NTP in hierarchical mode because it seems
> >easier to configure.  We need the synch to keep working if there's a
> >break in the network or a node is offline.
> 
> Are these nodes some kind of networkable speakers?
> 
> +-20ms is no good for audio.  Ears are a lot more sensitive to
> syncronization artifacts than are eyes.  Even "tin" ears will perceive
> some artifacts at +-20ms.  Depending on content [e.g., people tolerate
> hiccups in voice better than in music] stereo streams need to be
> sync'd within +-8ms to be acceptible to most people. Under optimal
> listening conditions, audiophiles with really good ears can hear sync
> artifacts even down to +-3ms.
> 
> That said, 64 nodes is not all that many - cable lengths permitting
> they all could be on one switch.  Even with a handful of switches, the
> cross section of the LAN should be < ~3ms.  Unless you have a
> congested network or serious drift problems with your nodes, NTP can
> be about as accurate as the network cross section.
> 
> Software PTP can do better than NTP - if you can afford the protocol
> traffic it can get down to the accuracy of the timekeeper clock.  But
> if you want reliable sub-millisecond synchronization with minimum
> traffic then you are going to need PTP hardware.
> 
> YMMV,
> George

Yes, it's a network of speakers.  It sounds like NTP should be ok then.  We're likely to use a hierarchical arrangement.  Do you know if there's any way to use either PTP or NTP without configuring lots of static IP addresses at every node.

[toc] | [prev] | [next] | [standalone]

#28049

On 2018-09-18, graeme.prentice@gmail.com <graeme.prentice@gmail.com> wrote:
>
> Yes, it's a network of speakers.  It sounds like NTP should be ok then.  We're likely to use a hierarchical arrangement.  Do you know if there's any way to use either PTP or NTP without configuring lots of static IP addresses at every node.

You should only need one, or a handful for redundancy.  It's been
a while since I configured NTP from scratch but seem to remember
there are a couple of ways it can be configured - either peer to
peer where it averages out clock differences or client/server where
the clients follow the server clock.  In the latter case only the
server(s) need a static IP address.  

That is essentially the way I have configured it in the past -
clients follow the server which itself gets the time from the
Internet.  I figure that way the local clocks are synced with each
relatively well (without the vagaries of the Internet link) and
are in reasonable sync with the real world time.

-- 
Andrew Smallshaw
andrews@sdf.org

[toc] | [prev] | [next] | [standalone]

#28050

graeme.prentice@gmail.com writes:

> Yes, it's a network of speakers.  It sounds like NTP should be ok
> then.  We're likely to use a hierarchical arrangement.  Do you know if
> there's any way to use either PTP or NTP without configuring lots of
> static IP addresses at every node.

If you're running DHCP, use DHCP option 42 to send addresses of NTP
servers to the nodes.

--
mikko

[toc] | [prev] | [next] | [standalone]

#28084

On Tue, 18 Sep 2018 04:23:37 -0700 (PDT), graeme.prentice@gmail.com
wrote:

>On Tuesday, September 18, 2018 at 2:11:06 PM UTC+12, George Neuner wrote:
>> On Mon, 17 Sep 2018 15:04:58 -0700 (PDT), gp....@gmail.com wrote:
>> 
>> >On Tuesday, September 18, 2018 at 3:30:50 AM UTC+12, George Neuner wrote:
>> >>
>> >> I think you said you needed +-20ms ... you didn't say how large or
>> >> complex the network, but if the cross section is under 10 milliseconds
>> >> (a pretty large wired net), you should be easily able to achieve your
>> >> desired resolution just with software PTP.
>> >
>> >Thanks.  It's for synching audio so +-20ms is ok.  There can be up to
>> >64 nodes.  We can assume a dedicated network but we may have some
>> >VOIP traffic with up to six people on a phone conference call.  We
>> >were intending to use NTP in hierarchical mode because it seems
>> >easier to configure.  We need the synch to keep working if there's a
>> >break in the network or a node is offline.
>> 
>> Are these nodes some kind of networkable speakers?
>> 
>> +-20ms is no good for audio.  Ears are a lot more sensitive to
>> syncronization artifacts than are eyes.  Even "tin" ears will perceive
>> some artifacts at +-20ms.  Depending on content [e.g., people tolerate
>> hiccups in voice better than in music] stereo streams need to be
>> sync'd within +-8ms to be acceptible to most people. Under optimal
>> listening conditions, audiophiles with really good ears can hear sync
>> artifacts even down to +-3ms.

At the speed of sound, that is a location variation of +/- 1 m.

Should be easy with NTP on a local network. I have often measured less
than 1 ms transaction times with half duplex protocols on a 100baseT
switch. At least the full NTP  should have no problems maintaining
submillisecond accuracy, possibly also SNTP (Simple-NTP)
implementations. 

You have a high speed but (slowly drifting) local oscillator (such as
the Time Stamp Counter TSC  in x86 or even the 48/96/192 kHz sample
clock). For each NTP transaction, compare the received time at the
local clock time. Due to variable network delays, there will be some
jitter in the received times. compared to  local clock. Some NTP
samples are early and some late compared to the local clock. When
there are about equal number of early as well as late samples, the
local clock is at correct time and frequency. If there is a early or
late bias between samples, adjust local clock so that there is equal
amount of early and late samples. Low pass filtering the clock
differences and sooner or later, you a very good local clock accuracy.

For a microphone network, the local clocks should be within a sample
clock period i.e. 20, 10 or 5 us.

>> 
>> That said, 64 nodes is not all that many - cable lengths permitting
>> they all could be on one switch.  Even with a handful of switches, the
>> cross section of the LAN should be < ~3ms.  Unless you have a
>> congested network or serious drift problems with your nodes, NTP can
>> be about as accurate as the network cross section.
>> 
>> Software PTP can do better than NTP - if you can afford the protocol
>> traffic it can get down to the accuracy of the timekeeper clock.  But
>> if you want reliable sub-millisecond synchronization with minimum
>> traffic then you are going to need PTP hardware.
>> 
>> YMMV,
>> George
>
>Yes, it's a network of speakers.  It sounds like NTP should be ok then.  We're likely to use a hierarchical arrangement.  Do you know if there's any way to use either PTP or NTP without configuring lots of static IP addresses at every node.

OK, so it is a speaker network, so no need for sample clock
synchronization, since the sound data i self clocked. Thus a
millisecond accuracy is more than sufficient.

[toc] | [prev] | [next] | [standalone]

#28047 — Re: clock synchronization over IP

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.

[toc] | [prev] | [next] | [standalone]

#28064

On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
> We need to synchronize clocks (so we can synchronize audio) on physically separated controllers that are connected via ethernet that may or may not be connected to the internet.  The controllers have ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more than 50 ms difference but preferably less.  Synchronization needs to continue working between any two controllers regardless of the failure of any other controller.
>
> Does anyone have an idea what is the easiest way to do this?

Read all the replies about ntp etc, but perhaps
look at this another way ?. Rather than each client
*requesting* time, how about a server / node
broadcasting time to the net, with each client
locking on to that ?. Not sure if there are any
standards for it, but may be be worth having
a look.

That would get rid of any client / server request
delays altogether, with sync offsets determined
entirely by the client software, probably down
to microseconds...

Chris

[toc] | [prev] | [next] | [standalone]

#28065

On 21.9.2018 г. 17:00, Chris wrote:
> On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
>> We need to synchronize clocks (so we can synchronize audio) on
>> physically separated controllers that are connected via ethernet that
>> may or may not be connected to the internet.  The controllers have
>> ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more
>> than 50 ms difference but preferably less.  Synchronization needs to
>> continue working between any two controllers regardless of the failure
>> of any other controller.
>>
>> Does anyone have an idea what is the easiest way to do this?
>
> Read all the replies about ntp etc, but perhaps
> look at this another way ?. Rather than each client
> *requesting* time, how about a server / node
> broadcasting time to the net, with each client
> locking on to that ?. Not sure if there are any
> standards for it, but may be be worth having
> a look.
>
> That would get rid of any client / server request
> delays altogether, with sync offsets determined
> entirely by the client software, probably down
> to microseconds...
>
> Chris
>

I think the idea is excellent. Broadcast a packet - on the same
Ethernet branch (as is the case of the OP I think) there will be
no skew to talk about; then have all recipients confirm to the
server they got the time, and once the server receives all confirmations
from all active hosts (it will need to know which these are) it safely
(via tcp) tells each host the broadcast time it got is now universally
valid.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#28066

On Fri, 21 Sep 2018 17:12:00 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 21.9.2018 ?. 17:00, Chris wrote:
>> On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
>>> We need to synchronize clocks (so we can synchronize audio) on
>>> physically separated controllers that are connected via ethernet that
>>> may or may not be connected to the internet.  The controllers have
>>> ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more
>>> than 50 ms difference but preferably less.  Synchronization needs to
>>> continue working between any two controllers regardless of the failure
>>> of any other controller.
>>>
>>> Does anyone have an idea what is the easiest way to do this?
>>
>> Read all the replies about ntp etc, but perhaps
>> look at this another way ?. Rather than each client
>> *requesting* time, how about a server / node
>> broadcasting time to the net, with each client
>> locking on to that ?. Not sure if there are any
>> standards for it, but may be be worth having
>> a look.
>>
>> That would get rid of any client / server request
>> delays altogether, with sync offsets determined
>> entirely by the client software, probably down
>> to microseconds...
>>
>> Chris
>>
>
>I think the idea is excellent. Broadcast a packet - on the same
>Ethernet branch (as is the case of the OP I think) there will be
>no skew to talk about; then have all recipients confirm to the
>server they got the time, and once the server receives all confirmations
>from all active hosts (it will need to know which these are) it safely
>(via tcp) tells each host the broadcast time it got is now universally
>valid.


Unless you're using one of the shared media versions of Ethernet,
which is somewhat unlikely these days, although not impossible, or if
your "switch" is really a hub (aka a repeater), also unlikely, except
in really inexpensive gear, there's no guarantee that the switch isn't
going to introduce variable latency in forwarding broadcast frames to
the various ports.  In fact the switch will have to introduce skew if
on of the ports has queued transmission traffic, and the others don't,
or if the ports are not all running at the same speed.

Slew can be introduced at the receiving nodes as well based on how
likely they have any queued receive traffic, either in the NIC or in
OS buffers.  A question would be how close to the wire the received
frame can be timestamped.

That might also leave all the nodes, except the time server,
synchronized, unless the time server can also receive the broadcast,
which is not a universal capability (the sending node often cannot).
That's not an issue if the time server node doesn't need to be
synchronized with the other nodes, but I'd generally assume that being
the time server was just a function of one of the nodes doing "normal"
work.

So there's a lot to be said for an interactive approach.

[toc] | [prev] | [next] | [standalone]

#28069

On 09/21/18 15:58, Robert Wessel wrote:
> On Fri, 21 Sep 2018 17:12:00 +0300, Dimiter_Popoff<dp@tgi-sci.com>
> wrote:
>
>> On 21.9.2018 ?. 17:00, Chris wrote:
>>> On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
>>>> We need to synchronize clocks (so we can synchronize audio) on
>>>> physically separated controllers that are connected via ethernet that
>>>> may or may not be connected to the internet.  The controllers have
>>>> ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more
>>>> than 50 ms difference but preferably less.  Synchronization needs to
>>>> continue working between any two controllers regardless of the failure
>>>> of any other controller.
>>>>
>>>> Does anyone have an idea what is the easiest way to do this?
>>>
>>> Read all the replies about ntp etc, but perhaps
>>> look at this another way ?. Rather than each client
>>> *requesting* time, how about a server / node
>>> broadcasting time to the net, with each client
>>> locking on to that ?. Not sure if there are any
>>> standards for it, but may be be worth having
>>> a look.
>>>
>>> That would get rid of any client / server request
>>> delays altogether, with sync offsets determined
>>> entirely by the client software, probably down
>>> to microseconds...
>>>
>>> Chris
>>>
>>
>> I think the idea is excellent. Broadcast a packet - on the same
>> Ethernet branch (as is the case of the OP I think) there will be
>> no skew to talk about; then have all recipients confirm to the
>> server they got the time, and once the server receives all confirmations
>>from all active hosts (it will need to know which these are) it safely
>> (via tcp) tells each host the broadcast time it got is now universally
>> valid.
>
>
> Unless you're using one of the shared media versions of Ethernet,
> which is somewhat unlikely these days, although not impossible, or if
> your "switch" is really a hub (aka a repeater), also unlikely, except
> in really inexpensive gear, there's no guarantee that the switch isn't
> going to introduce variable latency in forwarding broadcast frames to
> the various ports.  In fact the switch will have to introduce skew if
> on of the ports has queued transmission traffic, and the others don't,
> or if the ports are not all running at the same speed.
>
> Slew can be introduced at the receiving nodes as well based on how
> likely they have any queued receive traffic, either in the NIC or in
> OS buffers.  A question would be how close to the wire the received
> frame can be timestamped.
>
> That might also leave all the nodes, except the time server,
> synchronized, unless the time server can also receive the broadcast,
> which is not a universal capability (the sending node often cannot).
> That's not an issue if the time server node doesn't need to be
> synchronized with the other nodes, but I'd generally assume that being
> the time server was just a function of one of the nodes doing "normal"
> work.
>
> So there's a lot to be said for an interactive approach.

Agreed, but the spec is to synchronise audio, which is a hard real time
requirement. You might have to consider other issues as well, such as
embedded Linux real time response time. That said, if you have control
over the network topology, you can specify which switches and hubs
are permissable and design around that. Lowest cost that meets the
spec is usually the aim and the simplest protocol that gets the job
done can also minimise latency and hardware requirements :-)...

Chris

[toc] | [prev] | [next] | [standalone]

#28067

On 09/21/18 15:12, Dimiter_Popoff wrote:
> On 21.9.2018 г. 17:00, Chris wrote:
>> On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
>>> We need to synchronize clocks (so we can synchronize audio) on
>>> physically separated controllers that are connected via ethernet that
>>> may or may not be connected to the internet. The controllers have
>>> ARM9 LPC3250 SOM and embedded Linux. We need to synch with no more
>>> than 50 ms difference but preferably less. Synchronization needs to
>>> continue working between any two controllers regardless of the failure
>>> of any other controller.
>>>
>>> Does anyone have an idea what is the easiest way to do this?
>>
>> Read all the replies about ntp etc, but perhaps
>> look at this another way ?. Rather than each client
>> *requesting* time, how about a server / node
>> broadcasting time to the net, with each client
>> locking on to that ?. Not sure if there are any
>> standards for it, but may be be worth having
>> a look.
>>
>> That would get rid of any client / server request
>> delays altogether, with sync offsets determined
>> entirely by the client software, probably down
>> to microseconds...
>>
>> Chris
>>
>
> I think the idea is excellent. Broadcast a packet - on the same
> Ethernet branch (as is the case of the OP I think) there will be
> no skew to talk about; then have all recipients confirm to the
> server they got the time, and once the server receives all confirmations
> from all active hosts (it will need to know which these are) it safely
> (via tcp) tells each host the broadcast time it got is now universally
> valid.
>
> Dimiter
>
> ======================================================
> Dimiter Popoff, TGI http://www.tgi-sci.com
> ======================================================
> http://www.flickr.com/photos/didi_tgi/
>
>
>

If you wanted to use really low level, you might be able to
(mis) use an existing protocol like a rarp b/cast, to get the
job done, depending on network requirements. Had a quick
search and there are other methods, some described here:

http://tinyos.stanford.edu/tinyos-wiki/index.php/FTSP

You can also buy gps rx engines / boards really cheaply now and
most of those have a 1 pps o/p at ttl level, as well as time
of day via serial port. Antenna could be the sticking point
there though.

Just seems to me that ntp is too high level, with not
enough granularity for audio synchronisation...

Chris

[toc] | [prev] | [next] | [standalone]

#28070

On Fri, 21 Sep 2018 15:00:51 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk>
wrote:

>On 08/25/18 01:54, gp.kiwi@gmail.com wrote:
>>We need to synchronize clocks (so we can synchronize audio) on
>>physically separated controllers that are connected via ethernet that
>>may or may not be connected to the internet.  The controllers have
>>ARM9 LPC3250 SOM and embedded Linux.  We need to synch with no more
>>than 50 ms difference but preferably less.  Synchronization needs to
>>continue working between any two controllers regardless of the
>>failure of any other controller.
>>
>>Does anyone have an idea what is the easiest way to do this?
>
>Read all the replies about ntp etc, but perhaps
>look at this another way ?. Rather than each client
>*requesting* time, how about a server / node
>broadcasting time to the net, with each client
>locking on to that ?. Not sure if there are any
>standards for it, but may be be worth having
>a look.
>
>That would get rid of any client / server request
>delays altogether, with sync offsets determined
>entirely by the client software, probably down
>to microseconds...

There will be slew along the any cable and through any repeater - so
it is impossible to avoid altogether.  On a common cable, nodes nearer
the broadcast point receive it sooner than those further away. Twisted
pair is a (multi)star configuration centered around a switch or hub
which is has a repeater per port.

Moreover, simply broadcasting the time from a master won't work[*] ...
in order to synchronize the clocks youu need to know for each node (to
a good approximation) the time it takes for the network to deliver the
time packet.

[*] except in a dedicated setup like a DGPS timing network.  The
problem with such setups is that all the connections from the master
to the slaves need to be exactly the same length (bit delay). That is
very hard to achieve in most installations.

George

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web