Quick update. Long story short, I'm unable to reproduce Sharon's issue with tcpprep taking a long time (minutes).
My analysis: I downloaded the LLDOS 2.0.2 - Scenario Two inside & outside pcaps from: http://www.ll.mit.edu/IST/ideval/data/2000/2000_data_index.html (see bottom of page) these are relatively large pcaps (230-280MB) containing around 1M packets each. So not as big as Sharon's test set, but at least in the ballpark. $ tcpprep -V tcpprep version: 3.0.0 (build 1826) Copyright 2001-2007 by Aaron Turner <aturner at synfin dot net> Cache file supported: 04 Not compiled with libnet. Compiled against libpcap: 0.9.5 64 bit packet counters: disabled Verbose printing via tcpdump: enabled $ time tcpprep -o inside.cache -c 172.16.0.0/12 -i inside.tcpdump real 0m16.065s user 0m12.122s sys 0m1.602s $ time tcpprep -o outside.cache -c 172.16.0.0/12 -i outside.tcpdump real 0m21.963s user 0m16.062s sys 0m1.933s Above is on an Apple MacBookPro (OS X 10.4.9) w/ 3GB of RAM and 2.16Ghz Core2Duo. Notice each run took well under 30 seconds. The one thing I did notice is that tcpprep's total RAM usage went way up... around 800MB. Off the top of my head I don't know if that's "normal" or not. It could be a memory leak- I'll have to look into it. But if you don't have much free RAM and your box is swapping a lot, it could explain the slowness. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
