clock synchronization over IP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Quoted text here. Click to load it

https://youtu.be/dRTplGUzw28?t13%m30s

Re: clock synchronization over IP
snipped-for-privacy@gmail.com writes:
Quoted text here. Click to load it

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

Re: clock synchronization over IP
snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it
 separated controllers that are connected via ethernet that may or may not  
be connected to the internet.  The controllers have ARM9 LPC3250 SOM and em
bedded Linux.  We need to synch with no more than 50 ms difference but pref
erably less.  Synchronization needs to continue working between any two con
trollers regardless of the failure of any other controller.
Quoted text here. Click to load it

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

Re: clock synchronization over IP
On Sunday, September 16, 2018 at 4:00:57 AM UTC+12, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
P ( http://www.nist.gov/el/isd/ieee/ieee1588.cfm ).
Quoted text here. Click to load it
w.ohwr.org/projects/white-rabbit/wiki/synchronization ).
Quoted text here. Click to load it

Thanks, I did eventually discover PTP.  The hardware timestamping appeals t
o me but PTP is apparently harder to set up and you need routers and switch
es 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 mast
ers listen in, so that they can take over if the active master goes away fo
r 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-smackd
own/

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

Re: clock synchronization over IP
On Sat, 15 Sep 2018 15:08:11 -0700 (PDT), snipped-for-privacy@gmail.com wrote:


Quoted text here. Click to load it

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

George

Re: clock synchronization over IP
On Monday, September 17, 2018 at 12:49:25 AM UTC+12, George Neuner wrote:
Quoted text here. Click to load it

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

The main wikipedia article on PTP actually gives (almost) no indication tha
t hardware timestamping gives better accuracy and claims that on a LAN, it  
can achieve sub-microsecond accuracy.  Without hardware support I suspect t
hat kind of accuracy requires a low traffic LAN, although it's possible tha
t it keeps trying until it achieves a really short round-trip time.


Re: clock synchronization over IP
On Mon, 17 Sep 2018 01:45:53 -0700 (PDT), snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it

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

Re: clock synchronization over IP
On Tuesday, September 18, 2018 at 3:30:50 AM UTC+12, George Neuner wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it

Thanks.  It's for synching audio so +-20ms is ok.  There can be up to 64 no
des.  We can assume a dedicated network but we may have some VOIP traffic w
ith 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 offli
ne.

Re: clock synchronization over IP
On Mon, 17 Sep 2018 15:04:58 -0700 (PDT), snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it

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

Re: clock synchronization over IP
On Tuesday, September 18, 2018 at 2:11:06 PM UTC+12, George Neuner wrote:
Quoted text here. Click to load it

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.

Re: clock synchronization over IP
Quoted text here. Click to load it

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
snipped-for-privacy@sdf.org

Re: clock synchronization over IP
snipped-for-privacy@gmail.com writes:

Quoted text here. Click to load it

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

--
mikko

Re: clock synchronization over IP
On Tue, 18 Sep 2018 04:23:37 -0700 (PDT), snipped-for-privacy@gmail.com
wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: clock synchronization over IP
On 17/09/18 18:45, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it


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.

Re: clock synchronization over IP
On 08/25/18 01:54, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

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


Re: clock synchronization over IP
On 21.9.2018 ?. 17:00, Chris wrote:
Quoted text here. Click to load it

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/




Re: clock synchronization over IP
wrote:

Quoted text here. Click to load it


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.

Re: clock synchronization over IP
On 09/21/18 15:58, Robert Wessel wrote:
Quoted text here. Click to load it

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





Re: clock synchronization over IP
On 09/21/18 15:12, Dimiter_Popoff wrote:
Quoted text here. Click to load it

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




Re: clock synchronization over IP
wrote:

Quoted text here. Click to load it

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

Site Timeline