Opened 8 years ago

Closed 8 years ago

#457 closed defect (worksforme)

tcpreplay -p and -M option not worked correctly

Reported by: alok.dadarya@… Owned by: aturner
Priority: medium Milestone: 3.5.0
Component: tcpreplay Version: 3.4.3
Keywords: packet per second Cc: alok.dadarya@…
Operating System: Linux Add to FAQ?: yes
Hardware: Intel
Output of tcpreplay -V: tcpreplay version: 3.4.3 (build 2375) Copyright 2001-2009 by Aaron Turner <aturner at synfin dot net> Cache file supported: 04 Compiled against libdnet: 1.11 Compiled against libpcap: 0.9.4 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Packet editing: disabled Fragroute engine: enabled Injection method: PF_PACKET send()



Given below is the following information of the PCAP file.

No of messages 6996001
Start Time 5/11/2010 0:35
End Time 5/11/2010 0:59
Size of the traffic file : 1.2 GB

while I have played this file at the top speed it is completed as below.

processing file: /tmp/Perfromance2_SIG.pcap
Actual: 6996001 packets (1148889273 bytes) sent in 13.76 seconds
Rated: 83494856.0 bps, 637.02 Mbps, 508430.31 pps
Statistics for network device: lo

Attempted packets: 6996001
Successful packets: 6996001
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0


While same file at same server play a traffic file at 20000 messages per second then it processes only 248.02 pps instead of 20000 PPS.

/root> /usr/local/bin/tcpreplay -p 20000 -i lo /tmp/Perfromance2_SIG.pcap
Warning: Unsupported physical layer type 0x0304 on lo. Maybe it works, maybe it wont. See tickets #123/318
sending out lo
processing file: /tmp/Perfromance2_SIG.pcap

Actual: 209756 packets (33419786 bytes) sent in 845.72 seconds
Rated: 39516.4 bps, 0.30 Mbps, 248.02 pps

Note :- I have also go through and tried other option but unable to resolve the problem and could not get the logic how tcpreplay works internally and in which PPS and -M options works as given parameters.

server information :-

Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
RAM : 8 GB

Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 0.7%sy, 0.0%ni, 94.9%id, 3.4%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 8109824k total, 2874668k used, 5235156k free, 53512k buffers
Swap: 8393920k total, 0k used, 8393920k free, 2620316k cached

Change History (2)

comment:1 Changed 8 years ago by aturner

You didn't specify what the issue with -M (--mbps) is, but per the documentation ( it's not the best solution. If you're seeing really bad results with -p then I'm not surprised you're having issues here.

Your issue with -p is most likely caused by the default timing method used in v3.4.3 doesn't mix well with your Linux kernel version/hardware. Generally speaking, using -T gtod will provide better results- although it uses more CPU horsepower. See for more info about timing methods.

comment:2 Changed 8 years ago by aturner

  • Resolution set to worksforme
  • Status changed from new to closed

No update from user, so closing ticket.

Note: See TracTickets for help on using tickets.