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 2 of 2 — ← Prev page 1 [2]

#28071

On 09/21/18 22:15, George Neuner wrote:

> 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


There is cable delay, but that's in the order a few nS per foot at most,
where the requirement here is in mS, so that can probably be ignored.
As for the switch or hub delay, that could be modelled or even subject
to testing to find suitable products.

Ideally, I would use gps to sync, as it has all the outputs required to
within a few nS over a wide area, but you need a clear view of the sky
to make that work.

Still think it would be worth looking at broadcast methods, as it could
be made low cost at client and server ends, could be run on modest h/w
without use of an OS, even without a full tcp/ip stack and is probably
good enough for the application...

Chris

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

#28073

On Saturday, September 22, 2018 at 9:35:45 AM UTC+12, Chris wrote:
> On 09/21/18 22:15, George Neuner wrote:
> 
> > 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
> 
> 
> There is cable delay, but that's in the order a few nS per foot at most,
> where the requirement here is in mS, so that can probably be ignored.
> As for the switch or hub delay, that could be modelled or even subject
> to testing to find suitable products.
> 
> Ideally, I would use gps to sync, as it has all the outputs required to
> within a few nS over a wide area, but you need a clear view of the sky
> to make that work.
> 
> Still think it would be worth looking at broadcast methods, as it could
> be made low cost at client and server ends, could be run on modest h/w
> without use of an OS, even without a full tcp/ip stack and is probably
> good enough for the application...
> 
> Chris

Thanks for all the replies.  I really appreciate all the suggestions and the level of expertise here.  

The software is running on embedded Linux and every node will have a Moxa switch because we need redundant paths.  If NTP "favours" a packet with the shortest round trip time then that should work fairly well.  

The micro is an ARM9 LPC3250. I'm curious to know something.  When an NTP packet arrives somewhere, is the NTP processing and response all done in the ethernet chip without the need for the operating system to switch threads to process the message.

We also need to synchronize time between the ARM micro and a K64 micro running MQX that is on the same board.  The ARM micro will be the master.  Any ideas for the best way to get the synch time from the ARM to the K64?

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

#28076

On 09/21/18 23:16, gp.kiwi@gmail.com wrote:

>
> Thanks for all the replies.  I really appreciate all the suggestions and the level of expertise here.
>
> The software is running on embedded Linux and every node will have a Moxa switch because we need redundant paths.

If NTP "favours" a packet with the shortest round trip time then that 
should work fairly well.
>
> The micro is an ARM9 LPC3250. I'm curious to know something.  When an NTP packet arrives somewhere, is the NTP

processing and response all done in the ethernet chip without the need 
for the operating system to switch

threads to process the message.

Don't want to appear rude, but if you have to ask questions like that,
perhaps you need some engineers on the project who know what they are
doing ?. But yes, multiple levels of the stack may have to be traversed
to get the ntp stuff processed, including the ntp client daemon. Also, 
embedded Linux may or may not be suitable, as it was never
designed for hard real time work of that type and may have significant
latency, though there may be versions optimised in some way.

>
> We also need to synchronize time between the ARM micro and a K64 micro running MQX that is on the same board.

The ARM micro will be the master.  Any ideas for the best way to get the 
synch time from the ARM to the K64?
>

Sounds really complex, so what is this project trying to do overall ?...

Chris

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

#28077

On Saturday, September 22, 2018 at 11:11:44 AM UTC+12, Chris wrote:
> On 09/21/18 23:16, gp....@gmail.com wrote:
> 
> >
> > Thanks for all the replies.  I really appreciate all the suggestions and the level of expertise here.
> >
> > The software is running on embedded Linux and every node will have a Moxa switch because we need redundant paths.
> 
> If NTP "favours" a packet with the shortest round trip time then that 
> should work fairly well.
> >
> > The micro is an ARM9 LPC3250. I'm curious to know something.  When an NTP packet arrives somewhere, is the NTP
> 
> processing and response all done in the ethernet chip without the need 
> for the operating system to switch
> 
> threads to process the message.
> 
> Don't want to appear rude, but if you have to ask questions like that,
> perhaps you need some engineers on the project who know what they are
> doing ?. But yes, multiple levels of the stack may have to be traversed
> to get the ntp stuff processed, including the ntp client daemon. Also, 
> embedded Linux may or may not be suitable, as it was never
> designed for hard real time work of that type and may have significant
> latency, though there may be versions optimised in some way.
> 
> >
> > We also need to synchronize time between the ARM micro and a K64 micro running MQX that is on the same board.
> 
> The ARM micro will be the master.  Any ideas for the best way to get the 
> synch time from the ARM to the K64?
> >
> 
> Sounds really complex, so what is this project trying to do overall ?...
> 
> Chris

