lkml.org 
[lkml]   [2006]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Network performance degradation from 2.6.11.12 to 2.6.16.20
    From
    From: David Lang <dlang@digitalinsight.com>
    Date: Mon, 18 Sep 2006 14:57:04 -0700 (PDT)

    > yes tcpdump may be wrong in requesting timestamps (in most cases it
    > probably is, but in some cases it's doing exactly what the sysadmin
    > wants it to do), but I don't think that many sysadmins would expect
    > this much of a performance hit. there should be some way to tell
    > the system to ignore requests for timestamps so that a badly behaved
    > program cannot cripple the system this way (and preferably something
    > that doesn't require a full SELinux/capabilities implementation)

    tcpdump is not wrong in requesting timestamps, and there are
    many legitimate userland programs that call gettimeofday()
    for internal timestamping _A LOT_. Such as X11 clients.

    The real fact of the matter is that these x86_64 systems are using the
    slowest possible time-of-day implementation, simply because it's "too
    hard" currently to properly probe the most efficient mechanism which
    is present in the system.

    If getting the time of day is at the top of the profiles in the packet
    input path, and we're only capturing a timestamp once per packet,
    something is _VERY VERY_ wrong with the timestamp implementation
    because think of all of the other seriously expensive things that
    happen on a per-packet basis which should absolutely dwarf
    timestamping in terms of cost.

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

    \
     
     \ /
      Last update: 2006-09-19 21:43    [W:9.593 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site