All of lore.kernel.org
 help / color / mirror / Atom feed
From: John <linux.kernel@free.fr>
To: linux-kernel@vger.kernel.org
Cc: johnstul@us.ibm.com, mingo@elte.hu, zippel@linux-m68k.org,
	tglx@timesys.com, akpm@linux-foundation.org, ak@suse.de,
	jbohac@suse.cz, linux.kernel@free.fr
Subject: Re: CLOCK_MONOTONIC datagram timestamps by the kernel
Date: Mon, 26 Feb 2007 11:26:44 +0100	[thread overview]
Message-ID: <45E2B5E4.7020208@free.fr> (raw)
In-Reply-To: <45E1FFCC.50201@free.fr>

John wrote:

> It is possible to ask Linux to timestamp incoming datagrams when they
> are received, then to retrieve this timestamp with an ioctl command or
> a recvmsg call (which would save one round trip to kernel space).
> 
> SIOCGSTAMP
>     Return a struct timeval with the receive timestamp of the last
> packet passed to the user. This is useful for accurate round trip time
> measurements. See setitimer(2) for a description of struct timeval.
> 
> As far as I understand, this timestamp is given by the CLOCK_REALTIME
> clock. I would like to get the timestamp given by a different clock:
> the CLOCK_MONOTONIC clock.
> 
> In other words, I would like the kernel to do the equivalent of
> 
>   struct timespec spec;
>   clock_gettime(CLOCK_MONOTONIC, &spec)
> 
> for each datagram the system receives, as soon as it is received.
> 
> Is there a way to achieve that?
> 
> Is there a different ioctl perhaps? (I don't think so.)

I've been reading the following documents:

Clocks and Timers
http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_18

Rationale for the Monotonic Clock
http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19

"For those applications that use time services to achieve realtime 
behavior, changing the value of the clock on which these services rely 
may cause erroneous timing behavior. For these applications, it is 
necessary to have a monotonic clock which cannot run backwards, and 
which has a maximum clock jump that is required to be documented by the 
implementation. Additionally, it is desirable (but not required by IEEE 
Std 1003.1-2001) that the monotonic clock increases its value uniformly. 
This clock should not be affected by changes to the system time; for 
example, to synchronize the clock with an external source or to account 
for leap seconds. Such changes would cause errors in the measurement of 
time intervals for those time services that use the absolute value of 
the clock."

clock and timer functions
http://www.opengroup.org/onlinepubs/009695399/functions/clock_settime.html

"If the value of the CLOCK_REALTIME clock is set via clock_settime(), 
the new value of the clock shall be used to determine the time of 
expiration for absolute time services based upon the CLOCK_REALTIME 
clock. This applies to the time at which armed absolute timers expire. 
If the absolute time requested at the invocation of such a time service 
is before the new value of the clock, the time service shall expire 
immediately as if the clock had reached the requested time normally."

"The effect of setting a clock via clock_settime() on armed per-process 
timers associated with a clock other than CLOCK_REALTIME is 
implementation-defined."


Here's some background on what I'm trying to do:

My app expects a stream of UDP datagrams containing compressed video.
These datagrams have been time stamped by the source using a high 
resolution clock.

The video stream is played out in real-time. I buffer several packets, 
then repeatedly arm a one-shot timer (with TIMER_ABSTIME set) to wait 
until it's time to send the oldest packet.

AFAIU, if I use the CLOCK_REALTIME clock in my app, and if the sysadmin 
changes the date, hell will break loose in my app. Hence my need for 
CLOCK_MONOTONIC.


On a related note, I see that do_gettimeofday() in kernel/timer.c 
actually gets a struct timespec from __get_realtime_clock_ts() then 
throws bits away in the ns to us conversion. The integer division is 
also a waste of cycles in my case, as I want the result in ns.

I suppose that if I change sock_get_timestamp() in core/sock.c to call 
__get_realtime_clock_ts() instead of do_gettimeofday() I'll break 50 
billion applications (ping? traceroute?) that expect a struct timeval?

Anyway, thanks for reading this far.

Regards.

  reply	other threads:[~2007-02-26 10:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-25 21:29 CLOCK_MONOTONIC datagram timestamps by the kernel John
2007-02-26 10:26 ` John [this message]
2007-02-26 12:20   ` Andi Kleen
2007-02-26 14:17     ` John
2007-02-28 11:23       ` John
2007-02-28 10:18 John
2007-02-28 13:37 ` John
2007-02-28 13:55   ` Eric Dumazet
2007-02-28 14:23     ` John
2007-02-28 14:55       ` Eric Dumazet
2007-02-28 16:07         ` John
2007-03-01 10:03           ` Evgeniy Polyakov
2007-03-01 11:30           ` Eric Dumazet
2007-03-01 15:54             ` Stephen Hemminger
2007-03-01 16:13               ` Eric Dumazet
2007-03-01 18:53             ` Stephen Hemminger
2007-03-01 23:14               ` Eric Dumazet
2007-03-01 23:34                 ` Stephen Hemminger
2007-03-02  0:56                   ` Eric Dumazet
2007-03-02  9:26             ` John
2007-03-02 10:11               ` Eric Dumazet
2007-02-28 18:22   ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45E2B5E4.7020208@free.fr \
    --to=linux.kernel@free.fr \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jbohac@suse.cz \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@timesys.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.