Inline...
On 3/16/07, Lothar Braun <[EMAIL PROTECTED]> wrote:
> Hi Aaron,
>
> On Saturday 24 February 2007 18:06:48 Aaron Turner wrote:
>
> Uh, i somehow missed this mail.
>
> > Anyways, since my results are very different from yours, I was hoping
> > you could send me the exact command lines you were using for beta12 &
> > 2.3.5 as well as the pcap involved.
>
> I don't have the former dump any more, but i created a new file and got the
> following results on my laptop (Intel Celeron M processor 1.40GHz with 1 GB
> RAM)
>
> 2.3.5:
> [EMAIL PROTECTED] tcpreplay-2.3.5]# ./tcpreplay -i eth0 -l 50000 -R dump
> sending on: eth0
> 1450000 packets (230700000 bytes) sent in 5.56 seconds
> 41440275.0 bytes/sec 316.16 megabits/sec 260461 packets/sec
316Mbps? Damn. You say this is a 1.4Ghz celeron? My 2.16Ghz
Core2Duo (macbook pro) only 180Mbps. What OS & version? What NIC?
Any performance tweaks you've done?
> beta12:
> [EMAIL PROTECTED] tcpreplay-3.0.beta12]# ./src/tcpreplay -i eth0 -l 50000 -t
> dump
> processing file: dump
> > [repeated]
> processing file: dump
> Actual: 1450000 packets (230700000 bytes) sent in 10.96 seconds
> Rated: 21043968.8 bps, 160.55 Mbps/sec, 132265.95 pps
More like what I would expect.
> After doing that, i commented out line 141 in src/tcpreplay.c
>
> 141 //notice("processing file: %s", path);
>
> recompiled and tried again:
>
> [EMAIL PROTECTED] tcpreplay-3.0.beta12]# ./src/tcpreplay -i eth0 -l 50000 -t
> dump
> sending out eth0
> Actual: 1450000 packets (230700000 bytes) sent in 3.22 seconds
> Rated: 71636685.6 bps, 546.54 Mbps/sec, 450252.25 pps
>
> As you can see, there is a heavy speed up. 3.0 got even faster than 2.3.5.
Wow, your terminal really has a stiff performance hit doesn't it? Can
you redirect stderr to a file and check the results? My guess is you
will see things improve significantly.
Anyways, I've added a --quiet option to tcpreplay which skips the
notices all together. It'll be part of 3.0.RC1.
> After that i tried the -p option with 2.3.5 and beta12 (the one that included
> the above comment):
>
> 2.3.5:
> [EMAIL PROTECTED] tcpreplay-2.3.5]# ./tcpreplay -i eth0 -l 1000 -p 4000 dump
> sending on: eth0
> 29000 packets (4614000 bytes) sent in 7.22 seconds
> 638889.8 bytes/sec 4.87 megabits/sec 4015 packets/sec
>
> beta12:
> [EMAIL PROTECTED] tcpreplay-3.0.beta12]# ./src/tcpreplay -i eth0 -l 1000 -p
> 4000
> dump
> sending out eth0
> Actual: 29000 packets (4614000 bytes) sent in 8.36 seconds
> Rated: 574150.6 bps, 4.38 Mbps/sec, 3608.66 pps
>
> You'll notice that the difference between the actual and the desired speed is
> less than 1% on 2.3.5 and almost 10% on beta12.
Very unfortunate, but not shocking. 4000pkts/sec is a hard rate to
match using nanosleep() which often has a resolution closer to 1 to
10ms. Unfortunately, my testing of the --accurate flag in 3.0.beta12
isn't showing much better (it uses a gettimeofday() loop for timing,
but this syscall is relatively expensive). Basically when you need to
spread 4000 events evenly over a second (or once every .25ms) things
get crappy really quick when your timer resolution is 4 to 40 times
that.
Anyways, fixing this is part of ticket #41.
Regards,
Aaron
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Tcpreplay-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
