netdev - Re: [PATCH net-next 4/7] sfc: Add support for IEEE-1588 PTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Jul 2012 17:30:16 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Stuart Hodgson <smhodgson@...arflare.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-net-drivers@...arflare.com,
	Andrew Jackson <ajackson@...arflare.com>
Subject: Re: [PATCH net-next 4/7] sfc: Add support for IEEE-1588 PTP

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?

> > ... 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.

Thanks,
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