netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).