It's not rude.  I was wondering if someone would say that.  We do have a kind of IP expert whose opinion is that NTP will be fine.  I find I can learn a lot by just asking questions so I take the risk of making myself look stupid in the hope of learning something.  e.g. someone mentioned that NTP favours a packet with the shortest round trip time.  I suspect I could read for an hour or more about NTP and not discover that.  Also, nothing I've read gives me any clue about how an NTP packet is processed and how it avoids queueing delays at each end.

The project isn't really especially complex.  I can't really say anything more specific about it.  The extra micro is to take some of the work-load and real-time stuff off the Linux micro.

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

#28090

On 09/22/18 00:35, gp.kiwi wrote:

>
> It's not rude.  I was wondering if someone would say that.  We do have a kind of IP expert whose opinion is that NTP will be fine.  I find I can learn a lot by just asking questions so I take the risk of making myself look stupid in the hope of learning something.  e.g. someone mentioned that NTP favours a packet with the shortest round trip time.  I suspect I could read for an hour or more about NTP and not discover that.  Also, nothing I've read gives me any clue about how an NTP packet is processed and how it avoids queueing delays at each end.
>
> The project isn't really especially complex.  I can't really say anything more specific about it.  The extra micro is to take some of the work-load and real-time stuff off the Linux micro.

It was  a bit off the cuff, but seems to me such a project needs a
more thorough analysis of requirements in terms of latency. Then,
identify all the components in the data path and work out worst
case for them all to see if the spec can be met. If not, add / swap
stuff around until it can. ntp may be a hammer, but not everything is
a nail, right ?.

I prefer lightweight solutions, keep things simple as possible to
reduce development time, cost and ongoing maintenance. The latter
being significant if the design is right on the edge, or if there's
been not enough analysis up front.

Anyway, suggest have a look again at the FTSP page

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

which looks like it might be ideal for the mS latency
requirements you have. Never used it, but such timing
specs  must a be a very common thing across industry
and there must be laods of solutions out there, so suggest
cast the net a bit wider...

Chris

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

#28092

On Friday, September 21, 2018 at 7:35:56 PM UTC-4, gp.kiwi wrote:
> On Saturday, September 22, 2018 at 11:11:44 AM UTC+12, Chris wrote:
> > On 09/21/18 23:16, gp....@gmail.com wrote:
> > 
> > >
> > > Thanks for all the replies.  I really appreciate all the suggestions and the level of expertise here.
> > >
> > > The software is running on embedded Linux and every node will have a Moxa switch because we need redundant paths.
> > 
> > If NTP "favours" a packet with the shortest round trip time then that 
> > should work fairly well.
> > >
> > > The micro is an ARM9 LPC3250. I'm curious to know something.  When an NTP packet arrives somewhere, is the NTP
> > 
> > processing and response all done in the ethernet chip without the need 
> > for the operating system to switch
> > 
> > threads to process the message.
> > 
> > Don't want to appear rude, but if you have to ask questions like that,
> > perhaps you need some engineers on the project who know what they are
> > doing ?. But yes, multiple levels of the stack may have to be traversed
> > to get the ntp stuff processed, including the ntp client daemon. Also, 
> > embedded Linux may or may not be suitable, as it was never
> > designed for hard real time work of that type and may have significant
> > latency, though there may be versions optimised in some way.
> > 
> > >
> > > We also need to synchronize time between the ARM micro and a K64 micro running MQX that is on the same board.
> > 
> > The ARM micro will be the master.  Any ideas for the best way to get the 
> > synch time from the ARM to the K64?
> > >
> > 
> > Sounds really complex, so what is this project trying to do overall ?...
> > 
> > Chris
> 
> It's not rude.  I was wondering if someone would say that.  We do have a kind of IP expert whose opinion is that NTP will be fine.  I find I can learn a lot by just asking questions so I take the risk of making myself look stupid in the hope of learning something.  e.g. someone mentioned that NTP favours a packet with the shortest round trip time.  I suspect I could read for an hour or more about NTP and not discover that.  Also, nothing I've read gives me any clue about how an NTP packet is processed and how it avoids queueing delays at each end.
> 
> The project isn't really especially complex.  I can't really say anything more specific about it.  The extra micro is to take some of the work-load and real-time stuff off the Linux micro.

