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 for Android: free password hash cracker in your pocket

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

Message-ID: <50165BD6.2030205@solarflare.com>
Date:	Mon, 30 Jul 2012 11:03:02 +0100
From:	Stuart Hodgson <smhodgson@...arflare.com>
To:	Richard Cochran <richardcochran@...il.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 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

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