Date:	Fri, 16 Mar 2012 07:55:38 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	chetan loke <loke.chetan@...il.com>
Cc:	netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	jacob.e.keller@...el.com, jeffrey.t.kirsher@...el.com,
	john.ronciak@...el.com, john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of
 the timecompare method

On Thu, Mar 15, 2012 at 01:18:26PM -0400, chetan loke wrote:
> 
> 1) how can I use igb->PHC to set/discipline my system time?
>  a) clock_gettime(IGB_CLK_ID...);
>  b) clock_settime(REAL_TIME,...) ? Good/bad idea?

This is a very crude method, and it will cause frequent jumps in your
system clock.

Better would be:

    a = clock_gettime(igb_clk_id);
    clock_settime(CLOCK_REALTIME, a);

    once_every_second()
    {
        a = clock_gettime(igb_clk_id);
        b = clock_gettime(CLOCK_REALTIME);
        offset = a - b;
        freq_adj = pi_servo(offset);
        clock_adjtime(CLOCK_REALTIME, freq_adj);
    }

There is a program, phc2sys, that does something very similar to this
(but using a kernel PPS time stamp instead of clock_gettime) in the
linuxptp code. You could modify that program to do the above fairly
easily. With a heavy enough filter, it might even be acceptable.

    http://linuxptp.sourceforge.net/

Even better would be to use the internal PPS provided by some PHC
hardware to get a better time stamp from the system clock. The IGB
could provide this (I think), but it is not implemented yet.

> 2) what is this deadlock from intel's datasheet
> (http://download.intel.com/design/network/datashts/82576_Datasheet.pdf)
> - goto pg 426
>   2.1) Is this applicable? If not please ignore this question.
>   2.2) Do we need to worry about it. Just asking because a quick
> visual scan didn't pull up - TIMADJL/H.

Do you mean RXSTMPL/H?

Looking at igb_rx_hwtstamp() in igb_main.c, it appears that the 82576
might deliver wrong time stamps with a received packet, if ever a
packet gets time stamped in hardware but does not make it into the Rx
ring buffer.

The 82580 delivers the time stamp with the frame and does not have this
problem.

> 3) Testing IGB PHC (couple of months from now because I'm busy with
> something else):
> 
>    3.1) CardX(It's a different non-intel NIC) and CardY(intel) are in
> hostA. Both cards will use the same time-source Z.
>    3.2) CardX is time-sync'd using PTP.
>    3.3) CardY - is a dual port card. Port 0 will receive PTP packets
> via time-srcZ.
>    3.4) Wait for some time for both the cards to get in-sync.
>    3.5) feed same traffic to Card X and CardY-Port1.
>    3.6) measure time-difference across packets from different NICs on hostA.
> 
>    Is this a good test configuration? Now, ofcourse there will be some
> delta but the intention is to get a feel. See how far off are both the
> adapters.

The best way to do this is to compare a 1 PPS output from each card. I
think the IGB hardware can provide a PPS output, but driver support is
not yet there. Also, the pin providing the signal may or may not be
accessible on your card. Talk to Intel about this.
 
> 4) possible contention on tmreg_lock?
> I will read previous emails/patches shortly but I was thinking - what
> if there are many readers who would like to use PHC as reference time?
> Then do we want them to block the driver who wants to time-stamp the
> packet?
>  igb_gettime->spin_lock::tmreg_lock         <---contention--->  driver
> ->igb_systim_to_hwtstamp->spin_lock::tmreg_lock

Under normal use cases, I would not expect much contention at all.

HTH,

Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists