From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Stultz Subject: Re: [PATCH NET-NEXT 02/10] time sync: generic infrastructure to map between time stamps generated by a time counter and system time Date: Mon, 09 Feb 2009 13:54:18 -0800 Message-ID: <1234216458.10457.56.camel@jstultz-laptop> References: <1233752517-30010-1-git-send-email-patrick.ohly@intel.com> <1233752517-30010-2-git-send-email-patrick.ohly@intel.com> <1233752517-30010-3-git-send-email-patrick.ohly@intel.com> <1233776680.6994.30.camel@localhost.localdomain> <1233829262.20435.37.camel@pohly-MOBL> <1234198922.20325.170.camel@ecld0pohly> <1234207667.10457.53.camel@jstultz-laptop> <1234216013.8213.18.camel@pohly-MOBL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , David Miller , Thomas Gleixner To: Patrick Ohly Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:52199 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752643AbZBIV6b (ORCPT ); Mon, 9 Feb 2009 16:58:31 -0500 In-Reply-To: <1234216013.8213.18.camel@pohly-MOBL> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2009-02-09 at 22:46 +0100, Patrick Ohly wrote: > On Mon, 2009-02-09 at 21:27 +0200, John Stultz wrote: > > On Mon, 2009-02-09 at 18:02 +0100, Patrick Ohly wrote: > > > Is this revision of the patch okay? How should the two patches get > > > included in the main kernel - via netdev-next-2.6? > > > > Small comment below, but otherwise it looks ok to me. I usually push > > patches through Andrew, so I'd probably go that way. But I'd leave it to > > Dave if he's comfortable pushing them to Linus. > > As you don't mind, I suggest to push through Dave as part of the > complete patch series. That way we don't need to worry about > coordinating two subtrees. > > > Acked-by: John Stultz > > Thanks! Will add that. > > > > + /* ignore negative durations */ > > > + sample.duration_target = ktime_to_ns(ktime_sub(end, start)); > > > + if (sample.duration_target >= 0) { > > > > You may also want to checking the bounds on the duration_target. If > > preemption hits and the values are too out of whack, the symetric delay > > assumption below might be quite invalid. > > > > I guess the outliers removal probably covers this as well, but seems > > some sanity checking might be good. > > That would require more information, like "duration_target is usually in > the xxx-yyy range". This could be determined based on past measurements > or the median of the current sample set, but is this really better than > the current "remove longest 25%"? > > In practice I haven't seen such a problem, therefore I'd prefer to keep > the code simple and not change it. It was tested under load conditions > (both CPU and network). Ok. I was just thinking more along the lines of "throw out duration times longer then 25us" or 100us or something relatively sane like that. Again, the largest 25% will probably cover it, but I'm just looking at this with the realtime preemption patches in mind. thanks -john