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  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]
Date:	Mon, 30 Jul 2012 11:03:02 +0100
From:	Stuart Hodgson <>
To:	Richard Cochran <>
CC:	Ben Hutchings <>,
	David Miller <>, <>,
	Andrew Jackson <>
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
More majordomo info at

Powered by blists - more mailing lists