I built a board for a major networking company that conveys a time code signal onto their network and reconstructs it at the other end.  When we were designing this board I kept asking how they would define the "now" of the signal... that is, how do they deal with the "unknown" network delays?  NTP was the answer.  I never got any more clarity than that.  

In the rest of the system they designed are buffers and a clock that is locked to the buffer size so we have the same rate clocks at each end as controlled by the packet buffer.  This gives us the same readout rate as the rate of sampling the signal on the input (which is synchronized to the 1 kHz carrier).  I think my customer applied for a patent on the details of how they do that.  

Then the first use for one of these units was to control a wall clock... at a missile command center.  lol  

Rick C.

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

#28081

On Saturday, September 22, 2018 at 11:11:44 AM UTC+12, Chris wrote:
> On 09/21/18 23:16, gp....@gmail.com wrote:
> 
> >
> > Thanks for all the replies.  I really appreciate all the suggestions and the level of expertise here.
> >
> > The software is running on embedded Linux and every node will have a Moxa switch because we need redundant paths.
> 
> If NTP "favours" a packet with the shortest round trip time then that 
> should work fairly well.
> >
> > The micro is an ARM9 LPC3250. I'm curious to know something.  When an NTP packet arrives somewhere, is the NTP
> 
> processing and response all done in the ethernet chip without the need 
> for the operating system to switch
> 
> threads to process the message.
> 
> Don't want to appear rude, but if you have to ask questions like that,
> perhaps you need some engineers on the project who know what they are
> doing ?. But yes, multiple levels of the stack may have to be traversed
> to get the ntp stuff processed, including the ntp client daemon. Also, 
> embedded Linux may or may not be suitable, as it was never
> designed for hard real time work of that type and may have significant
> latency, though there may be versions optimised in some way.
> 
> >
> > We also need to synchronize time between the ARM micro and a K64 micro running MQX that is on the same board.
> 
> The ARM micro will be the master.  Any ideas for the best way to get the 
> synch time from the ARM to the K64?
> >
> 
> Sounds really complex, so what is this project trying to do overall ?...
> 
> Chris

Also, if I knew the throughput of IP messages between any two nodes was an average of, say, at least 200 messages per second, I would be arguing to forget NTP because if the average round trip time is 5 milliseconds then all we have to do is keep sending a home-grown synch packet until it returns in under 5 milliseconds, then notify the far end to use that packet synch time.  Same with the internal ethernet links.  We can also manage the failure of a clock master ourselves instead of configuring multiple NTP clock masters.

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

#28080

On Fri, 21 Sep 2018 22:35:40 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk>
wrote:

>On 09/21/18 22:15, George Neuner wrote:
>
>> 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
>
>
>There is cable delay, but that's in the order a few nS per foot at most,
>where the requirement here is in mS, so that can probably be ignored.
>As for the switch or hub delay, that could be modelled or even subject
>to testing to find suitable products.

But the cable length can be up to 100m for twisted pair, 200m for thin
cable, and 500m for thick cable.  And up to 4 repeaters (5 cables) are
permitted between any pair of stations, provided the total CSMA/CD
collision sense time does not exceed the maximum allowed (which varies
by transmission speed).

Remember also that for twisted pair, switches establish new collision
domains for each switched port, but repeating hubs and L2 bridges do
not.  Even for twisted pair, you *still* can have up to 4 repeaters
between the central switch and any station.


