From: Stuart Hodgson <smhodgson@solarflare•com>
To: Richard Cochran <richardcochran@gmail•com>
Cc: Ben Hutchings <bhutchings@solarflare•com>,
David Miller <davem@davemloft•net>, <netdev@vger•kernel.org>,
<linux-net-drivers@solarflare•com>,
Andrew Jackson <ajackson@solarflare•com>
Subject: Re: [PATCH net-next 4/7] sfc: Add support for IEEE-1588 PTP
Date: Mon, 30 Jul 2012 11:03:02 +0100 [thread overview]
Message-ID: <50165BD6.2030205@solarflare.com> (raw)
In-Reply-To: <20120720153016.GB2771@netboy.at.omicron.at>
On 20/07/12 16:30, Richard Cochran wrote:
> On Fri, Jul 20, 2012 at 10:15:46AM +0100, Stuart Hodgson wrote:
>>
>> Do you mean using the PPS kernel consumer to govern the system time?
>
> Well, I meant just using the PPS subsystem, which does not necessarily
> mean that the kernel consumer has to be used. In my experience, it is
> better to handle the servo in user space, but in any case, the user
> has the choice of what to do.
>
>>>>>> + ptp_pps_evt.type = PTP_CLOCK_EXTTS;
>>>>>> + ptp_pps_evt.timestamp = ktime_to_ns(gen_time_host);
>>>>>> + ptp_clock_event(ptp->phc_clock, &ptp_pps_evt);
>
>> In order for a PPS to arrive at the kernel consumer ptp_clock_event
>> needs to be called with PTP_CLOCK_PPS. This then calls pps_get_ts
>> and stamps the event with the current system time, not the time
>> that was put into the event.
>
> Oops, I meant PTP_CLOCK_PPS. I overlooked that your code is making an
> external timestamp event, but the basic idea is similar.
>
>> Using PTP_CLOCK_EXTTS the PPS is visible to userspace via a read
>> on the phc device and can then be used in our modified ptpd2.
>
> How does your program use this information?
>
We have a second servo that governs the system time.
>>> ... why can't you also just set the time?
>>
>> Our hardware can only have an offset applied to the clock. In order to set time
>> we need to know the time now, then work out and offset to get to the target time.
>> At the point that we apply this offset the clock will have moved on and not be
>> set to the target time. We can apply some measured average times to the offset
>> to get closer but with this hardware settime will not leave the NIC clock at the
>> desired time.
>
> It does not matter if setting the time introduces a small error. That
> usually happens, but it is no big deal, since the servo in the PTP
> stack will correct the error.
>
I will add the ability to set the time to the patch.
> Thanks,
> Richard
next prev parent reply other threads:[~2012-07-30 10:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 18:16 pull request: sfc-next 2012-07-18 Ben Hutchings
2012-07-18 18:19 ` [PATCH net-next 1/7] sfc: Add explicit RX queue flag to channel Ben Hutchings
2012-07-18 18:20 ` [PATCH net-next 2/7] sfc: Add channel specific receive_skb handler and post_remove callback Ben Hutchings
2012-07-18 18:32 ` David Miller
2012-07-18 18:42 ` Ben Hutchings
2012-07-18 18:43 ` David Miller
2012-07-18 18:20 ` [PATCH net-next 3/7] sfc: Allow efx_mcdi_rpc to be called in two parts Ben Hutchings
2012-07-18 18:21 ` [PATCH net-next 4/7] sfc: Add support for IEEE-1588 PTP Ben Hutchings
2012-07-19 14:25 ` Richard Cochran
2012-07-19 14:37 ` Ben Hutchings
2012-07-19 16:05 ` Andrew Jackson
2012-07-20 6:11 ` Richard Cochran
2012-07-19 15:29 ` Stuart Hodgson
2012-07-19 15:43 ` David Miller
2012-07-19 15:50 ` Ben Hutchings
2012-07-20 7:37 ` Richard Cochran
2012-07-20 6:31 ` Richard Cochran
2012-07-20 9:15 ` Stuart Hodgson
2012-07-20 15:30 ` Richard Cochran
2012-07-30 10:03 ` Stuart Hodgson [this message]
2012-07-18 18:21 ` [PATCH net-next 5/7] sfc: Support variable-length response to MCDI GET_BOARD_CFG Ben Hutchings
2012-07-18 18:22 ` [PATCH net-next 6/7] sfc: Expose FPGA bitfile partition through MTD Ben Hutchings
2012-07-18 18:22 ` [PATCH net-next 7/7] sfc: Bump version to 3.2 Ben Hutchings
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=50165BD6.2030205@solarflare.com \
--to=smhodgson@solarflare$(echo .)com \
--cc=ajackson@solarflare$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-net-drivers@solarflare$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=richardcochran@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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