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.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