And yes, there still are uses for non-switched repeater hubs.

George

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

#28089

On 09/22/18 03:17, George Neuner wrote:

> But the cable length can be up to 100m for twisted pair, 200m for thin
> cable, and 500m for thick cable.  And up to 4 repeaters (5 cables) are
> permitted between any pair of stations, provided the total CSMA/CD
> collision sense time does not exceed the maximum allowed (which varies
> by transmission speed).
>
> Remember also that for twisted pair, switches establish new collision
> domains for each switched port, but repeating hubs and L2 bridges do
> not.  Even for twisted pair, you *still* can have up to 4 repeaters
> between the central switch and any station.
>
>
> And yes, there still are uses for non-switched repeater hubs.
>
> George

That's the spec limits, but good design matches the solution to the
requirements, which should be conservative and not stretching
limits. Remember, this is engineering, not academia and you are
always working with the three conflicting goals: performance, cost and
reliability, pick any two :-)...

Chris

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

#28101 — Re: clock synchronization over IP

George Neuner <gneuner2@comcast.net> wrote:
> On Fri, 21 Sep 2018 22:35:40 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk>
> wrote:
> 
>> On 09/21/18 22:15, George Neuner wrote:
>> 
>>> 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
>> 
>> 
>> There is cable delay, but that's in the order a few nS per foot at most,
>> where the requirement here is in mS, so that can probably be ignored.
>> As for the switch or hub delay, that could be modelled or even subject
>> to testing to find suitable products.
> 
> But the cable length can be up to 100m for twisted pair, 200m for thin
> cable, and 500m for thick cable.  And up to 4 repeaters (5 cables) are
> permitted between any pair of stations, provided the total CSMA/CD
> collision sense time does not exceed the maximum allowed (which varies
> by transmission speed).
> 
> Remember also that for twisted pair, switches establish new collision
> domains for each switched port, but repeating hubs and L2 bridges do
> not.  Even for twisted pair, you *still* can have up to 4 repeaters
> between the central switch and any station.
> 
> 
> And yes, there still are uses for non-switched repeater hubs.

NTP includes calculations for round trip time.
https://en.m.wikipedia.org/wiki/Network_Time_Protocol

The only gotcha would be with load balanced alternate routes which can
happen at telecom connections, and I believe the packets specify a route to
get around that issue.

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

#28085

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.

The traditional method is to use some IRIG protocol variant. Of course
this requires a dedicated network, but standard CAT5 cabling and even
10baseT hubs might be usable.


Unfortunately IRIG devices can be quite expensive.

>
>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]

#28093

On Saturday, September 22, 2018 at 4:56:59 AM UTC-4, upsid...@downunder.com wrote:
> 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.
> 
> The traditional method is to use some IRIG protocol variant. Of course
> this requires a dedicated network, but standard CAT5 cabling and even
> 10baseT hubs might be usable.

Why a dedicated network?  That is exactly what my board was originally designed to do, convey IRIG-B.  This is used over a non-dedicated network using NTP. 


> Unfortunately IRIG devices can be quite expensive.

For various values of "expensive".  What sort of device are you talking about exactly?  My unit is no more expensive than a cell phone.  It's not the full IRIG to IP solution though.  By the time my customer plugs my units onto their boards and shoves their boards into their boxes, I'm told it does get rather expensive.  I think a less general solution providing an IRIG port and an IP port could be about the same cost as my unit alone, about the same as a cell phone in multiples of 100.  At higher volumes the cost could drop to $100. 

Rick C.

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

#28097

On Sat, 22 Sep 2018 07:31:51 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:

>On Saturday, September 22, 2018 at 4:56:59 AM UTC-4, upsid...@downunder.com wrote:
>> 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.
>> 
>> The traditional method is to use some IRIG protocol variant. Of course
>> this requires a dedicated network, but standard CAT5 cabling and even
>> 10baseT hubs might be usable.
>
>Why a dedicated network?  That is exactly what my board was originally designed to do, convey IRIG-B.  This is used over a non-dedicated network using NTP. 

I am talking about the traditional method of provide common timing
e.g. to a large industrial site by broadcasting timing over a wired
network using some of the IRIG variants.

I was *not* talking about some IRIG/NTP gateways or similar systems.

>
>
>> Unfortunately IRIG devices can be quite expensive.
>
>For various values of "expensive".  
>What sort of device are you talking about exactly?  

Typically rack mounted units which are at least 1U high and supporting
multiple IRIG variants.

>My unit is no more expensive than a cell phone. 
> It's not the full IRIG to IP solution though.  
>By the time my customer plugs my units onto their boards and shoves their boards into their boxes, I'm told it does get rather expensive.  I think a less general solution providing an IRIG port and an IP port could be about the same cost as my unit alone, about the same as a cell phone in multiples of 100.  At higher volumes the cost could drop to $100. 
>
>Rick C.

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

#28103

On Saturday, September 22, 2018 at 1:01:44 PM UTC-4, upsid...@downunder.com wrote:
> On Sat, 22 Sep 2018 07:31:51 -0700 (PDT),
> gnuarm.deletethisbit@gmail.com wrote:
> 
> >On Saturday, September 22, 2018 at 4:56:59 AM UTC-4, upsid...@downunder.com wrote:
> >> 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.
> >> 
> >> The traditional method is to use some IRIG protocol variant. Of course
> >> this requires a dedicated network, but standard CAT5 cabling and even
> >> 10baseT hubs might be usable.
> >
> >Why a dedicated network?  That is exactly what my board was originally designed to do, convey IRIG-B.  This is used over a non-dedicated network using NTP. 
> 
> I am talking about the traditional method of provide common timing
> e.g. to a large industrial site by broadcasting timing over a wired
> network using some of the IRIG variants.
> 
> I was *not* talking about some IRIG/NTP gateways or similar systems.
> 
> >
> >
> >> Unfortunately IRIG devices can be quite expensive.
> >
> >For various values of "expensive".  
> >What sort of device are you talking about exactly?  
> 
> Typically rack mounted units which are at least 1U high and supporting
> multiple IRIG variants.

The only reason why the stuff my board goes into is expensive is because it is general purpose and very configurable.  It would be easy to produce a dedicated product at the cell phone price.  I'm not talking about the fancy dancy, latest and greatest phones, I mean the $200-$300 range.  The company I sell my boards to actually isn't interested in that part of the market.  The sales people have to talk management into retaining the product line because it enables them to bid on contracts that include the functionality.  The actual product line (and I mean the entire circuit to packet product line, not just IRIG) makes good profit, but not enough to keep anyone's attention at the top levels of the company, so they keep evaluating whether to drop it. 

Lucky for me they haven't and likely won't.  It keeps me in Teslas. 

Rick C.

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

#28091

On Friday, September 21, 2018 at 10:00:55 AM UTC-4, 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...

ntp is a protocol.  The message routing times are compared to find the estimated delay times.  Without a round trip there is no way of doing this.  Otherwise you have to guess.  How do you expect the "client software" to do this? 

Rick C.

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

#28099

Chris <xxx.syseng.yyy@gfsys.co.uk> writes:


> 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.

Check IEEE1588-2008 PTP. The PTP master broadcasts the time in Sync and
Follow_Up messages up to 10 times per second. The slaves can then
request request for delay reply from the master, but that's not
required.

--
mikko

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

#28102

On 09/22/18 18:16, Mikko OH2HVJ wrote:
> Chris<xxx.syseng.yyy@gfsys.co.uk>  writes:
>
>
>> 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.
>
> Check IEEE1588-2008 PTP. The PTP master broadcasts the time in Sync and
> Follow_Up messages up to 10 times per second. The slaves can then
> request request for delay reply from the master, but that's not
> required.
>
> --
> mikko

That looks interesting, article here from Wiki:

https://en.wikipedia.org/wiki/Precision_Time_Protocol

and a list of implementations here:

https://en.wikipedia.org/wiki/List_of_PTP_implementations

including open source and a Linux version.

Wold be fun to build an evaluation net for this...

Chris

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web