All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hubert Feurstein <h.feurstein@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev <netdev@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Richard Cochran <richardcochran@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v3 2/4] net: mdio: add PTP offset compensation to mdiobus_write_sts
Date: Wed, 21 Aug 2019 10:07:09 +0200	[thread overview]
Message-ID: <20190821080709.GO891@localhost> (raw)
In-Reply-To: <CAFfN3gUgpzMebyUt8_-9e+5vpm3q-DVVszWdkUEFAgZQ8ex73w@mail.gmail.com>

On Tue, Aug 20, 2019 at 06:56:56PM +0200, Hubert Feurstein wrote:
> Am Di., 20. Aug. 2019 um 17:40 Uhr schrieb Miroslav Lichvar
> > I think a large jitter is ok in this case. We just need to timestamp
> > something that we know for sure happened after the PHC timestamp. It
> > should have no impact on the offset and its stability, just the
> > reported delay. A test with phc2sys should be able to confirm that.
> > phc2sys selects the measurement with the shortest delay, which has
> > least uncertainty. I'd say that applies to both interrupt and polling.
> >
> > If it is difficult to specify the minimum interrupt delay, I'd still
> > prefer an overly pessimistic interval assuming a zero delay.
> >
> Currently I do not see the benefit from this. The original intention was to
> compensate for the remaining offset as good as possible.

That's ok, but IMHO the change should not break the assumptions of
existing application and users.

> The current code
> of phc2sys uses the delay only for the filtering of the measurement record
> with the shortest delay and for reporting and statistics. Why not simple shift
> the timestamps with the offset to the point where we expect the PHC timestamp
> to be captured, and we have a very good result compared to where we came
> from.

Because those reports/statistics are important in calculation of
maximum error. If someone had a requirement for a clock to be accurate
to 1.5 microseconds and the ioctl returned a delay indicating a
sufficient accuracy when in reality it could be worse, that would be a
problem.

BTW, phc2sys is not the only user of the ioctl.

-- 
Miroslav Lichvar

  reply	other threads:[~2019-08-21  8:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20  8:48 [PATCH net-next v3 0/4] Improve phc2sys precision for mv88e6xxx switch in combination with imx6-fec Hubert Feurstein
2019-08-20  8:48 ` [PATCH net-next v3 1/4] net: mdio: add support for passing a PTP system timestamp to the mii_bus driver Hubert Feurstein
2019-08-20  8:48 ` [PATCH net-next v3 2/4] net: mdio: add PTP offset compensation to mdiobus_write_sts Hubert Feurstein
2019-08-20  9:49   ` Miroslav Lichvar
2019-08-20 12:29     ` Hubert Feurstein
2019-08-20 14:25       ` Miroslav Lichvar
2019-08-20 15:23         ` Andrew Lunn
2019-08-20 15:40           ` Miroslav Lichvar
2019-08-20 16:56             ` Hubert Feurstein
2019-08-21  8:07               ` Miroslav Lichvar [this message]
2019-08-21  9:53                 ` Hubert Feurstein
2019-08-21 10:19                   ` Vladimir Oltean
2019-08-21 10:19                   ` Miroslav Lichvar
2019-08-20 13:26     ` Andrew Lunn
2019-08-20  8:48 ` [PATCH net-next v3 3/4] net: dsa: mv88e6xxx: extend PTP gettime function to read system clock Hubert Feurstein
2019-08-20  8:48 ` [PATCH net-next v3 4/4] net: fec: add support for PTP system timestamping for MDIO devices Hubert Feurstein
2019-08-21 10:28   ` Vladimir Oltean
2019-08-22  3:49 ` [PATCH net-next v3 0/4] Improve phc2sys precision for mv88e6xxx switch in combination with imx6-fec David Miller

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=20190821080709.GO891@localhost \
    --to=mlichvar@redhat.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=h.feurstein@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=richardcochran@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.