netdev - Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAsGZS4xU6Uqu59r6donnVmvi-NdxhQRi-7FEEHwg0mFcmKhxA@mail.gmail.com>
Date:	Wed, 21 Mar 2012 13:02:38 -0400
From:	chetan loke <loke.chetan@...il.com>
To:	Richard Cochran <richardcochran@...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 Wed, Mar 21, 2012 at 12:08 PM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Wed, Mar 21, 2012 at 11:00:59AM -0400, chetan loke wrote:
>>
>> Once PHC->gettime goes live(aka exported to user space), we can't
>> really control how users will use it in their applications. There
>> could be 100+ apps all trying to get real-time from the network to do
>> some time-keeping stuff. They might pound the ioctls at high rate. The
>> last thing we would want is to self-induce a light weight DOS.
>
> Well, if people want to write programs that make no sense at all,
> then I can cannot stop them. There really isn't any point in general
> applications using the PHC directly. You can easily synchronize the

I thought the core patches enables using PHC as a reference time, no?
So that seems to be contradicting the PHC API. If there's no point
then why are we exporting PHC->get_time as a generic interface? May be
just limit get_time interface to something like ethtool?

> system time to the PHC to within a few microseconds. Just the error
> from reading the clock (due to various kinds of latency) is much
> larger than that.
>

Once, the clocks are in-sync, it's not an error - but  *somewhat
fixed* latency. There are users who don't want to spend extra money
for expensive GPS time-sync stuff but yet have enough CPUs such that
they can dedicate 1 CPU for book-keeping. For such users, this
*somewhat fixed* latency should be constant over a period of time even
when other CPUs are processing traffic at line rate.

> Also, although you might be able to optimize clock_gettime performance
> for a PCI card, this will never work for PHY based devices, which, by
> the way, offer superior PTP time stamping. So, in general, applications
> should stick to reading the system time. We still need to get some more tools out there in order to support the
> PHC->system synchronization, but that is not too far off. That is what
> I am working on now,

Sounds good on the tools part. But if applications should stick to
reading sys-time then either we shouldn't export the API or export it
selectively.If there's an API then user-space guys will use it. For
this discussion, lets focus on PCI cards because that is what this
patch talks about. Also the majority of the deployment will be LOM or
PCI cards.

>
> Thanks,
> Richard
>
thanks
Chetan
--
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