[lkml]   [2003]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fast timestamps
    David S. Miller wrote:
    > Ben Greear <> 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:

    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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.032 / U:54.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site