Stefan,
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.
If there is no real good reason, I'd really like to remove that.
Thanks,
tglx
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.
ALSA is adding CLOCK_MONOTONIC_RAW for the same reason.
Regards,
Clemens
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?
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
On Wed, Jul 16, 2014 at 04:16:35PM +0200, Clemens Ladisch wrote:
> Peter Zijlstra wrote:
> > On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote:
> >> 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?)
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.
For ALSA the behaviour is optional and users can always opt to use the
NTP corrected monotonic clock if they prefer.
On 16/07/14 16:00, Mark Brown wrote:
> On Wed, Jul 16, 2014 at 04:16:35PM +0200, Clemens Ladisch wrote:
>> Peter Zijlstra wrote:
>>> On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote:
>
>>>> 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?)
>
> 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.
Both audio and video must be presented synchronized to the recovered
broadcast clock which in practice this means comparing them to
CLOCK_MONOTONIC_RAW and doing some maths.
In is, of course, possible to convert ALSA's CLOCK_MONOTONIC
timestamps into CLOCK_MONOTONIC_RAW values so we can compare ALSA time
to the broadcast clock. In fact its not even that hard compared to the
other time conversions we have to do. Nevertheless it is a redundant
conversion and adds an extra dimension to a problem that only just fits
in most craniums ;-)
Daniel.
On Thu, 17 Jul 2014, 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:
> >> Peter Zijlstra wrote:
> >>> On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote:
> >
> >>>> 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?)
> >
> > 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.
>
> Both audio and video must be presented synchronized to the recovered
> broadcast clock which in practice this means comparing them to
> CLOCK_MONOTONIC_RAW and doing some maths.
>
> In is, of course, possible to convert ALSA's CLOCK_MONOTONIC
> timestamps into CLOCK_MONOTONIC_RAW values so we can compare ALSA time
> to the broadcast clock. In fact its not even that hard compared to the
> other time conversions we have to do. Nevertheless it is a redundant
> conversion and adds an extra dimension to a problem that only just fits
> in most craniums ;-)
Thanks for the explanation!
tglx
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.
On 17/07/14 17:14, John Stultz wrote:
> 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).
Interesting. That certainly explains *why* our algorithm breaks!
I admit I was curious why having the clock tick more accurately part way
through the data gathering caused our sync algorithms to break (although
clearly not curious enough). However even a pretty gradual change
towards a new offset would certainly cause lots of problems for these
use cases.
> 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.
Certainly the use case I presented is pretty niche and, intrinsically
non-portable.
In our case we make the "non-portable" assumption that the hardware
oscillator feeding CLOCK_MONOTONIC_RAW is of high enough quality for the
rest of the SoC to function correctly.
That's about the only assumption though.
> 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).