Re: firewire: CLOCK_MONOTONIC_RAW exposure

[John Stultz]

On 07/17/2014 01:37 AM, Daniel Thompson wrote:
> On 16/07/14 16:00, Mark Brown wrote:
>> On Wed, Jul 16, 2014 at 04:16:35PM +0200, Clemens Ladisch wrote:
>>> (I don't have numbers for the errors caused by NTP adjustments.  Daniel?)
>> Right, the goal is to get a clock which is guaranteed to never have any
>> adjustments that might cause discontinuities or rate changes applied to
>> it.  My understanding is that the users are already doing their own rate
>> matching and it's much more important to them to get a stable clock than
>> it is to get a clock at a specific nominal rate, and given the set top
>> box applications I expect they also need this from very soon after boot.
> We are trying to match rates with a broadcast device that "shouts" the
> current time many times per second (MPEG transport stream PCR packets).
> These packets are timestamped on arrival with a local clock and the
> resulting data is used to recover the broadcast clock. However due to
> variable transmission delay of the packets we require very long
> control loops to extract any useful information from this data (varies
> between five minutes and half and hour).
>
> An NTP rate correction can change the rate of CLOCK_MONOTONIC
> sufficiently to confuse our clock recovery algorithms so we use
> CLOCK_MONOTONIC_RAW as the master view of time.

Just to further clarify on this point, the problem is that with NTP
there are both frequency (ie: clock runs too fast) and offset (ie: we're
out of sync by 10ms) corrections made to CLOCK_REALTIME. 

In the long-term when we've synced up with NTP, these are basically the
same thing, so to keep things (relatively) simple we eventually combine
these into one adjustment factor when steering the clock.  But in the
short-term when we're trying to quickly get in sync with NTP, the offset
correction can be fairly large.

The problem is that we want CLOCK_MONOTONIC to be frequency corrected,
so that a second is really a second. But we don't really care about it
being offset corrected. However, since its much simpler to define a
fixed offset between _MONOTONIC and _REALTIME (which is only modified if
_REALTIME is set or stepped).

Ideally I guess we'd probably want to track the freq adjustment and
offset adjustment separately and apply the freq offset to both
_MONONTONIC and _REALTIME, but only apply offset corrections to
_REALTIME. However, this would make the accounting much more complex and
would break the fixed relationship between _MONOTONIC and _REALTIME.

Miroslav has discussed trying this previously, but I'm a bit skeptical
its worth the extra effort and overhead.

CLOCK_MONOTONIC_RAW provide just a nanosecond abstraction of a hardware
counter. It was added because some folks who were doing time sync
algorithms were using non-portable methods like rdtsc to measure
corrections being made (as measuring correction with the time base being
corrected is a bit circular). So in cases where the short-term
adjustment is problematic, it can be a good choice, as long as accuracy
needs are low (since a second may not be a real second).

thanks
-john










CLOCK_MONOTONIC is ntp corrected, since we want 1 second there to really
be 1 second.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/