Re: [PATCH 2/3] ptp: add a software clock based onclock_monotonic_raw

[torbenh]

On Sun, Mar 06, 2011 at 02:28:36PM +0100, Richard Cochran wrote:
> On Sat, Mar 05, 2011 at 12:08:07PM -0800, john stultz wrote:
> > On Fri, 2011-03-04 at 07:46 +0100, Richard Cochran wrote:
> > > I do think a software only PHC will make it easier for people to get
> > > started with the new interface. I have been carrying along such a
> > > patch privately for my own testing.
> > 
> > Consistency is but a hobgoblin... :)
> > 
> > But seriously, do forgive me if I misunderstood your earlier patches
> > with this respect. I thought it was just exporting CLOCK_REALTIME
> > directly through a new interface/clockid (which would be duplicative).
> 
> You are right, I was doing that, but the purpose was for testing.
> 
> I am not sure where Torben is going with his idea. In order to figure
> out meaningful clock adjustments, you need the clock's timestamps on
> the PTP packet tx/rx events. Implementing an internal clock correction
> with no connection to the network stack might still be interesting,
> but I think having the timestamps is much more useful.

I am planning to enable the networking stack to timestamp using
arbitrary clock id. 
But that means adding an ioctl. So there is going to be a lot of
critical review, and questions asked. 

On the audio lists, we have a guy now claiming that software ptp would
confuse the whole h/w ptp infrastructure. His main agenda seems to be to
prevent a software only ptp/avb implementatation.
I cant imagine how a slave clock can confuse a master clock.
And emission of audio stream packets does not need to be accurate to the
nanosecond.

I am a bit confused now, because i initially thought, i could quote that
guy to prove that an avb master clock might not necessarily be suitable
to become CLOCK_REALTIME. 

I am still assuming this. But i dont really have proof.
This might block this.

> 
> Let's wait and see what Torben says once he come back from travel.
> 
> Thanks,
> 
> Richard

-- 
torben Hohn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/