Messages in this thread | | | Date | Wed, 26 Nov 2003 16:30:17 -0800 | From | Mitchell Blank Jr <> | Subject | Re: Fast timestamps |
| |
David S. Miller wrote: > Ben Greear <greearb@candelatech.com> wrote: > > I'll try to write up a patch that uses the TSC and lazy conversion > > to timeval as soon as I get the rx-all and rx-fcs code happily > > into the kernel.... > > > > Assuming TSC is very fast and the conversion is accurate enough, I think > > this can give good results.... > > I'm amazed that you will be able to write a fast_timestamp > implementation without even seeing the API I had specified > to the various arch maintainers :-)
Also, anyone interested in doing this should probably re-read the thread on netdev from a couple months back about this, since we hashed out some implementation details wrt SMP efficiency: http://oss.sgi.com/projects/netdev/archive/2003-10/msg00032.html
Although reading this thread I'm feeling that Andi is probably right - are there really any apps that coudn't cope with a small inaccuracy of the first ioctl-fetched timestamp? I really doubt it. Basically there's two common cases: 1. System under reasonably network load: in this case the tcpdump (or whatever) probably will get the packet soon after it arrived, so the timestamp we compute for the first packet won't be very far off. 2. System under heavy network load: the card's hardware rx queues are probably pretty full so our timestamps won't be very accurate no matter what we do
Given that the timestamp is already inexact it seems like a fine idea to trade a tiny amount of accuracy for a potentially significant performance improvement.
-Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |