Cost-effectivenesss of highly-accurate clocks for NTP

Måns Nilsson mansaxel at
Sun May 15 19:16:26 UTC 2016

Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP Date: Sun, May 15, 2016 at 03:21:02PM +0000 Quoting Mel Beckman (mel at
> The upshot is that there are many real-world situations where expensive clock discipline is needed. But IT isn't, I don't think, one of them, with the exception of private SONET networks (fast disappearing in the face of metro Ethernet).

Pro audio is moving to Ethernet (they talk about it, Ethernet, as either
"RJ45" or "Internet"...) and sometimes even to IP in a fairly rapid
pace. If you think the IP implementations in IoT devices are naîve, wait
until you've seen what passes for broadcast quality network engineering.

Shoving digital audio samples in raw Ethernet frames is at least 20 years
old, but the last perhaps 5 years has seen some progress in actually
using IP to carry audio streams. (this is close-to-realtime audio,
not file transfers, btw.)

A lot of audio is sent using codecs like Opus, with SIP as
signalling. That works quite nicely. We've got a smartphone app to do
that, for instance. 

But, this is all mostly floating in terms of absolute sampling
frequency. Digital audio needs a clock to work. In the simple home stereo
case, this is taken care of by listening to the pace samples arrive at,
and using that. But as soon as you are mixing two sources, they need
to be in tune. Something needs to decide what to use as master. In the
smartphone case, we simply buffer some 20-100ms of audio and start playing
back, using our own clock. Then we hope the interview is over before
the buffer is overflowing or drained. Which mostly works.

Inside facilities, when we use the SIP-signalled streams, we usually can
rely on a separate clock distribution. In our specific case, we've bought
country-wide clock distribution that gives us the same sample clock in
all facilities. (Digital TV is mostly built as single frequency networks,
which requires syntonous (at least) transmitters. Thus, it today is
quite easy to find providers of frequency in the broadcast business.)

Now, the Audio Engineering Society has published AES67 which in essence
is multichannel, multicast RTP audio (L48 mediatype, ie. linear 48KHz
24-bit) synchronized by PTP, also multicast.

Now, bear in mind that I wrote _synchronized_, not _syntonized_. 

Up to now, the only thing that mattered to keep track of was
frequency. Since one of the big reasons for AES67 is distributing
sound to several different loudspeakers that can be heard by one
listener simultaneously, the prime example being a stereo pair of active
loudspeakers with one network jack on each, _phase_ matters, as well as
absolute time. (Mostly, telco synchronization mentions absolute time as
phase.) This application requires absolute time, since a mono sound
in our stereo example needs to play back _at the same time_ from both
speakers. Or it ceases to be a mono sound, instead becoming a sound
that is offset in the soundstage by delaying it. 
Most classical stereo recordings are mono in terms of level, but not in
terms of the time domain; since they derive all spatial info from time,
not gain. Like we humans do.

The usual test case is to buy a PTP-aware switch, a PTP Grand Master,
steered by <something>  and build a small LAN, test that Vendor A and
Vendor B can send audio between themselves via this simple network and
call it a day.

That is a nice lab setup. Also very far from what needs to be built in 
order to solve the actual production cases. 

But, to try to return to "relevant for NANOG", there are actual products
requiring microsecond precision being sold. And used. And we've found
that those products don't have a very good holdover. On ranty days I
usually accuse them of having hotglued an Ethernet adapter onto the old
TDM-based audio devices and sent them out to customers with a prayer
and instructions to build an overengineered network to make certain that
PTP always is delivered with zero IPDV.

A lot of strange things are getting network connectors these days. Not
all of them are content with a http connection to some cloud provider.
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <>

More information about the NANOG mailing list