From: John <linux.kernel@free.fr>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: linux-net@vger.kernel.org, netdev@vger.kernel.org, linux.kernel@free.fr
Subject: Re: CLOCK_MONOTONIC datagram timestamps by the kernel
Date: Wed, 28 Feb 2007 15:23:30 +0100 [thread overview]
Message-ID: <45E59062.6000103@free.fr> (raw)
In-Reply-To: <200702281455.27720.dada1@cosmosbay.com>
Eric Dumazet wrote:
>> John wrote:
>>
>>> I know it's possible to have Linux timestamp incoming datagrams as soon
>>> as they are received, then for one to retrieve this timestamp later with
>>> an ioctl command or a recvmsg call.
>> Has it ever been proposed to modify struct skb_timeval to hold
>> nanosecond stamps instead of just microsecond stamps? Then make the
>> improved precision somehow available to user space.
>
> Most modern NICS are able to delay packet delivery, in order to reduce number
> of interrupts and benefit from better cache hits.
You are referring to NAPI interrupt mitigation, right?
AFAIU, it is possible to disable this feature.
I'm dealing with 200-4000 packets per second. I don't think I'd save
much with interrupt mitigation. Please correct any misconception.
> Then kernel is not realtime and some delays can occur between the hardware
> interrupt and the very moment we timestamp the packet. If CPU caches are
> cold, even the instruction fetches could easily add some us.
I've applied the real-time patch.
http://rt.wiki.kernel.org/index.php/Main_Page
This doesn't make Linux hard real-time, but the interrupt handlers can
run with the highest priority (even kernel threads are preempted).
> Enabling nanosecond stamps would be a lie to users, because real accuracy is
> not nanosecond, but in the order of 10 us (at least)
POSIX is moving to nanoseconds interfaces.
http://www.opengroup.org/onlinepubs/009695399/functions/clock_settime.html
struct timeval and struct timespec take as much space (64 bits).
If the hardware can indeed manage sub-microsecond accuracy, a struct
timeval forces the kernel to discard valuable information.
> If you depend on a < 50 us precision, then linux might be the wrong OS for
> your application. Or maybe you need a NIC that is able to provide a timestamp
> in the packet itself (well... along with the packet...) , so that kernel
> latencies are not a problem.
Does Linux support NICs that can do that?
Regards.
next prev parent reply other threads:[~2007-02-28 14:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 10:18 CLOCK_MONOTONIC datagram timestamps by the kernel John
2007-02-28 13:37 ` John
2007-02-28 13:55 ` Eric Dumazet
2007-02-28 14:23 ` John [this message]
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-02 14:38 ` [PATCH] NET : convert network timestamps to ktime_t Eric Dumazet
2007-03-02 16:27 ` Stephen Hemminger
2007-03-02 21:02 ` Stephen Hemminger
2007-03-02 22:46 ` Eric Dumazet
2007-03-05 0:19 ` David Miller
2007-03-05 6:56 ` Eric Dumazet
2007-03-05 7:40 ` Eric Dumazet
2007-03-05 8:00 ` David Miller
2007-03-05 8:21 ` Eric Dumazet
2007-03-05 8:49 ` David Miller
2007-03-08 14:17 ` [PATCH] NET : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution Eric Dumazet
2007-03-08 16:28 ` Patrick McHardy
2007-03-08 16:42 ` Eric Dumazet
2007-03-08 16:45 ` Patrick McHardy
2007-03-09 4:39 ` David Miller
2007-03-09 18:39 ` [PATCH] NET : Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support Eric Dumazet
2007-03-09 22:17 ` David Miller
2007-03-01 18:53 ` CLOCK_MONOTONIC datagram timestamps by the kernel 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=45E59062.6000103@free.fr \
--to=linux.kernel@free.fr \
--cc=dada1@cosmosbay.com \
--cc=linux-net@vger.kernel.org \
--cc=netdev@vger.kernel.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 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).