Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

On Fri, March 4, 2011 3:56 am, torbenh wrote:
> if we can cite the standard draft with some requirements for the clock,
> which are unacceptable for clock_realtime, we would have a good argument
> for maintaining the avb clock as a different timebase inside the kernel.

I don't like the way IEEE draft standards are so hard to get. I can't
really find the full standard which is currently proposed for 802.1AS (the
synchronization standard), but here is what the working group page says:
http://www.ieee802.org/1/pages/802.1as.html

"This standard specifies the protocol and procedures used to ensure that
the synchronization requirements are met for time sensitive applications,
such as audio and video, across Bridged and Virtual Bridged Local Area
Networks consisting of LAN media where the transmission delays are fixed
and symmetrical; for example, IEEE 802.3 full duplex links. This includes
the maintenance of synchronized time during normal operation and following
addition, removal, or failure of network components and network
reconfiguration. It specifies the use of IEEE 1588 specifications where
applicable in the context of IEEE Stds 802.1D and 802.1Q. Synchronization
to an externally provided timing signal (e.g., a recognized timing
standard such as UTC or TAI) is not part of this standard but is not
precluded."

"This standard enables stations attached to bridged LANs to meet the
respective jitter, wander, and time synchronization requirements for
time-sensitive applications."


I think the relevant point for your concern is that "(...UTC...) is not
part of this standard but is not precluded."

So if a device had capability to keep UTC and was the grandmaster, all
well and good, but if not, the network timing still works, you just have
no defined relationship to external time.

Since it seems you would definitely want a device with hardware timing
support to act as the grandmaster for your network, a standard PC could
not be the grandmaster, it would have to be a time slave, and might have
to slave to a device with no concept of UTC.

-- 
Chris Caudle

1299262027.12554_0.ltw:2,a <a655b75674db47c583d0a5a6847675e0.squirrel at email dot powweb dot com>