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

On Thu, Mar 03, 2011 at 10:42:32PM -0600, Chris Caudle wrote:
> On Thu, March 3, Duncan Gray wrote:
> > If the NIC doesn't have one, the timestamp resolution
> > of a kernel PTP is one jiffy.
> 
> I think Torben already pointed out that you would probably use high
> resolution timers, and not the jiffy based timers.

yeah. they have nanoseconds resolution, and the only problem is that
querying them takes some time. but i think we are in the order of a few
ns here.

but i think its true, that the current software time stamping is jiffy
based. i fix that on the way, though.

> 
> > The AES-11 frequency accuracy (Grade-2) spec of 10 ppm for a
> > clock is nice, but probably won't be present in any PTP stream
> > from anyone I know of except Apogee.
> 
> The time and instrumentation guys will definitely have better than that.  
> You can already get PTP clocks from Symmetricom which will lock to GPS and
> give you long term accuracies better than 1ppb (10^-9).
> http://www.symmetricom.com/products/ieee-1588-ptp-solutions/
> 
> > Absolute frequency is not AVB's strength. The local clock
> > on the motherboard, servoed to NTP will be good enough.
> > What application might demand such low jitter RTC?
> 
> Absolute frequency accuracy and jitter are independent concepts.  There is
> no reason that the long term average frequency could not approach
> trivially close to 0 error if you are locked to a stratum 1 source such as
> GPS.
> Jitter is a more difficult issue, and you will have the same kinds of
> problems deriving a frame or bit clock from PTP as from Firewire. 
> Probably worse, you will definitely need a lot of jitter attenuation on
> your sampling clock PLL.
> 
> I think we're getting off track here, though. This is jack-devel, not
> network-attached-audio-equipment-devel.  Let's start with the expectation
> that someone else (or at least on a different mailing list) will make some
> hardware that uses PTP to synchronize sampling clocks, does it properly
> with lots of jitter attenuation, does it in a way that is AVB compliant,
> and has some higher level protocol that we can use, probably based on
> RTP/UDP/IP.
> At that point, JACK just has to make sure it sends groups of packets with
> audio samples, not too fast to overrun the buffers, not too slow to
> underrun the buffers.  That should be feasible with a software clock
> implementation, either using hardware assist in the NIC, or (hopefully)
> using a fully software implemented solution so that current generation
> hardware without explicit PTP support can be used.

my question about the suitability of the ptp clock to drive
clock_realtime is based on the fact that the kernel people do not want
to introduce different timebases (posix clocks) into the kernel, if
there are no real reasons. 

if the ptp clock, was derived from gps, and was epoch based. there is
actually no reason. we can just servo CLOCK_REALTIME to it, and do our
timing based on this.

but if that clock was crap. (iE out of some network loudspeakers with a
future $10 avb chip...) i wouldnt want that to be clock_realtime. 

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.

> 
> -- 
> Chris Caudle
> 
> 
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

-- 
torben Hohn

1299232614.13730_0.ltw:2,a <20110304095636.GG4903 at siel dot b>