All of lore.kernel.org
 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: 39+ 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
  -- strict thread matches above, loose matches on Subject: below --
2007-02-25 21:29 John
2007-02-26 10:26 ` John
2007-02-26 12:20   ` Andi Kleen
2007-02-26 14:17     ` John
2007-02-28 11:23       ` John

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