clock synchronization over IP

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?

Reply to
graeme.prentice
Loading thread data ...

If NTP "favours" a packet with the shortest round trip time then that should work fairly well.

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.

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

Reply to
Chris

d the level of expertise here.

xa switch because we need redundant paths.

TP packet arrives somewhere, is the NTP

running MQX that is on the same board.

It's not rude. I was wondering if someone would say that. We do have a ki nd 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 st upid in the hope of learning something. e.g. someone mentioned that NTP fa vours a packet with the shortest round trip time. I suspect I could read f or an hour or more about NTP and not discover that. Also, nothing I've rea d 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 m ore specific about it. The extra micro is to take some of the work-load an d real-time stuff off the Linux micro.

Reply to
gp.kiwi

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

Reply to
George Neuner

d the level of expertise here.

xa switch because we need redundant paths.

TP packet arrives somewhere, is the NTP

running MQX that is on the same board.

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 fo rget 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 tim e. Same with the internal ethernet links. We can also manage the failure of a clock master ourselves instead of configuring multiple NTP clock maste rs.

Reply to
graeme.prentice

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.

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.

Reply to
upsidedown

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.

Reply to
upsidedown

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

Reply to
Chris

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

formatting link

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 to
Chris

ly separated controllers that are connected via ethernet that may or may no t 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 pr eferably less. Synchronization needs to continue working between any two c ontrollers regardless of the failure of any other controller.

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

Rick C.

Reply to
gnuarm.deletethisbit

and the level of expertise here.

Moxa switch because we need redundant paths.

NTP packet arrives somewhere, is the NTP

o running MQX that is on the same board.

e
.

kind of IP expert whose opinion is that NTP will be fine. I find I can lea rn 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 r ead gives me any clue about how an NTP packet is processed and how it avoid s queueing delays at each end.

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 sig nal 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 s ignal... 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 loc ked to the buffer size so we have the same rate clocks at each end as contr olled by the packet buffer. This gives us the same readout rate as the rat e of sampling the signal on the input (which is synchronized to the 1 kHz c arrier). I think my customer applied for a patent on the details of how th ey 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 to
gnuarm.deletethisbit

lly separated controllers that are connected via ethernet that may or may n ot 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 p referably less. Synchronization needs to continue working between any two controllers regardless of the failure of any other controller.

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

For various values of "expensive". What sort of device are you talking abo ut 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 on to 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 po rt 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 to
gnuarm.deletethisbit

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.

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

Reply to
upsidedown

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 to
Mikko OH2HVJ

NTP includes calculations for round trip time.

formatting link

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 to
Brett

That looks interesting, article here from Wiki:

formatting link

and a list of implementations here:

formatting link

including open source and a Linux version.

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

Chris

Reply to
Chris

ically separated controllers that are connected via ethernet that may or ma y 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 bu t preferably less. Synchronization needs to continue working between any t wo controllers regardless of the failure of any other controller.

esigned to do, convey IRIG-B. This is used over a non-dedicated network us ing NTP.

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 d edicated 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 b ecause it enables them to bid on contracts that include the functionality. The actual product line (and I mean the entire circuit to packet product l ine, not just IRIG) makes good profit, but not enough to keep anyone's atte ntion 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 to
gnuarm.deletethisbit

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.