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.
Reply by Chris●September 22, 20182018-09-22
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
> 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.
Reply by Mikko OH2HVJ●September 22, 20182018-09-22
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
Reply by ●September 22, 20182018-09-22
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.
Reply by ●September 22, 20182018-09-22
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.
Reply by ●September 22, 20182018-09-22
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.
Reply by ●September 22, 20182018-09-22
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.
Reply by Chris●September 22, 20182018-09-22
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
Reply by Chris●September 22, 20182018-09-22
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