Re: tcptrace and huge files ? (a few GB)

From: Long Le (le@cs.unc.edu)
Date: 10/27/02

  • Next message: Rick Jones: "Re: tcptrace and huge files ? (a few GB)" 

    Date: Sun, 27 Oct 2002 19:28:03 -0500 (EST)
From: Long Le <le@cs.unc.edu>
Subject: Re: tcptrace and huge files ? (a few GB)
Message-ID: <Pine.LNX.4.33.0210271927010.28834-100000@le-cs.cs.unc.edu>

    On a slightly related topic, does anyone have tips for taking tcpdump
    traces on a fairly high-speed link (say, 1-Gbps link) without dropping
    too many packets?

    Thanks,
    -- long

    On Tue, 22 Oct 2002, Rick Jones wrote:

    > > tcptrace have memory problems when procesing large files. I think the
    > > best solution is to prefilter the trace with tcpdump.
    >
    > It can also have file descriptor limit problems when generating the
    > xplot files... I've run into that - not sure if I was trying to run a
    > 64-bit compiled tcptrace at the time or not.
    >
    > I figure that the only "complete" soltuion other than a 64-bit
    > application with no file descriptor limits would be some sort of
    > heuristic where tcptrace decides to "swap-out" a connection to a temp
    > file (think backing store) or something when it has gone say N packets
    > past the FIN or RST in the trace. that, or once it has state for M flows
    > already running.
    >
    > it would still need/want to keep an N-tuple/flow to backing store
    > mapping (think TLB/pdir) in memory
    >
    > i suspect it would be straight-forward, but non-trivial, but I've never
    > actually writen anything like that so I could be completely wrong.
    >
    > rick jones
    >

    ----------------------------------------------------------------------------
    To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
    majordomo@tcptrace.org.

    This archive was generated by hypermail 2b30 : 10/28/02 EST