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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120322070026.GC2182@netboy.at.omicron.at>
Date:	Thu, 22 Mar 2012 08:00:26 +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 01:02:38PM -0400, chetan loke wrote:
> > 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?

There was a long discussion on this list and the lkml about the API,
and I think what we came up is a good solution. There is nothing to
prevent you from rewriting all of user space to use a dynamic clock ID
instead of CLOCK_REALTIME, but I seriously doubt anyone is going to do
this.

It does make sense for the time synchronization services to use
the clock_gettime calls to do their work.

Calls to read the system clock are highly optimized (at least on x86),
and thus applications wanting quick time stamps are wise to use that
clock. Calling clock_gettime on another clock, a PHY based clock for
example, might block for a long, long time. There is no way to
optimize around that, since it is a MDIO bus transaction.

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

Consider the following program:

	if (interesting_event()) {
		/* what happens in this empty space? preemption? interrupt? */
		clock_gettime();
	}

Run cyclictest on your system, and let's then talk about your 'fixed'
latency numbers.

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

Like I said, I personally don't see much utility in optimizing igb. I
only have so much time to spend, but I am not against you or Jacob or
anyone else doing that work.

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