Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

From: Andi Kleen <redacted>
Date: 18 Sep 2006 11:58:21 +0200

For netdev: I'm more and more thinking we should just avoid the
problem completely and switch to "true end2end" timestamps. This
means don't time stamp when a packet is received, but only when it
is delivered to a socket. The timestamp at receiving is a lie
anyways because the network hardware can add an arbitary long delay
before the driver interrupt handler runs. Then the problem above
would completely disappear.

I don't think this is wise.

People who run tcpdump want "wire" timestamps as close as possible.
Yes, things get delayed with the IRQ path, DMA delays, IRQ
mitigation and whatnot, but it's an order of magnitude worse if
you delay to user read() since that introduces also the delay of
the packet copies to userspace which are significantly larger than
these hardware level delays.  If tcpdump gets swapped out, the
timestamp delay can be on the order of several seconds making it
totally useless.

Andi, you will need to find another solution to this problem :-)