linux-kernel - Re: [PATCH 2/3] ptp: add a software clock based on clock_monotonic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110311111321.GA5553@siel.b>
Date:	Fri, 11 Mar 2011 12:13:21 +0100
From:	torbenh <torbenh@....de>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	john stultz <johnstul@...ibm.com>, linux-kernel@...r.kernel.org,
	richard.cochran@...cron.at, tglx@...utronix.de
Subject: Re: [PATCH 2/3] ptp: add a software clock based on
 clock_monotonic_raw

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/