public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torbenh <torbenh@gmx.de>
To: Richard Cochran <richardcochran@gmail.com>
Cc: john stultz <johnstul@us.ibm.com>,
	linux-kernel@vger.kernel.org, richard.cochran@omicron.at,
	tglx@linutronix.de
Subject: Re: [PATCH 2/3] ptp: add a software clock based on clock_monotonic_raw
Date: Fri, 11 Mar 2011 12:13:21 +0100	[thread overview]
Message-ID: <20110311111321.GA5553@siel.b> (raw)
In-Reply-To: <20110306132834.GA11790@riccoc20.at.omicron.at>

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

  reply	other threads:[~2011-03-11 11:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 17:26 some patches for the ptp framework Torben Hohn
2011-03-03 17:26 ` [PATCH 1/3] remove __cpuinit from mwait_usable() Torben Hohn
2011-03-03 17:26 ` [PATCH 2/3] ptp: add a software clock based on clock_monotonic_raw Torben Hohn
2011-03-03 19:34   ` john stultz
2011-03-04  6:46     ` Richard Cochran
2011-03-04 11:06       ` torbenh
2011-03-05 20:08       ` john stultz
2011-03-06 13:28         ` Richard Cochran
2011-03-11 11:13           ` torbenh [this message]
2011-03-11 11:37             ` Christian Riesch
2011-03-11 13:38               ` torbenh
2011-03-11 11:56             ` Christian Riesch
2011-03-04  6:42   ` Richard Cochran
2011-03-04 11:30     ` torbenh
2011-03-04 16:10       ` Richard Cochran
2011-03-03 17:26 ` [PATCH 3/3] Check for write permission on FD based posix-clocks Torben Hohn
2011-03-04  7:22   ` Richard Cochran
2011-03-04  9:55     ` Arnd Bergmann
2011-03-04 10:13     ` torbenh
2011-03-11 19:46     ` Thomas Gleixner
2011-03-12 17:23       ` Richard Cochran
2011-03-12 17:35         ` Thomas Gleixner
2011-03-12 20:30   ` [tip:timers/core] posix-clocks: Check write permissions in posix syscalls tip-bot for Torben Hohn
2011-03-04  6:21 ` some patches for the ptp framework Richard Cochran
2011-03-10  7:02   ` Richard Cochran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110311111321.GA5553@siel.b \
    --to=torbenh@gmx.de \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.cochran@omicron.at \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox