All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jackson <ajackson@solarflare.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
	David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>,
	<linux-net-drivers@solarflare.com>
Subject: Re: [PATCH net-next 4/7] sfc: Add support for IEEE-1588 PTP
Date: Thu, 19 Jul 2012 17:05:45 +0100	[thread overview]
Message-ID: <50083059.7070700@solarflare.com> (raw)
In-Reply-To: <1342708653.2617.33.camel@bwh-desktop.uk.solarflarecom.com>

On 19/07/2012 15:37, Ben Hutchings wrote:
> On Thu, 2012-07-19 at 16:25 +0200, Richard Cochran wrote:
>> On Wed, Jul 18, 2012 at 07:21:33PM +0100, Ben Hutchings wrote:

>>> +/* Process times received from MC.
>>> + *
>>> + * Extract times from returned results, and establish the minimum value
>>> + * seen.  The minimum value represents the "best" possible time and events
>>> + * too much greater than this are rejected - the machine is, perhaps, too
>>> + * busy. A number of readings are taken so that, hopefully, at least one good
>>> + * synchronisation will be seen in the results.
>>> + */
>>
>> This code looks like it is trying to find the offset between two
>> clocks. Is there some reason why you cannot use <linux/timecompare.h>
>> to accomplish this?
>>
>> Also, these comments about "hopefull" synchronization make me
>> nervous. I think it might be easier just to offer RAW timestamps and
>> forget about the SYS timestamps.
>>
>> I am trying to purge the whole SYS thing (only blackfin is left)
>> because there is a much better way to go about this, namely
>> synchronizing the system time to the PHC time via an internal PPS
>> signal.
>
> Andrew, would that work for us?

I don't think so for the reason that Stu has pointed out (failed 
assumption).

The NIC's clock isn't directly accessible by the host from the PCIe bus 
and is "behind" the MC. Even when we process PPS events, we need a 
reliable way of determining the relationship between the two clocks 
(system <> NIC). We're trying to get that as accurately as we can but we 
know that some measurements will be incorrect/out of bounds because of 
loading on the system.

In retrospect, I should have phrased the comment in more statistical 
terms rather than using ambiguous phrases like "hopefully".

	Andrew

  reply	other threads:[~2012-07-19 16:05 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 [this message]
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
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=50083059.7070700@solarflare.com \
    --to=ajackson@solarflare.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-net-drivers@solarflare.com \
    --cc=netdev@vger.kernel.org \
    --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.