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  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:	Mon, 07 Jul 2014 12:44:44 -0700
From:	Chad Reese <kreese@...ium.com>
To:	Willem de Bruijn <willemb@...gle.com>,
	Richard Cochran <richardcochran@...il.com>
CC:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Chad Reese <kreese@...iumnetworks.com>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH net-next v2 1/8] net-timestamp: explicit SO_TIMESTAMPING
 ancillary data struct

On 07/07/2014 12:14 PM, Willem de Bruijn wrote:
> On Mon, Jul 7, 2014 at 2:47 PM, Richard Cochran
> <richardcochran@...il.com> wrote:
>> On Mon, Jul 07, 2014 at 11:34:05AM -0400, Willem de Bruijn wrote:
>>>
>>> The hardware timestamp converted to system time is deprecated? I did
>>> not know that. Because it is largely unused, or for a more fundamental
>>> reason?
>>
>> It is for the fundamental reason that the idea behind it is just plain
>> wrong. MAC drivers are not the place to put clock servos.
>>
>>> If so, the documentation could indeed use an explicit comment. The
>>> definition of skb_shared_hwtstamps.syststamp too. I can write a small
>>> patch independent of this patchset.
>>
>> Please do.
>
> Ok. See below.
>
>>
>>> Unfortunately, a cursory inspection shows one, octeon. While that user
>>> exists and generates such timestamps, I think that the above new flag
>>> should be passed, as well, for API consistency.
>>
>> Ugh, how the heck did that turd get in? Its not like they bothered to
>> include the maintainer on CC. That code must go.
>
> I'm happy to unwind the syststamp part of 3d305850 ("netdev:
> octeon_mgmt: Add hardware timestamp support"). Chad, let me know if
> you object to that. Else, I'll send a patch to you both for review.

A hardware timer used for ethernet timestamps is completely independent 
from the kernel's software view of time. Since the hardware timestamps 
are only exposed in the driver, how can they be correlated with system 
time? If the driver doesn't do it, then nobody else knows how.

For Octeon, you can optionally use the hardware timestamp as the system 
clock reference. Most people don't, but it is the only way to get the 
system time to be accurate. 1588 can synchronize two Octeon boards to 
less than 1ns for the hardware timer. The Linux software timers is 
always farther off.

Chad

-- 

Chad Reese <kreese@...ium.com>
Cavium Networks
Phone: 408 - 943 - 7183
Cell: 321 - 438 - 7753

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