[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120321160817.GB1941@netboy.at.omicron.at>
Date: Wed, 21 Mar 2012 17:08:17 +0100
From: Richard Cochran <richardcochran@...il.com>
To: chetan loke <loke.chetan@...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 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
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.
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, and I don't think optimizing the igb is worth the
effort. If you want to try it, please go right ahead, but adding the
PPS would be much more useful IMHO.
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
Powered by blists - more mailing lists