* clock_nanosleep and NTP drift correction
@ 2012-09-13 11:20 Koehrer Mathias (ETAS/ESS2)
2012-09-13 12:09 ` Luis Claudio R. Goncalves
0 siblings, 1 reply; 6+ messages in thread
From: Koehrer Mathias (ETAS/ESS2) @ 2012-09-13 11:20 UTC (permalink / raw)
To: linux-rt-users@vger.kernel.org
Hi all!
I have two x86 PCs running with the RT_PREEMPT patch (2.6.33.x).
Both PCs run a real time application with a thread that will be executed periodically every 1ms.
For this I use a
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL);
within the application's main loop.
The value of "ts" will be incremented after every call.
Both PCs (PC-A, PC-B) are connected via Ethernet to a third PC (PC-C) that acts as NTP time server for the other PCs (PC-A and PC-B).
My question is now:
Does clock_nanosleep() consider a potential time drift that is corrected by NTP?
Or: Will there be a significant drift between both PCs (PC-A, PC-B) by using this approach?
As the application runs very long (hours or even days) I am looking for a solution that avoids
large drifts between the two systems.
Deltas of 1 or 2 ms are acceptable, but no time differences in tens of milliseconds.
Thanks for any help or feedback on this question
Best regards
Mathias
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: clock_nanosleep and NTP drift correction
2012-09-13 11:20 clock_nanosleep and NTP drift correction Koehrer Mathias (ETAS/ESS2)
@ 2012-09-13 12:09 ` Luis Claudio R. Goncalves
2012-09-13 15:22 ` Adrian Knoth
0 siblings, 1 reply; 6+ messages in thread
From: Luis Claudio R. Goncalves @ 2012-09-13 12:09 UTC (permalink / raw)
To: Koehrer Mathias (ETAS/ESS2); +Cc: linux-rt-users@vger.kernel.org
On Thu, Sep 13, 2012 at 11:20:24AM +0000, Koehrer Mathias (ETAS/ESS2) wrote:
| Hi all!
|
| I have two x86 PCs running with the RT_PREEMPT patch (2.6.33.x).
| Both PCs run a real time application with a thread that will be executed periodically every 1ms.
| For this I use a
| clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL);
| within the application's main loop.
| The value of "ts" will be incremented after every call.
|
| Both PCs (PC-A, PC-B) are connected via Ethernet to a third PC (PC-C) that acts as NTP time server for the other PCs (PC-A and PC-B).
|
| My question is now:
| Does clock_nanosleep() consider a potential time drift that is corrected by NTP?
| Or: Will there be a significant drift between both PCs (PC-A, PC-B) by using this approach?
CLOCK_MONOTONIC is not affected by NTP nor any adjusts to date and time
that the admin/user may perform.
The only problem you could face would happen if the 'ts' value, third
parameter passed to clock_nanosleep, was coming from one system and being
used on both. Then, any difference between the clocks could lead to shorter
sleep times. Other than that, as far as manpages go, you seem to be safe.
Luis
--
[ Luis Claudio R. Goncalves Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: clock_nanosleep and NTP drift correction
@ 2012-09-13 12:59 Koehrer Mathias (ETAS/ESS2)
0 siblings, 0 replies; 6+ messages in thread
From: Koehrer Mathias (ETAS/ESS2) @ 2012-09-13 12:59 UTC (permalink / raw)
To: Luis Claudio R. Goncalves; +Cc: linux-rt-users@vger.kernel.org
> On Thu, Sep 13, 2012 at 11:20:24AM +0000, Koehrer Mathias (ETAS/ESS2) wrote:
> | I have two x86 PCs running with the RT_PREEMPT patch (2.6.33.x).
> | Both PCs run a real time application with a thread that will be executed periodically
> every 1ms.
> | For this I use a
> | clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL);
> | within the application's main loop.
> | The value of "ts" will be incremented after every call.
> |
> | Both PCs (PC-A, PC-B) are connected via Ethernet to a third PC (PC-C) that acts as
> NTP time server for the other PCs (PC-A and PC-B).
> |
> | My question is now:
> | Does clock_nanosleep() consider a potential time drift that is corrected by NTP?
> | Or: Will there be a significant drift between both PCs (PC-A, PC-B) by using this
> approach?
>
> CLOCK_MONOTONIC is not affected by NTP nor any adjusts to date and time
> that the admin/user may perform.
>
> The only problem you could face would happen if the 'ts' value, third
> parameter passed to clock_nanosleep, was coming from one system and being
> used on both. Then, any difference between the clocks could lead to shorter
> sleep times. Other than that, as far as manpages go, you seem to be safe.
I want to ensure that after one day the very same number of cycles have
been executed on PC-A and PC-B.
Even if the internal clock of PC-A has a drift of 2s/day against that of PC-B.
Using NTP the real time clock will be corrected - however the used
function clock_nanosleep using CLOCK_MONOTONIC will not.
Does this mean that I will have 2000 more millisecond cycles on the "faster PC" during
a whole day?
Regards
Mathias
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: clock_nanosleep and NTP drift correction
2012-09-13 12:09 ` Luis Claudio R. Goncalves
@ 2012-09-13 15:22 ` Adrian Knoth
2012-09-13 15:33 ` Adrian Knoth
2012-09-13 18:18 ` Luis Claudio R. Goncalves
0 siblings, 2 replies; 6+ messages in thread
From: Adrian Knoth @ 2012-09-13 15:22 UTC (permalink / raw)
To: Luis Claudio R. Goncalves
Cc: Koehrer Mathias (ETAS/ESS2), linux-rt-users@vger.kernel.org
On 09/13/2012 02:09 PM, Luis Claudio R. Goncalves wrote:
> | clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL);
> | within the application's main loop.
> | The value of "ts" will be incremented after every call.
> |
> CLOCK_MONOTONIC is not affected by NTP nor any adjusts to date and time
> that the admin/user may perform.
I beg to differ. CLOCK_MONOTONIC is frequency adjusted. Though it won't
jump, it will slew. From man clock_gettime:
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since
some unspecified starting point. This clock is not affected by
discontinuous jumps in the system time (e.g., if the system
administrator manually changes the clock), but is affected by
the incremental adjustments performed by adjtime(3) and NTP.
Which means it's more or less what the original poster wants.
Though it's LaTeX, here's a table I've created a couple of months ago:
\begin{table}
\begin{tabular*}{\textwidth}{l@{\extracolsep{\fill}}ccccc}
\toprule
{\scshape clock name}& {\scshape posix}& {\scshape set}& {\scshape
adjust}&
{\scshape jump} &
{\scshape slew}\\
\midrule
\texttt{CLOCK_REALTIME}& yes& yes& yes& yes& yes\\
\texttt{CLOCK_MONOTONIC}& yes& no& yes& no& yes\\
\texttt{CLOCK_MONOTONIC_RAW}& no& no& no& no& no\\
\texttt{CLOCK_PROCESS_CPUTIME_ID}& yes& no& no& SMP& no\\
\texttt{CLOCK_THREAD_CPUTIME_ID}& yes& no& no& SMP& no\\
\bottomrule
\end{tabular*}
\caption{Multiple clock sources as required by
POSIX and the Linux-specific \texttt{CLOCK_MONOTONIC_RAW}.
Only \texttt{CLOCK_REALTIME}, the clock shown to the user as system
time, can be set
explicitly.
It is not monotonic, the clock
can jump back and forth or slew when being frequency adjusted. In
contrast, \texttt{CLOCK_MONOTONIC} is strictly monotonic, but can still
be frequency adjusted and will hence slew.
\texttt{CLOCK_MONOTONIC_RAW} does not exhibit any of
these deficiencies, but has no relation to UTC at all.
It is ideal for reliably tracking foreign clocks, e.g., timestamps in
networked or FireWire audio.
The two CPUTIME clocks
accumulate the time a process or thread has spent running on the
CPU. Since these clocks rely on registers that can be local to an
individual CPU or core, care must be taken on SMP systems.}
\label{tab:clocks}
\end{table}
(the adjust and slew columns are somewhat redundant)
Side note: if NTP is too coarse, maybe it's worth having a look at PTP.
HTH
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: clock_nanosleep and NTP drift correction
2012-09-13 15:22 ` Adrian Knoth
@ 2012-09-13 15:33 ` Adrian Knoth
2012-09-13 18:18 ` Luis Claudio R. Goncalves
1 sibling, 0 replies; 6+ messages in thread
From: Adrian Knoth @ 2012-09-13 15:33 UTC (permalink / raw)
To: linux-rt-users@vger.kernel.org
On 09/13/2012 05:22 PM, Adrian Knoth wrote:
> {\scshape clock name}& {\scshape posix}& {\scshape set}& {\scshape
> adjust}&
> {\scshape jump} &
> {\scshape slew}\\
> \midrule
> \texttt{CLOCK_REALTIME}& yes& yes& yes& yes& yes\\
> \texttt{CLOCK_MONOTONIC}& yes& no& yes& no& yes\\
> \texttt{CLOCK_MONOTONIC_RAW}& no& no& no& no& no\\
> \texttt{CLOCK_PROCESS_CPUTIME_ID}& yes& no& no& SMP& no\\
> \texttt{CLOCK_THREAD_CPUTIME_ID}& yes& no& no& SMP& no\\
For the sake of completeness, let me add that it's not possible to
clock_nanosleep() on CLOCK_MONOTONIC_RAW.
We recently came across this problem in FFADO, so maybe having this
information available saves some time for somebody. Further reading:
http://subversion.ffado.org/ticket/242
Cheers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: clock_nanosleep and NTP drift correction
2012-09-13 15:22 ` Adrian Knoth
2012-09-13 15:33 ` Adrian Knoth
@ 2012-09-13 18:18 ` Luis Claudio R. Goncalves
1 sibling, 0 replies; 6+ messages in thread
From: Luis Claudio R. Goncalves @ 2012-09-13 18:18 UTC (permalink / raw)
To: Adrian Knoth; +Cc: Koehrer Mathias (ETAS/ESS2), linux-rt-users@vger.kernel.org
On Thu, Sep 13, 2012 at 05:22:27PM +0200, Adrian Knoth wrote:
| On 09/13/2012 02:09 PM, Luis Claudio R. Goncalves wrote:
|
| > | clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, NULL);
| > | within the application's main loop.
| > | The value of "ts" will be incremented after every call.
| > |
| > CLOCK_MONOTONIC is not affected by NTP nor any adjusts to date and time
| > that the admin/user may perform.
|
| I beg to differ. CLOCK_MONOTONIC is frequency adjusted. Though it won't
| jump, it will slew. From man clock_gettime:
|
| CLOCK_MONOTONIC
| Clock that cannot be set and represents monotonic time since
| some unspecified starting point. This clock is not affected by
| discontinuous jumps in the system time (e.g., if the system
| administrator manually changes the clock), but is affected by
| the incremental adjustments performed by adjtime(3) and NTP.
You are right. The man pages I had access to are a bit less verbose on the
description but, to the attentive reader, give the same idea. Also Mathieu
and Rostedt showed me I had a slightly absurd concept of 'monotonic'.
I learned two new things on a single discussion :)
Cheers,
Luis
--
[ Luis Claudio R. Goncalves Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-13 18:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-13 11:20 clock_nanosleep and NTP drift correction Koehrer Mathias (ETAS/ESS2)
2012-09-13 12:09 ` Luis Claudio R. Goncalves
2012-09-13 15:22 ` Adrian Knoth
2012-09-13 15:33 ` Adrian Knoth
2012-09-13 18:18 ` Luis Claudio R. Goncalves
-- strict thread matches above, loose matches on Subject: below --
2012-09-13 12:59 Koehrer Mathias (ETAS/ESS2)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).