On Thu, Jan 27, 2011 at 10:18 AM, Jason Funk
<[email protected]> wrote:
> -Tgtod helped but it still wasn't very accurate. Maybe I have unrealistic
> expectations of the accuracy I should be seeing.
> --mbps=100 -> 86.63
> --mbps=200 -> 135.30
> --mbps=300 -> 163.53
> --mbps=400 -> 185.68
>
> You can download the pcap from here:
> http://productupdates.palisadesys.com/support/downloads/http.pcap.tar.gz
I looked at the pcap, and it's mostly small packets (average is
225bytes). This means tcpreplay has to work a lot harder to be
accurate and my current algorithms don't do a good job taking into
account the actual CPU time spent sending the traffic. The result is
that accuracy tends to be most poor for high speed + small packets
such as in this case. There are some tricks though:
tcpreplay -i en0 -M100.0 --preload-pcap --sleep-accel=2 -Tgtod http.pcap
What I'm doing here is loading the pcap fully into RAM before
starting. This removes disk I/O from causing any problem which can
happen with many small reads. The other thing is the --sleep-accel
option which is basically a manual compensator for tcpreplay's timing
algorithm. Basically play with that value and possibly --mbps until
you get something closer to your goal.
Using those settings above I was able to get:
sending out en0
File Cache is enabled
processing file: http.pcap
Actual: 415298 packets (93454987 bytes) sent in 7.28 seconds.
Rated: 12837223.0 Bps, 102.70 Mbps, 57046.43 pps
Statistics for network device: en0
Attempted packets: 415298
Successful packets: 415298
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Hope that helps!
--
Aaron Turner
http://synfin.net/ Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
"carpe diem quam minimum credula postero"
>
> On Thu, Jan 27, 2011 at 12:03 PM, Aaron Turner <[email protected]> wrote:
>>
>> On Thu, Jan 27, 2011 at 9:39 AM, Jason Funk
>> <[email protected]> wrote:
>> > Any ideas on what would cause this? The second test, even though I told
>> > it
>> > to send at 100 mbps, only sent at ~4 mbps.
>> >
>> > tester# tcpreplay -i em1 --mbps=100.0 http.pcap
>> > sending out em1
>> > processing file: http.pcap
>> > Actual: 415298 packets (93454987 bytes) sent in 179.87 seconds
>> > Rated: 519569.6 bps, 3.96 Mbps, 2308.88 pps
>> > Statistics for network device: em1
>> > Attempted packets: 415298
>> > Successful packets: 415298
>> > Failed packets: 0
>> > Retried packets (ENOBUFS): 0
>> > Retried packets (EAGAIN): 0
>> > tester#
>>
>>
>> You can try adding -Tgtod which will increase server load, but allows
>> more accurate timing. If that doesn't help, send me the pcap file to
>> look at.
>>
>> Regards,
>> Aaron
--
Aaron Turner
http://synfin.net/ Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
"carpe diem quam minimum credula postero"
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Tcpreplay-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
