Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965013AbaGPOQm (ORCPT ); Wed, 16 Jul 2014 10:16:42 -0400 Received: from dehamd003.servertools24.de ([31.47.254.18]:53130 "EHLO dehamd003.servertools24.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934388AbaGPOQk (ORCPT ); Wed, 16 Jul 2014 10:16:40 -0400 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Message-ID: <53C68943.2060003@ladisch.de> Date: Wed, 16 Jul 2014 16:16:35 +0200 From: Clemens Ladisch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Peter Zijlstra , Daniel Thompson CC: Thomas Gleixner , Stefan Richter , linux-kernel@vger.kernel.org, linux1394-devel@lists.sourceforge.net, John Stultz , Mark Brown Subject: Re: firewire: CLOCK_MONOTONIC_RAW exposure References: <53C6633D.9080905@ladisch.de> <20140716123727.GA19379@twins.programming.kicks-ass.net> In-Reply-To: <20140716123727.GA19379@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra wrote: > On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote: >> Thomas Gleixner wrote: >>> I wonder why firewire exposed CLOCK_MONOTONIC_RAW to user space. >>> >>> What's the purpose of that? CLOCK_MONOTONIC_RAW is the raw time based >>> on the initial frequency setup of the clocksource. That can be quite >>> off from the NTP corrected frequency which is exposed by >>> CLOCK_MONOTONIC. >> >> The purpose is to get a stable clock, i.e., to avoid clock rate changes >> caused by NTP corrections. > > That's maybe half an answer; what do you need that for? According to the original report, "for applications which need to synchronise with external timebases such as broadcast TV applications". Such external clocks are not synchronous with any available clocksource, so proper resampling requires that the (relative) rate of the two clocks (sender and playback device) is measured accurately. (I don't have numbers for the errors caused by NTP adjustments. Daniel?) Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/